Обмен данными по сети, адресация по МАС адресу - Си и Паскаль.

гуглим по словосочетанию "raw sockets"

man 7 packet

libpcap

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

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

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

По теме: Libnet is a high-level API (toolkit) allowing the application programmer to construct and inject network packets. It provides a portable and simplified interface for low-level network packet shaping, handling and injection. Libnet hides much of the tedium of packet creation from the application programmer such as multiplexing, buffer management, arcane packet header information, byte-ordering, OS-dependent issues, and much more. ...

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

т. е в обшем случае tcpdump не имеет смысла? ;)

ну а зачем по-вашему в man tcpdump такой абзац про вывод:

packets ‘‘dropped by kernel’’ (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is run ning, if the OS reports that information to applications; if not, it will be reported as 0).

Я в своё время плотно занимался libpcap и winpcap, работу писал по ARP-spoofing'у, и помню из кучи прочитанных док, что libpcap "by design" может дропать пакеты. Сейчас с полоборота не находится, если это для вас критично - сами поищите. Где-нибудь в доках, описывающих внутреннее устройство libpcap.

А может быть, что пакеты дропаются, потому что не хватает производительности процессора?

хех. простой ответ - может. Всё может быть, пока не доказано обратное. Тут выбор какой: или приоритет отдаётся tcpdump'у и тормозится сетевой интерфейс, пока не будут обработаны все перехваченные пакеты, или tcpdump получает не все пакеты. Вообще говоря, когда не знаешь наверняка, нужно предполагать худший вариант: опыт показывает, что в большинстве случаев он оказывается правильным. По моей информации, в случае с llibpcap верен как раз второй вариант.

> Где-нибудь в доках, описывающих внутреннее устройство libpcap.

в Linux libpcap - это обертка над пакетными сокетами (AF_PACKET)
вроде библиотека является opensource
в чем проблема посмотреть реализацию?

> packets ‘‘dropped by kernel’’

не из ядра до этих пакетов не добраться никак, т. к они дропятся 
тут
http://rswiki.csie.org/lxr/http/source/net/core/dev.c?v=linux-2.6.25#L1784
(в контексте обработчика аппаратного прерывания NIC)

> Тут выбор какой: или приоритет отдаётся tcpdump'у и тормозится 
> сетевой интерфейс, пока не будут обработаны все перехваченные 
> пакеты, или tcpdump получает не все пакеты

если пройдена netif_rx() и сгенерировано отложенное прерывание NET_RX_SOFTIRQ, то tcpdump, как и любой другой зарегистрированный снифер получит _все_ пакеты

> в чем проблема посмотреть реализацию?

Ну вот и смотри, у меня есть занятия поинтереснее. Чем мог - помог.

> не из ядра до этих пакетов не добраться никак

Здорово, что ты знаком с такими подробностями, но ведь ты же дал ссылку на исходники ядра ;) То есть ядром и дропаются, "dropped by kernel" - нормально фраза построена.

> если пройдена netif_rx() и сгенерировано отложенное прерывание NET_RX_SOFTIRQ

Ок, а если tcpdump не успевает выводить на терминал информацию о пакетах ("терминал" - через ssh по модему 56Kbit/s), а канал сниффим гигабитный с загрузкой 100%, что будет :)

ну и что пакеты будут цепляться за sk_receive_queue код тут http://rswiki.csie.org/lxr/http/source/net/packet/af_packet.c?v=linux-2.6.25#...

и по мере доступности терминала будут обрабатываться другое дело, что это может съесть всю память системы

кроме того, это проблема _tcpdump_, а не пакетных сокетов ;)

> Здорово, что ты знаком с такими подробностями, но ведь ты же дал 
> ссылку на исходники ядра ;) То есть ядром и дропаются, "dropped by 
> kernel" - нормально фраза построена.

ну и?

То есть голос подан в пользу OOM (в ядро не пускать!) :) А я говорю, что libpcap держит буфер фиксированного размера, и если приложение не успевает этот буфер опустошать, пакеты дропаются. А если напрямую использовать PF_PACKET, то работает другой вариант - "тормозится" интерфейс, то есть если бы мы написали самописный снифер наподопие tcpdump, но работающий через packet-сокеты, то в моём примере гигабитное соединение на время прослушивания превратится по скорости в модемное 56k.

Поэтому на исходный пост я рекомендую PF_PACKET. Об этом ведь разговор.

> ну и?

что "ну и"? Ты сказал:

>> не из ядра до этих пакетов не добраться никак

я поправил. вопрос иcчерпан.

> то работает другой вариант - "тормозится" интерфейс

засчет чего?
тут накладные расходы по сути только на вызов packet_rcv() и добавление пакета в приемный буфер сокета
я не думаю, что это настолько снизит пропускную способность
или я не прав?

> засчет чего?

Потому что буфер для необработанных пакетов в ядре ограничен, и они будут дропаться (возможно, там, где ты показал, с лимитом netdev_max_backlog) - out of memory на ровном месте никто не допустит. Место в буфере освобождается по мере считывания из packet-сокета. В примере считывание происходит со скоростью 56Кбит/сек, соответственно эффективная скорость считывания данных с гигабитного канала тоже будет 56Кбит/сек. Если мы будем скачивать что-то через TCP, который будет успешно бороться с дропнутыми пакетами, то получим примерно такую скорость.

ok

при такой скорости считывания мы все же рискуем out of memory получить ;)

> при такой скорости считывания мы все же рискуем out of memory получить ;)

oom? А вот это не похоже на ограничение длины очереди?

http://rswiki.csie.org/lxr/http/source/net/packet/af_packet.c?v=linux-2.6.25#...

Вообще, похоже, я неправ на счёт того, что packet-сокеты блокируют считывание пакетов с интерфейса. Они просто страдают тем же недугом, что и libpcap - у каждого сокета своя очередь ограниченного размера.

Если нужно "блокирующее" поведение, то можно воспользоваться целью QUEUE (или NFQUEUE) в iptables - не сложнее в использовании, чем packet-сокеты. С её помощью можно писать эдакие userspace-расширения для фильтрации пакетов - вот тогда уже точно ни один пакет не ускользнёт.

Кстати, начинаю вспоминать, как я порт arp-спуфера под linux делал. Было комби: отправлял пакеты через packet-сокет, а читал через цель QUEUE. Работало...

> А вот это не похоже на ограничение длины очереди? 

ну размер как раз можно поставить максимальный 
(~0) >> 1
через setsockopt() ;)
вот тогда то будет OOM при малой скорости считывания

да, еще надо увеличить /proc/sys/net/core/rmem_max

То есть по дефолту всё ок... Ну тогда я спокоен :)

не все ;)

по дефолту значение rmem_max лежит от 100K до 200K, а это довольно мало

Говорите что ядро будет дропать пакеты если ему памяти не хватит. А что оно должно по-вашему делать? Просто не зевайте и вовремя забирайте пакеты.

Да, но тут дело в том, что некоторые программы получат пакеты, которые не получит снифер, запущенный на той же машине. За это и перетёрли.