Red Hat Bugzilla – Bug 156118
phantom bad UDP packets detected by NetworkManager
Last modified: 2007-11-30 17:11:04 EST
Description of problem:
When I try to connect to a wireless network using STABLE-0.3 branch of CVS, I
often am unable to. NetworkManager reports "Reply message was not UDP
(ip_hdr->protocol = 6, IPPROTO_UDP = 17), won't use it." (Full NM log attached)
However, when I run ethereal concurrently, it shows no traffic on the wlan0
interface, except for the outgoing UDP DHCP packets, which never receive a response.
One thing I have noticed is that if i replug and unplug the wired ethernet cable
repeatedly, sometimes NM will be able to grab a wireless IP when I plug the
Also, once this happens, plugging the ethernet cable back in does not result in
NM receiving an event to bring up the wired interface.
Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN
Controller (rev 03) on wlan0 under ndiswrapper driver
Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet
PCI Express (rev 01) on eth0 under tg3 driver
Created attachment 113726 [details]
I'm not exactly sure why, but it seems to be working now, even with no changes
to the NM code...
The only thing I can think that I changed was that I set the BIOS to do a full
POST on boot to workaround an ndiswrapper bug (loading ndiswrapper freezes the
machine if boot without power cable plugged in and the BIOS only does a minimal
post). for reference, my laptop is a Dell Latitude D810, but I've also seen the
NM bug on a Dell Inspiron 8600.
wierd... all NM is doing is reading from a socket with recv()-type calls. Is
there possibly a "dhclient" running at the same time as NetworkManager is
running? If you've got any of your devices marked to start on boot, that might
be the cause of a dhclient process running.
I shouldn't have any other dhcp client running at the same time... here's my
/etc/network/interfaces (running ubuntu, not fedora):
iface lo inet loopback
iface eth0 inet dhcp
iface wlan0 inet dhcp
I think the issue here is that the code is simply pulling packets from the
networking stack. Unfortunately, because we're doing that at the packet layer
and _not_ the ethernet layer, we have no way of masking out traffic on other
interfaces. So, the DHCP code will actually receive traffic on eth0 when its
trying to do DHCP on eth1.
Now, this is OK because the code checks the 'xid' of the message, and discards
it if its not the same as the DHCP request we sent out. But it does mean more
spew in the logs. I might try to counteract this by taking out some of the
Fixed with NM 0.6.x in FC6 and later...