On Jan 20, 2004, at 7:36 AM, 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) 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.
That's because, typically, the reported length *IS* the UDP size, even
for packets that, when the Ethernet header is included, are shorter
than the minimum Ethernet packet size. The total length field in the
IP header is supposed to include the length of the IP header (20 plus
IP options, if any), the UDP header (8), and the UDP payload, so for a
UDP packet with no IP options and 4 bytes of UDP data, that'd be
20+8+4, or 32. That length should *NOT* include any trailer padding to
make the packet have a size >= the minimum Ethernet packet size - if
the packet is routed over a non-Ethernet network, that padding doesn't
need to be present, and if it then reaches another Ethernet it'll get
added back.
The length field in the UDP header thus appears to be redundant - note
that the TCP header doesn't include a segment length field.
I've checked in a change to use the header length from the UDP header
(if it's less than the reported length - it needs to somehow handle the
case where the header length is *greater* than the reported length,
either because the packet is fragmented and hasn't been reassembled or
because the packet is bogus).