1

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. 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. So, for example, a packet with a 7-octet-long payload will not have an IP total length of 35, but rather 46. 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.

Minor question: Am I right to understand that according to RFC 894 such packets are considered invalid to begin with?

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.

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. This is also what Wireshark's UDP parser does.

On the other hand, the network stacks of both Windows and Linux do something else. When they verify the checksum, they set the pseudo-header's length to the total length from the IP header minus its size. For normal packets, this nets the same value as the length field from the UDP header, so it doesn't matter. But, for my packets, the result is obviously different.

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?

Improve this question

1 Answer 1

Reset to default
0

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. The equipment generating said packets includes the length of the padding in the IP header's total length field. So, for example, a packet with a 7-octet-long payload will not have an IP total length of 35, but rather 46.

Where did you get that idea?

Ethernet is a layer-2 protocol, and it doesn't know about the layer-3 protocol. Ethernet can carry any number of layer-3 protocols (IPv4, IPX, IPv6, AppleTalk, etc.), and it knows nothing about the layer-3 protocols or headers for the layer-3 protocols, so it has no way to change a field in a layer-3 header.

Conversely, the layer-3 protocol has no idea which layer-2 protocol (ethernet, Wi-Fi, token ring, frame relay, ATM, PPP, etc.) carries its packets.

The ethernet padding is for ethernet frames at layer-2, not the layer-3 packets.

Edit:

You completely changed the meaning of the question, which is very bad form, especially when you already got an answer to the original question. You should start a new question for a different question, not change the original question.

The device in the middle that changes the IPv4 header total length field must change the IPv4 header checksum, and the UDP checksum (if it used, but it is optional for IPv4, and it is often not used) is not computed using the IPv4 total length field or checksum, so it would not change.

If the IPv4 total length field is changed, then IPv4 will send its original payload (the UDP datagram) and the padding to UDP.

The UDP header has its own length field. If the device does not modify this field, then the UDP will be correct and UDP will send the correct number of octets (not including the padding) to the application, but if the device changes the UDP length field, then the UDP checksum will be recomputed and UDP will send the original UDP payload, plus the padding to the application, possibly causing a problem for the application.

Improve this answer
3
  • You're completely right of course, and yet that's exactly the situation I'm dealing with. The custom equipment in question receives a normal Ethernet frame, parses and modifies the IP header inside of it (not to mention other changes on deeper layers), and then sends it onward. I've never said that this behavior is sane, but it is what it is. I've modified my question to clarify this somewhat. In any case, these are the packets I have to deal with in practice, and Windows/Linux do accept them, so my main question - about the checksum - still stands.
    – Corvus Corax
    Dec 7, 2017 at 19:06
  • Questions about networks which you do not directly control are off-topic here, so if you do not control this device, it is really off-topic here.
    – Ron Maupin ♦
    Dec 7, 2017 at 19:16
  • I haven't changed the intention of the question at all. Since I have no control over the problematic device, it doesn't make any difference whether it corrupts normal packets or just generates faulty ones on its own. But as for questions about networks not directly under my control, I didn't know that's off-topic here, so I do apologize for it. In any case I will mark your answer as correct - it has confirmed my suspicions that the way Windows and Linux verify the checksums of such packets seems buggy, since they have no business looking at the IP header when validating the UDP layer.
    – Corvus Corax
    Dec 7, 2017 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.