On Tue, Jan 20, 2004 at 10:36:49AM -0500, Robert Morin wrote:
> I am testing an ethernet driver and I notice something odd with the UDP
> checksum with
> small IPv4 packet. If I send a UDP packet with only 4 bytes in the data
> and padding with 0 to have a valid IP packet (64 bytes)
There is no mimimum length of 64 bytes for IP packets.
There is a minimum length of 64 bytes, including the CRC, for *Ethernet*
packets. However, the padding in that is *not* included in the IP
packet.
I.e., if you sent a UDP-over-IPv4 packet with no IP options (so that the
IP header is 20 bytes) with 4 bytes of UDP data, so that you have 20
bytes of IPv4 header, 8 bytes of UDP header, and 4 bytes of UDP data,
the total length field in the IPv4 header would be 20+8+4 or 32.
If you sent that packet over Ethernet, the length of the *Ethernet*
packet would be 64 bytes, including the CRC - but the length in the IPv4
header would still be 32. The padding of 64 - (14+32) = 18 bytes would
*not* be counted in the IPv4 header.
> then I notice that the UDP checksum is computed using the length of
> the UDP data + the size of the padding.
>
> I check in the code (in packet_udp.c function dissect_udp()) and the
> size used for
> the UDP checksum is the reported_len and not the upd size.
The size used for the UDP checksum is the reported length of the tvbuff
handed to the UDP dissector, which *IS* the UDP size - i.e., for any
packet with a valid IPv4 header, so that the "total length" field is the
sum of the length of the IPv4 header and the length of the IPv4 payload,
i.e. 8 plus the length of the UDP data, the reported length of the
tvbuff handed to the UDP dissector would be 12. The IPv4 dissector
changes the reported length of the tvbuff on which it works to include
only the data specified by the total length - i.e., *not* to include any
Ethernet padding.