Wireshark zeigt mir Pakete mit weniger als 64Bytes

[sirius]

Mein Programm (basierend auf WinPCap) und auch Wireshark (was ja auch auf WinPCap basiert) zeigen mir Datenframes (ARP oder auch TCP/IP) mit 50 bis 60 Byte an.
Ein EthernetFrame soll aber mindestens 64 Byte haben und soweit ich verstanden hab ohne die (ca 8 Bytes) Präambel.

Wie kann das sein. Wo ist mein Denkfehler?

Diese Verhalten zeigt sich bei einer wired LAN-Verbindung zu einem Cisco-Router als auch über einen openVPN-Adapter zu mdex. Und ich extrapoliere, dass dies bei allen anderen Netzwerkadaptern wohl auch so ist.

Unterschlägt WinPCap da etwas?

Vielen Dank für Antworten und Links.



(Früherer Post)

[Valle]

Hallo,

ich meine mich daran zu erinnern, dass kleinere Packete einfach mit Null-Bytes aufgefüllt werden.
Die Länge des Packets steht IIRC ja im IP-Header.

... oder? :gruebel:

Liebe Grüße,
Valle

[sirius]

Zitat:

Zitat von Valle

Hallo,

ich meine mich daran zu erinnern, dass kleinere Packete einfach mit Null-Bytes aufgefüllt werden.

Genau das meine ich. Aber ich finde nirgends in der Doku zu WinPCap, dass die das automatisiert wegkürzen. Die wissen ja gar nicht, was Sie wegkürzen.

Zitat:

Die Länge des Packets steht IIRC ja im IP-Header.

Das ist aber schon Layer 3. So ziemlich jedes Protokoll (auch TCP) hat eine Angabe zur Länge oder zumindest ein Paket-Ende-Zeichen. Aber das eben nur zur Paketlänge des entsprechenden Protokolls.

Edit: Und was waäre dann bspw. mit ARP?

[Sharky]

Ich meine das ein Ethernetframe kleiner als 64Byte sein "kann". ABER dann ist keine Kollisionserkennung nach CSMA/CD mehr möglich.

[sirius]

Zitat:

Zitat von Sharky

Ich meine das ein Ethernetframe kleiner als 64Byte sein "kann". ABER dann ist keine Kollisionserkennung nach CSMA/CD mehr möglich.

Du meinst, der Sender schickt das Frame los und interessiert sich nicht dafür, ob es überhaupt gelesen werden kann?

Ich hab halt noch nie etwas anderslautendes gelesen, als dass ein Frame min 64 Bytes lang sein muss. Vielleicht gibts ja auch ein neues Verfahren. Ausserdem habe ich ja nicht 100m Kabel von mir zum Router, sodass die RTDT sicher auch ein kleineres Frame zulassen würde. Aber wo legt man das fest, und dann müsste ja auch irgendetwas dazu im Netz zu finden sein.

[Valle]

Hi,

schaut euch bitte mal das RFC1042 ("A Standard for the Transmission of IP Datagrams over IEEE 802 Networks") auf Seite 4 an. Eventuell müsste das die Fragen klären?

Liebe Grüße,
Valle

[sirius]

Zitat:

Zitat von Valle

Hi,
schaut euch bitte mal das RFC1042 ("A Standard for the Transmission of IP Datagrams over IEEE 802 Networks") auf Seite 4 an. Eventuell müsste das die Fragen klären?

Da steht genau, dass was ich schon wusste, oder?

Zitat:

IEEE 802 packets may have a minimum size restriction. When necessary, the data field should be padded (with octets of zero) to meet the IEEE 802 minimum frame size requirements. This padding is not part of the IP datagram and is not included in the total length field of the IP header.

[BUG]

Zitat:

IEEE 802 packets may have a minimum size restriction. When necessary, the data field should be padded (with octets of zero) to meet the IEEE 802 minimum frame size requirements. This padding is not part of the IP datagram and is not included in the total length field of the IP header.

Evtl. werden solche Füllbytes einfach nicht in Wireshark angezeigt? Wenn die Länge im Header steht, ist ja auch klar was abgeschnitten werden darf.

[sirius]

Zitat:

Zitat von BUG

Zitat:

IEEE 802 packets may have a minimum size restriction. When necessary, the data field should be padded (with octets of zero) to meet the IEEE 802 minimum frame size requirements. This padding is not part of the IP datagram and is not included in the total length field of the IP header.

Evtl. werden solche Füllbytes einfach nicht in Wireshark angezeigt? Wenn die Länge im Header steht, ist ja auch klar was abgeschnitten werden darf.

Ich benutze ja nicht Wireshark direkt, sondern WinPcap (das auch von Wireshark benutzt wird und für mich zur Verifizierung genutzt wird)
Deswegen schneidet nicht WireShark, sondern WinPCap ab. Und außerdem gibt es ja nicht nur IP-Pakete.

[Valle]

Vielleicht wird das auch noch viel weiter unten verarbeitet?
Wer sagt, dass nicht die Netzwerkkarte schon das Padding abschneidet?

@sirius: Weiter im Text sind auch noch andere minimal-Längen von Packeten definiert. Darum geht es mir.

Liebe Grüße,
Valle

[sirius]

Zitat:

Zitat von Valle

Wer sagt, dass nicht die Netzwerkkarte schon das Padding abschneidet?

Das wäre auch eine Möglichkeit. Allerdings müsste dazu die Netzwerkkarte min. das Layer-3-Protokoll (bspw. "IP") analysieren um das herauszufinden.
Ich will halt nur sagen, dass alle Netzwerkadpater sich nicht um IP o.ä. kümmern. Das ist ja der Grund für die Trennung der einzelnen Schichten bei OSI bzw. TCP/IP-Ref. Die Netzwerkkarte interessiert sich nur für Layer 1. ein zugehöriger Netzwerkadapter für Layer 2. Und genau hier sind die Frames, die nicht kleiner sein dürfen als 64 Bytes (bzw. 46 Byte Inhalt + Header + Chksum). Bei EthernetII-Frames gibt es da auch nirgendwo eine Längenangabe bzw. eine Möglichkeit zu unterscheiden, was Daten- und was Padding Byte sind. Das kriegt man erst raus, wenn man das darunterliegende Protokoll analysiert. Das geht natürlich. Wenn der Typ ARP ist, ist die Länge klar definiert (konstant) und der Typ "ARP" steht ja im Layer-2-Header. Aber auch die TCP-Pakete (Handshakes) sind kleiner als 64 Byte im Frame. Dazu müsste man aber das IP-Protokoll analysieren. Es ist gut möglich, dass WinPCap dies zumindest bei ihm bekannten Protokollen macht. Aber warum? Dann sollte das wenigstens dokumentiert sein. Deswegen glaube ich nicht, dass die das machen.
Ideen, warum das so sein könnte, habe ich auch viele. Ich dachte nur, es weis hier jemand ganz sicher.
[/quote]

Zitat:

@sirius: Weiter im Text sind auch noch andere minimal-Längen von Packeten definiert. Darum geht es mir.

Ich suche nochmal, jetzt mache ich erstmal Feierabend.


Danke erstmal für eure Anregungen.