The equipment generating said packets includes the length of the padding in the IP header's total length field. Suppose I'm receiving IPv4 UDP packets whose payload is less than 18 octets, so when they are transmitted over Ethernet they have some trailing padding. Who is at fault here? Is it a bug in Wireshark and in my understanding of RFC 768? Is it a bug in Windows/Linux? Is the question moot because such packets are illegal to begin with, in which case Wireshark should have marked them as such, and Windows/Linux should have discarded them in any case? But, for my packets, the result is obviously different. For normal packets, this nets the same value as the length field from the UDP header, so it doesn't matter. When they verify the checksum, they set the pseudo-header's length to the total length from the IP header minus its size. On the other hand, the network stacks of both Windows and Linux do something else. This is also what Wireshark's UDP parser does. If I understand RFC 768 correctly, the length in the pseudo-header should be the UDP length, so 15 for a 7-octet-long payload - just like the length field inside the actual UDP header. Regardless, both Windows and Linux do not discard such packets, so it makes sense to ask how should the UDP checksum be computed for them. Minor question: Am I right to understand that according to RFC 894 such packets are considered invalid to begin with? This is faulty behavior to be sure, but I cannot get rid of the device or modify it, so I have to deal with it. So, for example, a packet with a 7-octet-long payload will not have an IP total length of 35, but rather 46. Between the packets' source and my receiver sits a custom device which, among other things, modifies the IP header so that its total length field will include the Ethernet padding.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |