Ethereal-users: RE: [Ethereal-users] UDP checksum with less than 16 bytes

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Robert Morin" <morinr@xxxxxxxxxx>
Date: Fri, 23 Jan 2004 16:31:16 -0500
Thanks for the info. We read all the RFC at least three times trying to
figure out why ethereal was giving an invalid checksum on the UDP.

Robert Morin
embVUE
Montreal



-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx] 
Sent: 22 janvier 2004 16:19
To: Robert Morin
Cc: ethereal-users@xxxxxxxxxxxx
Subject: Re: [Ethereal-users] UDP checksum with less than 16 bytes



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).