pcap struct pcap_pkthdr len gegen caplen

Lesezeit: 2 Minuten

Wir schnüffeln Pakete mit libpcap unter Linux. Der Header, den wir auf jedem Paket erhalten, sieht so aus:

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};

Nun, nach meinem Verständnis ist caplen die Länge der Daten, die wir erfasst haben, während len die Länge des Pakets auf dem Draht ist. In einigen Fällen (z. B. wenn beim Öffnen des pcap-Geräts snaplen zu niedrig eingestellt wird) erfassen wir möglicherweise nur Teile des Pakets, diese Länge ist ‘caplen’, während ‘len’ die ursprüngliche Länge ist. Daher sollte caplen gleich oder kleiner als len sein, aber niemals größer als len.

Ist das ein richtiges Verständnis? Wir sehen caplen > len auf einigen Rechnern

  • Sie sollten das pcap, das dieses Problem auslöst, auf pcapr.net posten, es wäre ziemlich interessant. Ich persönlich habe das noch nie gesehen.

    – Bortzmeyer

    29. September 2009 um 20:42 Uhr

Ihr Verständnis ist korrekt, zumindest basierend auf der pcap-Manpage.

caplen ist die Datenmenge, die Ihnen in der Erfassung zur Verfügung steht. len war die tatsächliche Länge des Pakets.

Mir sind keine Fälle bekannt, die Ihnen ein caplen > len geben würden. Normalerweise scheinen sie gleich zu sein, da mein Snaplen ausreichend hoch ist.

Benutzeravatar von wanttomasterpython
will Python beherrschen

Ja, Ihr Verständnis ist richtig caplen ist immer kleiner als Len . Manchmal müssen wir nicht das ganze Paket erfassen.

Aber warum würdest du nicht das ganze Paket einfangen, wenn du die Chance dazu hättest?

Denn bei starkem Netzwerkverkehr wäre das keine gute Idee.

Verlieren wir nicht tatsächlich wertvolle Daten, wenn wir nicht das gesamte Paket erfassen, das auf der Leitung erscheint?

Nein. Tatsächlich hängt es von Ihrem Zweck ab. Wenn Sie Pakete nur basierend auf den Protokollen und der Anwendung klassifizieren möchten, für die sie bestimmt sind, benötigen Sie nur etwa 14 Bytes (Ethernet) plus 20 Bytes (Ip) + plus weitere 20 (Tcp). somit benötigt man scheinbar nur 54 Bytes an Daten, um Pakete basierend auf Protokollen zu klassifizieren, wodurch viel Last und Zeit beim Reduzieren der Verarbeitungsgröße gespart wird pcappkthdr->len zu pcappkthdr->caplen 🙂

Zu deiner Frage bzgl snaplen größer sein als len manchmal:

Wenn die Header in den Paketen beschädigt sind (was bedeutet, dass die Headerlength-Werte irgendwie durcheinander gebracht wurden), dann wäre die erfasste Länge größer als die tatsächliche Länge des Pakets.

Wenn caplen > len, ist das ein Fehler; Welche Version von libpcap verwendest du?

  • Ich stehe vor dem gleichen Problem für libpcap0.8 + usbmon unter Ubuntu 20.04

    – Marcelo Neves

    16. Februar um 17:23 Uhr

  • Das könnte libpcap bug 808 (github.com/the-tcpdump-group/libpcap/issues/808), die jetzt behoben ist.

    – Benutzer16139739

    20. Februar um 19:10 Uhr


1392380cookie-checkpcap struct pcap_pkthdr len gegen caplen

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy