Оптимальный Snaplen для PCAP Live Capture

Question

Когда используешь pcap_open_live Чтобы нюхать из интерфейса, я видел много примеров, использующих различные числа как SNAPLEN ценность, начиная с BUFSIZ (<stdio.h>) к «волшебным числам».

Разве не имеет смысла установить, как Snaplen MTU интерфейса, из которого мы захватываем? Таким образом, мы могли бы установить больше пакетов одновременно в буфере PCAP. Можно ли предположить, что MRU равен MTU?

В противном случае, есть ли неэксотический способ установить значение Snaplen?

Спасибо

Answer 1

MTU - самый большой полезная нагрузка размер, который может быть передан слою ссылки; Он не включает в себя какие-либо заголовки Leank-Layer, поэтому, например, в Ethernet это будет 1500, а не 1514 или 1518, и не будет достаточно большим, чтобы захватить полноразмерный пакет Ethernet.

Кроме того, он не включает в себя какие -либо заголовки метаданных, такие как заголовок RadioTAP для радио).

И если адаптер выполняет какую -либо форму разгрузки фрагментации/сегментации/повторной сборки, пакеты, передаваемые адаптеру или полученные от адаптера, могут еще не быть фрагментированы или сегментированы, или могли быть повторно собранные, и, как таковые, могут быть много больше, чем MTU.

Что касается установки большего количества пакетов в буфере PCAP, это относится только к механизмам захвата TPACKET_V1 и TPACKET_V2 в Linux, которые имеют слоты пакетов с фиксированным размером; Другие механизмы захвата не останавливают слот максимального размера для каждого пакета, поэтому более короткая длина снимка не будет иметь значения. Для tpacket_v1 и tpacket_v2 меньшая длина снижения может иметь значение, хотя, по крайней мере, для Ethernet, Libpcap 1.2.1, как можно лучше, выбрать подходящий размер буферного слота для Ethernet. (Tpacket_v3, похоже, не имеет слотов с фиксированным размером для каждого размера, и в этом случае у него не было бы этой проблемы, но он появился только в официально выпущенных ядрах в последнее время, и никакой поддержки еще не существует в Libpcap.)