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 cable in... Also, once this happens, plugging the ethernet cable back in does not result in NM receiving an event to bring up the wired interface. System information: 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] NM log
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): auto lo 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 debug messages.
Fixed with NM 0.6.x in FC6 and later...