Bug 147339 - NetworkManager sends UDP packets with broken checksum
NetworkManager sends UDP packets with broken checksum
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Depends On:
  Show dependency treegraph
Reported: 2005-02-07 09:55 EST by David Woodhouse
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-18 13:50:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
pcap file showing broken packets. (2.43 KB, application/octet-stream)
2005-02-07 09:57 EST, David Woodhouse
no flags Details
checksum patch (317 bytes, patch)
2005-02-10 09:22 EST, David Woodhouse
no flags Details | Diff

  None (edit)
Description David Woodhouse 2005-02-07 09:55:25 EST
See attached tcpdump. See broken UDP checksum on the DHCP Request

14:52:42.807355 IP (tos 0x0, ttl  64, id 38089, offset 0, flags
[none], proto 17, length: 349) > [bad udp cksum fe01!] BOOTP/DHCP, Request from
00:0a:95:c4:f1:c8, length: 321, xid:0x46e052a6, secs:10, flags: [none]
          Client Ethernet Address: 00:0a:95:c4:f1:c8
            VC:"Linux 2.6.10-1.1127_FC4.dwmw2 ppc"
Comment 1 David Woodhouse 2005-02-07 09:57:01 EST
Created attachment 110724 [details]
pcap file showing broken packets.
Comment 2 Dan Williams 2005-02-10 00:19:37 EST
Dave, does this appear to be only on PPC?  It may be a missing htonl()
somewhere...  I'm fairly sure that ethereal thinks the packets are OK on i386.

Peter: did you see anything in the DCHP code when you were looking through it
that might be wrong?
Comment 3 David Woodhouse 2005-02-10 07:39:52 EST
It's unlikely to be hton[sl] because that's a NOP on PPC anyway. But it does
look a bit like an endianness problem. The difference between the checksum and
what it _ought_ to be is always 0x1fe afaict -- we added 2 to the wrong byte.

For example, 'Checksum: 0x49f9 (incorrect, should be 0x4bf5)'

This happens on the DHCP Request packets but not DHCP Discover.
Comment 4 David Woodhouse 2005-02-10 09:22:53 EST
Created attachment 110920 [details]
checksum patch

The checksum routine is still not ideal -- it won't handle being given a buffer
which isn't aligned. Can you guarantee that your buffers will always be
correctly aligned?
Comment 5 David Woodhouse 2005-02-10 09:25:10 EST
That patch is purely empirical, btw. I haven't checked that it's correct.

Now I'm trying to work out WTF NetworkManager is doing to the interface to break
IPv6. IPv6 is _automatic_ -- the kernel picks up the addresses for itself. But
after NetworkManager brings up the interface, it seems to be hidden from the
IPv6 stack - it's even absent from /proc/sys/net/ipv6/conf/ .

If we can just get IPv6 working, I could start to use NetworkManager.  
Comment 6 Dan Williams 2005-02-10 09:40:21 EST
The patch seems to be correct, from what I can find if the packet length is not
even, you have to copy the last value into a 16-bit zeroed value and checksum
that.  Previously of course, the code was using u_char and probably picking up
some other random field next to the UDP header.
Comment 7 Dan Williams 2005-02-10 09:42:41 EST
WRT to the IPv6 stuff, is there no way to bump the kernel to tell it to send
those packets again?  There's no guarantee that the user actually has a
connection when the device is brought up, on wireless for example you don't have
a connection until NetworkManager actually gets one for you, and not all drivers
do netif_carrier_on(), so how does the kernel actually think it can get the
timing of this right?  NetworkManager is the one here that knows when you're
connected by a fairly complicated set of heuristics, the kernel has no clue and
probably doesn't want to.
Comment 8 Dan Williams 2005-02-10 11:15:43 EST
Fix added to CVS for the checksum stuff, and also we now flush only "scope
global" and "scope site" addresses with /sbin/ip.
Comment 9 Dan Williams 2005-02-18 13:42:30 EST
Your further patch applied, should be fixed now.  Can you confirm?
Comment 10 David Woodhouse 2005-02-18 13:50:08 EST
Yeah, s'fine now. Thanks.

Note You need to log in before you can comment on or make changes to this bug.