Optimales Snaplen für PCAP Live Capture

Question

Beim Benutzen pcap_open_live Um von einer Schnittstelle zu schnüffeln, habe ich viele Beispiele gesehen, die verschiedene Zahlen verwenden als SNAPLEN Wert, der von BUFSIZ (<stdio.h>) zu "magischen Zahlen".

Würde es nicht sinnvoller sein, als Snaplen die MTU der Schnittstelle zu setzen, von der wir erfassen? Auf diese Weise könnten wir mehr Pakete gleichzeitig in PCAP -Puffer einfügen. Ist es sicher anzunehmen, dass die MRU der MTU gleich ist?

Gibt es ansonsten eine nicht exotische Möglichkeit, den Snaplen-Wert festzulegen?

Vielen Dank

Answer 1

Die MTU ist die größte Nutzlast Größe, die der Linkschicht übergeben werden könnte; Es enthält keine Link-Schicht-Header. So wäre es beispielsweise bei Ethernet 1500, nicht 1514 oder 1518 und wäre nicht groß genug, um ein Ethernet-Paket in voller Größe zu erfassen.

Darüber hinaus enthält es keine Metadaten -Header wie den Radiotap -Header für 802.11 -Funkinformationen.

Und wenn der Adapter irgendeine Form von Fragmentierung/Segmentierung/Zusammenbau ausführt, werden die Pakete, die dem Adapter übergeben oder vom Adapter empfangen werden viel größer als die MTU.

Das Anpassen von mehr Paketen im PCAP-Puffer gilt nur für die maßstabulierten TPACKET_V1- und TPACKET_V2-Erfassungsmechanismen unter Linux, die Paketschlitzen fester Größe haben. Andere Erfassungsmechanismen reservieren für jedes Paket keinen Slot mit maximaler Größe, sodass eine kürzere Snapshot-Länge keine Rolle spielt. Für tpacket_v1 und tpacket_v2 könnte eine kleinere Snapshot -Länge einen Unterschied machen, obwohl zumindest für Ethernet libpCap 1.2.1 Versuche, so gut sie können, eine geeignete Pufferschlitzgröße für Ethernet zu wählen. (TPacket_v3 scheint nicht die festen Slots mit fester Größe zu haben. In diesem Fall hätte es dieses Problem nicht, aber es erschien erst in letzter Zeit in offiziell veröffentlichten Kerneln, und es gibt noch keine Unterstützung für IT in libpcap.)