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?