From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060202 Fedora/1.5.0.1-2 Firefox/1.5.0.1 Description of problem: After a recent (2-3 weeks ago) update of my rawhide system, NetworkManager quit having the ability to connect to my wireless system. This appears to be a regression, as it was rock solid until the update. I can hand enter ifconfig/iwconfig/route commands and get the hardware connected, so I don't believe that the hardware is to blame - and besides, it still works in that other evil OS starting with "W". Version-Release number of selected component (if applicable): NetworkManager-0.5.1-10.cvs20060205 How reproducible: Always Steps to Reproduce: 1. Click nm-applet icon and select network 2. Enter wep key and essid 3. NM isn't able to connect Actual Results: NetworkManager doesn't connect. I don't know if it's valid or not, but looking at iwconfig of the interface, it shows that the wep key is not being used. wlan0 IEEE 802.11g ESSID:"mynetwork" Mode:Managed Frequency:2.412 GHz Access Point: FF:FF:FF:FF:FF:FF Bit Rate:54 Mb/s Tx-Power:25 dBm RTS thr:2347 B Fragment thr:2346 B Encryption key:off Power Management:off Link Quality:100/100 Signal level:-37 dBm Noise level:-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Expected Results: NM should be able to connect. Additional info: Until about 2-3 weeks ago this has been working flawlessly on my laptop. This is a regression that had occurred after a yum update. This does not appear to be a problem with my wireless hardware, as I can still issue: ifconfig wlan0 192.168.1.150 iwconfig wlan0 key 0 restricted ffffffffff iwconfig wlan0 essid mynetwork route add default gw 192.168.1.1 and get up and running. tail -f /var/log/messages: Feb 7 10:27:30 localhost ntpd[2063]: kernel time sync disabled 0041 Feb 7 10:28:36 localhost ntpd[2063]: kernel time sync enabled 0001 Feb 7 17:29:08 localhost avahi-daemon[2175]: Withdrawing address record for 192.168.0.103 on wlan0. Feb 7 17:29:08 localhost avahi-daemon[2175]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.0.103. Feb 7 17:29:08 localhost avahi-daemon[2175]: IP_DROP_MEMBERSHIP failed: No such device Feb 7 17:29:08 localhost avahi-daemon[2175]: iface.c: interface_mdns_mcast_join() called but no local address available. Feb 7 17:29:08 localhost avahi-daemon[2175]: Interface wlan0.IPv4 no longer relevant for mDNS. Feb 7 10:29:10 localhost dhcdbd: Started up. Feb 7 10:29:11 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason Feb 7 10:29:26 localhost dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 Feb 7 10:29:33 localhost last message repeated 2 times Feb 7 10:29:43 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 Feb 7 10:29:51 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 Feb 7 10:29:51 localhost dhclient: DHCPRELEASE on wlan0 to 192.168.0.1 port 67 Feb 7 10:29:51 localhost dhclient: send_packet: Network is unreachable Feb 7 10:29:51 localhost dhclient: send_packet: please consult README file regarding broadcast address. Feb 7 10:33:36 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 Feb 7 10:33:44 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 Feb 7 10:33:58 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18 Feb 7 10:34:01 localhost dhclient: DHCPRELEASE on wlan0 to 192.168.0.1 port 67 Feb 7 10:34:01 localhost dhclient: send_packet: Network is unreachable Feb 7 10:34:01 localhost dhclient: send_packet: please consult README file regarding broadcast address.
I now believe this to be a dhclient related issue. Here is why. As stated in my initial report, I can bring up the wireless manually. If I do so, and instead of setting the ip address using ifconfig, I use dhclient to try to set it, I get these messages (nothing has changed on my dhcp setting on my router and it still works for other computers): Feb 10 12:03:43 localhost dhclient: Sending on LPF/wlan0/00:90:4b:55:cb:6b Feb 10 12:03:43 localhost dhclient: Listening on LPF/eth0/00:c0:9f:32:7e:0d Feb 10 12:03:43 localhost dhclient: Sending on LPF/eth0/00:c0:9f:32:7e:0d Feb 10 12:03:43 localhost dhclient: Sending on Socket/fallback Feb 10 12:03:43 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 Feb 10 12:03:43 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 Feb 10 12:03:50 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 Feb 10 12:03:50 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 Feb 10 12:03:59 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13 Feb 10 12:04:02 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 Feb 10 12:04:11 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 Feb 10 12:04:12 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 Feb 10 12:04:25 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13 Feb 10 12:04:27 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 Feb 10 12:04:38 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 Feb 10 12:04:39 localhost ntpd[2037]: synchronized to LOCAL(0), stratum 10 Feb 10 12:04:39 localhost ntpd[2037]: kernel time sync disabled 0041 Feb 10 12:04:42 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2 Feb 10 12:04:44 localhost dhclient: No DHCPOFFERS received. Feb 10 12:04:44 localhost dhclient: No working leases in persistent database - sleeping. Feb 10 12:04:44 localhost NET[2770]: /sbin/dhclient-script : updated /etc/resolv.conf Feb 10 12:04:44 localhost dhclient: No DHCPOFFERS received. Feb 10 12:04:44 localhost dhclient: No working leases in persistent database - sleeping.
Downgrading dhclient and dhcp to 3.0.3-18 fixes the issue of getting an ip address. It doesn't, however, fix the overall problem if I try to use NetworkManager to connect to the wireless. Now when I try to connect with NM, I get these messages: Feb 10 12:48:03 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason Feb 10 12:48:03 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason Feb 10 12:48:15 localhost NetworkManager: <WARNING> real_act_stage2_config (): Activation (wlan0/wireless): couldn't connect to the supplicant. I did look to make sure that wpa_supplicant was running.
I am experiencing this too. I noticed it when NetworkManager-0.5.1-10.cvs20060205 was released and has continued up to NetworkManager-0.5.1-13. If I install NetworkManager-0.5.1-8 again it starts working. I'm using the latest madwifi driver, but I don't think it is a driver issue since I can connect using ifup no problem.
I didn't have a copy of NetworkManager-0.5.1-8 so I grabbed NetworkManager-0.5.1-5.1 off my test2 disc. Once I downgraded, I was able to connect again (except for having to manually set the channel - an issue with my hardware). Note that I have tried with both the ndiswrapper (wlan0) driver and my bcm43xx driver that's in the current kernel. The result with both is that the latest NetworkManager will not connect.
This still occurs as of 0.5.1-15.cvs20060227. downgrading to NetworkManager-0.5.1-8.cvs20060131 still fixes the problem. NM sees the station, prompts for the passwork, attempts a connect, but times out. I've attached the /var/log/messages output from NM.
I would like to add a couple of comments: 1) Ignore what I said in comment #1. New versions of dhclient work iff NetworkManager and NetworkManagerDispatcher services are running. I wish someone could explain to me why. 2) In my scenario, it appears to be not a timeout, but the fact that NM apparently doesn't notice it's associated, so it trys to associate with something else (ff:f:ff:ff:ff:ff is the correct access point, the other is not): Feb 28 16:39:21 localhost kernel: SoftMAC: cannot associate without being authenticated, requested authentication Feb 28 16:39:21 localhost kernel: SoftMAC: Sent Authentication Request to ff:ff:ff:ff:ff:ff. Feb 28 16:39:21 localhost kernel: SoftMAC: Open Authentication completed with ff:ff:ff:ff:ff:ff Feb 28 16:39:21 localhost kernel: SoftMAC: sent association request! Feb 28 16:39:21 localhost kernel: SoftMAC: associated! Feb 28 16:39:21 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Feb 28 16:39:25 localhost kernel: SoftMAC: Scanning finished Feb 28 16:39:25 localhost kernel: SoftMAC: sent association request! Feb 28 16:39:25 localhost kernel: SoftMAC: sent association request! Feb 28 16:39:25 localhost kernel: SoftMAC: associated! Feb 28 16:39:28 localhost kernel: SoftMAC: Sent Authentication Request to 0f:0f:8f:8f:f4:ff.
Created attachment 125530 [details] Log of NetworkManager-0.5.1-18.cvs20060301 output This is the log output when I disconnect from my wired connection and NM attempts to connect to the wireless.
Still not working with NM 0.6.0. The log output is the same as above. Is there a way to turn on more debugging to see why NM is not able to bring ath0 up even though it can see all the access points out there when scanning and I can bring the network up statically? It would be really nice to resolve this as having NM working is critical for my laptop.
Although Brian and myself are having the same results, I'm suspecting that our problems might be slightly different. I just noticed this line as part of my logs. Can anyone tell me if this is normal? Notice "freq=0"? I notice in Brian's logs that this at least has the correct frequency. Mar 7 13:26:17 localhost NetworkManager: <information> wpa_supplicant(3190): Trying to associate with ff:ff:ff:ff:ff:ff (SSID='MyNetwork' freq=0 MHz)
*** Bug 183653 has been marked as a duplicate of this bug. ***
Well, I was able to fix my problem by downloading the source RPM for NetworkManager and removing the special-case-madwifi.patch. Looking at the patch its trying to change something to work around WPA support in madwifi. I use WEP for authorization. I'm also using the CVS drivers for madwifi so perhaps madwifi has "gotten their act in gear" and support WEXT too? I'm guessing though.
So it does seem that our two problems are different. I tried removing the patch and recompiling the rpm but it didn't help me at all.
Yep, madwifi-ng not working for me either, joining my home non-encrypted network. Anything I can do to help troubleshoot this?
My problem (I'm the original reporter) was solved in the rawhide updates sometime between Mar 21 and Apr 15. I was out of town and when I got back I did a huge rawhide update. NetworkManager started magically working again. I'm leaving this open, as others may not have been so lucky. By the way, I had just come across this thread about problems with bcm43xx and wpa_supplicant right before I did the update. I have a bcm43xx and wpa_supplicant support was rolled into later versions of NetworkManager that I could not use. https://lists.berlios.de/pipermail/bcm43xx-dev/2006-March/001473.html
I have this same problem on my IBM T43 with Atheros a/b/g wireless. I'm using MadWifi drivers for kernel 2.6.16_2080_fc5 and everything works fine if I use the command line (iwconfig...) but NetworkManager won't connect to wireless networks. Inspired by comment #14, I tried installing the latest NetworkManager in rawhide, <NetworkManager-0.6.2-1.fc6.i386>, along with the other two NetworkManager* rpms installed on my system. Problem not fixed.
I fixed the problem. I installed the NetworkManager source RPM, removed the special case madwifi patch (Patch0), built new RPMs and installed them. Everything works great now. Something is wonky with that patch and it should be looked at or removed.
Add to FC6Destop tracker
We no longer ship the patch. Closing...
What version of NetworkManager has the patch removed and will it be pushed to fc5?