What is raw socket in linux

What is raw socket in linux

Уровень IPv4 генерирует заголовок IP при посылке пакета, если только для сокета не включён параметр IP_HDRINCL. Если он включён, то пакет должен содержать заголовок IP. Принимаемые пакеты всегда содержат заголовок IP.

Открывать неструктурированные сокеты могут только процессы с идентификатором эффективного пользователя, равным 0, или имеющие мандат CAP_NET_RAW.

Все пакеты или ошибки, совпадающие с номером протокола protocol, указанным неструктурированному сокету, передаются этому сокету. Список допустимых протоколов назначается списком IANA и содержится в getprotobyname(3).

Протокол IPPROTO_RAW подразумевает включённый параметр IP_HDRINCL и позволяет отправлять любой протокол IP, который указан в передаваемом заголовке. Приём любых протоколов IP посредством IPPROTO_RAW через неструктурированные сокеты невозможен.

Поля заголовка IP, изменяемые IP_HDRINCL при передаче
IP Checksum	всегда заполняется
Source Address	заполняется, если значение равно нулю
Packet Id	заполняется, если значение равно нулю
Total Length	всегда заполняется

Если указан IP_HDRINCL и заголовок IP имеет ненулевой адрес назначения, то для маршрутизации пакета используется адрес назначения сокета. Если указан MSG_DONTROUTE, то адрес назначения должен ссылаться на локальный интерфейс, иначе в любом случае будет производиться поиск в таблице маршрутизации, но маршруты со шлюзами будут игнорироваться.

Если IP_HDRINCL не указан, то параметры заголовка IP в неструктурированных сокетах могут быть установлены с помощью setsockopt(2); более подробная информация приведена в ip(7).

Начиная с Linux 2.2 все поля заголовка IP и параметры могут быть заданы с помощью параметров сокета IP. Это означает, что неструктурированные сокеты, как правило, необходимы лишь для новых протоколов или протоколов без интерфейса пользователя (например, ICMP).

Принятый пакет передаётся всем подключенным (bound) к этому протоколу неструктурированным сокетам до того, как он будет передан другим обработчикам протоколов (например, протокольным модулям ядра).

Формат адреса

Параметры сокета

Кроме этого, поддерживаются все датаграммные параметры сокетов ip(7) для IPPROTO_IP.

Обработка ошибок

ОШИБКИ

ВЕРСИИ

Код неструктурированных сокетов в версии Linux 2.0 при установленном параметре SO_BSDCOMPAT был специально сделан совместимым с BSD «вплоть до ошибок». Из Linux 2.2 это было удалено.

ЗАМЕЧАНИЯ

Неструктурированный сокет может быть подключён к определённому локальному адресу с помощью вызова bind(2). Если он не подключён, то принимаются все пакеты указанного протокола IP. Кроме того, неструктурированный сокет может быть подключён к определённому сетевому устройству с помощью SO_BINDTODEVICE; смотрите socket(7).

Сокет IPPROTO_RAW предназначен только для отправки. Если вы хотите получать все пакеты IP, используйте сокет packet(7) с протоколом ETH_P_IP. Заметим, что пакетные сокеты, в отличие от неструктурированных сокетов, не собирают пакеты из фрагментов IP.

Если вы хотите получать все пакеты ICMP для датаграммного сокета, то лучше использовать IP_RECVERR на определённом сокете; смотрите ip(7).

Неструктурированные сокеты могут перехватывать в Linux все протоколы IP, даже имеющие протокольный модуль в ядре (такие, как ICMP или TCP). В этом случае пакеты передаются как модулю ядра, так и неструктурированным сокетам. На это нельзя закладываться в переносимых программах, так как многие другие реализации сокетов BSD так не делают.

Linux никогда не изменяет заголовки, полученные от пользователя (за исключением обнуления некоторых полей, как описано в случае с IP_HDRINCL). Такое поведение отличается от поведения многих других реализаций неструктурированных сокетов.

Неструктурированные сокеты, в общем случае, не являются переносимыми, поэтому следует избегать их использования в переносимых программах.

Передача через неструктурированный сокет должна осуществляться с помощью протокола IP из sin_port; эта возможность исчезла в Linux 2.2. Метод обхода — использовать IP_HDRINCL.

ДЕФЕКТЫ

Если установлен параметр IP_HDRINCL, датаграммы не будут фрагментированы и их размер будет ограничен MTU интерфейса.

В Linux 2.2 отсутствует настройка протокола IP для отправки sin_port — всегда используется тот протокол, к которому был подключён сокет или который был указан при первом вызове socket(2).

Источник

Особенности получения пакетов через raw socket в Linux

Linux (в отличии, к примеру, от FreeBSD) позволяет использовать сырые сокеты не только для отправки, но и для получения данных. В этом месте существуют интересные грабли, на которые я наступил. Теперь спешу показать их тем, кто еще на знает, чтобы каждый, используя свой любимый язык программирования, будь то C++ или Python, мог опробовать их в деле.

Суть граблей изображена на рисунке, чтобы те, кто уже в курсе, не тратили свое время.

Я буду писать примеры на С, но вы можете перенести их и на другие языки, предоставляющие возможность низкоуровневой работы со стеком TCP\IP в Linux.

Некоторые понятия

Напомню, что для инициализации сырого сокета мы передаем параметр, обозначающий тип протокола. Например UDP:

socket(AF_INET, SOCK_RAW, IPPROTO_UDP)

Этот протокол я буду называть уровнем на котором работает сырой сокет. В примере мы создали сырой сокет на уровне UDP.

Уровень сырого сокета не ограничивает вас в формировании пакета на отправку, вы можете самостоятельно сформировать как UDP, так и IP заголовок. А вот при получении данных начинается самое интересное…

Грабли

Допустим мы создали 2 сырых сокета на уровне UDP и воспользовались одним из них для отправки UDP пакета на UDP эхо сервер. Эхо вернет нам UDP payload обратно. Так вот, Стек TCP\IP скопирует полученный пакет на все сырые сокеты того уровня, который указан в поле Protocol IP заголовка пришедшего пакета. Еще раз повторюсь — на ВСЕ, даже те, которые открыты в других приложениях (по этой причине приложение, оперирующее сырыми сокетами может быть запущено только с правами суперпользователя). Так как UDP эхо сервер отвечает UDP пакетом, то все сырые сокеты UDP уровня его получат.

Отметим еще одну важную особенность. Не зависимо от уровня сырого сокета, ему доставляется полный пакет, включающий IP заголовки.

Таким образом, каждый сырой сокет в Linux является сниффером на том уровне, на котором он был создан. Следует помнить об этом при разработке приложений.

Пример

Не стал нагружать заметку кодом. Для тех, кому интересно попробовать, я
выложил свой пример на github. Там cmake проект, который собирает простенький UDP эхо-сервер и приложение, создающее 2 сырых сокета уровня UDP, один из которых посылает данные, но оба отправляются в epoll в ожидании ответа. Для чистоты эксперимента эхо-сервер и пример желательно пустить на разных машинах (не забудьте поправить код в соответствии вашим IP-шникам). Для интереса можно запустить несколько экземпляров примера.

Для внешкольного чтения есть хорошая статья.

Источник

How to Code Raw Sockets in C on Linux

Raw tcp sockets in C

Raw sockets can be used to construct a packet manually inside an application. In normal sockets when any data is send over the network, the kernel of the operating system adds some headers to it like IP header and TCP header. So an application only needs to take care of what data it is sending and what reply it is expecting.

But there are other cases when an application needs to set its own headers. Raw sockets are used in security related applications like nmap , packets sniffer etc.

In this article we are going to program raw sockets on linux using native sockets.

Windows for example does not support raw socket programming directly. To program raw sockets on windows a packet crafting library like winpcap has to be used.

In this article we are going to do some raw socket programming by constructing a raw TCP packet and sending it over the network. Before programming raw sockets, it is recommended that you learn about the basics of socket programming in c.

Raw TCP packets

A TCP packet is constructed like this

The plus means to attach the binary data side by side. So when making a raw tcp packet we need to know how to construct the headers properly. The structures of all headers are established standards which are described in RFCs.

IP Header Structure

The structure of IP Header as given by RFC 791 :

The «Source Address» field stores the ip address of the system sending the packet and the «Destination Address» contains the ip address of the destination system. Ip addresses are stored in long number format. The «Protocol» field stores a number that indicates the protocol, which is TCP in this case.

Structure of TCP header

The structure of a TCP header as given by RFC 793

So we need to construct the headers according to the formats specified above.

Raw tcp sockets

Create a raw socket like this

The above function call creates a raw socket of protocol TCP. This means that we have to provide the TCP header along with the data. The kernel or the network stack of Linux shall provide the IP header.

If we want to provide the IP header as well then there are 2 ways of doing this

1. Use protocol IPPROTO_RAW — This will allow to specify the IP header and everything that is contained in the packet.

2. Set the IP_HDRINCL socket option to 1 — This is same as the above. Just another way of doing.

When using the IP_HDRINCL the protocol used in the socket function is effectively of no use.

Below is an example code which constructs a raw TCP packet with some data

Final Code

Compile and Run

Compile by program by doing a gcc raw_socket.c at the terminal. Remember to run the program with root privileges. Raw sockets require root privileges.

Note the while loop in the above program. It has been put for testing purpose and should be removed if you dont intend to flood the target.

Use a packet sniffer like wireshark to check the output and verify that the packets have actually been generated and send over the network. Also note that if some kind of firewall like firestarter is running then it might block raw packets.

Resources

A Tech Enthusiast, Blogger, Linux Fan and a Software Developer. Writes about Computer hardware, Linux and Open Source software and coding in Python, Php and Javascript. He can be reached at [email protected] .

38 thoughts on “ How to Code Raw Sockets in C on Linux ”

also you can using below checksum function in your codes instead of this checksum function because this function may not work correctly on all processor architecture.
https://locklessinc.com/articles/tcp_checksum/

proposed checksum is second function in this link. you can read descriptions about different functions in above link.

hi dears,
this code has one problem:
1. you must send size of IP header for checksum function instead of iph->tot_len because this field is sum of IP and TCP with data part. (IP header size is 20 byte)

Why is the payload in hexadecimal form?

If i want receive the data then what should i have to do ?

if you need to receive the data then it is not recommended to use raw sockets.
Just use normal tcp or udp sockets to send and receive data.

sir why datagram is of size 4096…have u taken it randomly or thorugh some calculation??

struct iphdr *iph = (struct iphdr *) datagram;

//TCP header
struct tcphdr *tcph = (struct tcphdr *) (datagram + sizeof (struct ip));

please explain sir this it will be helpful if u mail me… also

Nice example: I am a little confused about the IPH checksum. you are passing iph->tot_len to csum(), which looks to include the data. I thought the IPH checksum was confined to only the header. Tx.

Can I get the code for SMTP raw socketing?

thannnnks, can you give us the modified raw tcp code for the ipv6 please ?

Very good example and explanations. Since I make use of raw sockets to send crafted TCP packets in my program, I was looking for an example on the web for exact variables, structures etc. and after reading many of those, I can tell you sir, Your’s explanation is excellent. Not only you’re mentioning all the correct fields. you’re also demonstrating using it with some excellent example.

However, since you’re using “malloc” in your example, shouldn’t you “free” it before the program ends?

where is the difference between “struct iphdr” and “struct ip”
Why do you use “struct ip” in line 74 ?

Okay. I just checked out the header files. It is actually the same.
Probably some Linux/BSD stuff.

I began reading this article, because i wanted to learn how user can define his own L4 layer protocol, but you ended up preparing standard TCP packet. Anyways….
Suppose if i define some XYZ layer 4 protocol, how the recieving machine would going to unwrap the layer 4 header as it may not aware of this non standard L4 header ??

Thanks for the example. How do I send a complete http get request to a particular uri?

Wow, I knew a bit of socket programming with pure C, but this is taking it too deeper. Thanks for letting me know it even existed. 🙂

The code makes some architecture assumptions that will probably work 99% of the time, but isn’t completely portable. For example, the checksum calculation assumes short is 2 bytes, and will likely segfault on anything where it is larger.

yeah right, thanks for pointing it out. shall fix the code to be more portable and post soon.

Shouldn’t iph->tot_len be hton’d?

Seems like there are several fields in the headers that need to be hton’d and they dont seem to be present in this example…

does this example work? or am i missing something?

thanks for pointing it out. the total_length value should be passed through htons.
the code works well because the kernel fills in the correct total length in the ip header.

Thank you. Could you please provide a link of a client-server IPv6 UDP RAW packet example. I’m having a problem to send sockets with sendto().

I have not yet coded the ipv6 version of udp raw sockets in c.
You need to google for it.

Why is it necessary to specify destination address in sendto(), if the packet header already has a destination address? What happens if they don’t match?

i am not sure about the exact mechanism. the destination address given in sendto is probably used to determine the network route the packet should take. the behaviour could vary across different systems like bsd, linux etc.

Segmentation Fault encountered on compiling it for SPEAr platform. What to do? Thanks

you have to debug the program and find out the exact point where the segmentation fault is occuring.
the error might be occuring due to some kind of invalid memory access being done in the code.

Thanks for the explanation and for the code example.

Hey I also want to send some data,say a character string along with the datagram. What changes should I make to the code?

I have updated the code to include data in the packet.
Check it out.

I did it in a slightly different way. This one works too.
Thanks a lot. 🙂
You rock!!

I run your code and capture the packets using wireshark. But when I try to see the the data using the “follow TCP stream” option, it says “the packets in the capture file for that stream have no data”. I checked the code and everything seems to be fine.
Is there any hidden reason for this happening?

it gives me “[bad hdr length 0 – too short,

are you setting the ip header fields correctly ?
what does wireshark show ?

Hey do you need to write an explicit code for receiving these packets on the client side or can wireshark capture them automatically?
I am sending these packets over wlan0 and am not able to view these packets on wireshark for some reason.
Could you help me with this?
I would really appreciate any help you could provide.

wireshark will capture the packets. if wireshark is not showing any packets, check if some firewall is blocking
the packets or not (this happens in most cases).

Hey it worked. But I am trying to change the TOS values but those changes are not showing up on the packets captured on wireshark. If I change any other fields in the Ip header, it shows that but it is causing some problems with the TOS field.
I basically want to set the priority of the packets that are going out of the machine. Am I on the right track?
Please help me with this.

what kind of priority are you trying to set ?
the TOS field does not control the priority in terms of how the packets go out of the machine.

And do you have any idea what changes are to be made in this code to make it work for UDP protocol rather than TCP?

change iph->protocol to 17. UDP protocol number is 17
then replace tcp header with the udp header. rest is the data to be send

Источник