Bugzilla – Bug 151151
wpa_supplicant fails to associate when using NetworkManager
Last modified: 2007-06-05 10:04:54 UTC
wpa_supplicant fails to associate when using NetworkManager. I have tried using orinoco (Prism2) and Atheros cards. In 9 out of 10 connection attempts wpa_supplicant seems to remain in state "scanning" until the 90s time-out of NetworkManager finally kills the connection attempt. The Remedy: We need wpa_supplicant 0.4.8 (currently we're at 0.4.7) Looks like NM and the UIs (nm-applet and KNetworkManager) are not to blame as it Just Works when using wpa_supplicant 0.4.8. I ask everyone to test the RPMS from mbuild nouse-thoenig-8. I have tried newest madwifi and wireless-tools which didn't improve my situation. Just after having wpa_supplicant 0.4.8 in charge made the sun shine bright. The system is a base install Beta3 with interesting packages being upgraded to the latest. wireless-tools-28pre13-11 madwifi-1451-2 NetworkManager-glib-0.5.1cvs20060214-2 NetworkManager-gnome-0.5.1cvs20060214-2 NetworkManager-debuginfo-0.5.1cvs20060214-2 NetworkManager-kde-debuginfo-0.1r5741-2 NetworkManager-0.5.1cvs20060214-2 NetworkManager-kde-0.1r5741-2 NetworkManager-devel-0.5.1cvs20060214-2 cc'ing the usual suspects.
I'm just happy using wpa_supplicant-0.4.7-5 madwifi-kmp-default-1451_2.6.16_rc3_2-2 madwifi-1451-2 NetworkManager-kde-0.1r5741-2 NetworkManager-glib-0.5.1cvs20060214-2 NetworkManager-0.5.1cvs20060214-2 NetworkManager-gnome-0.5.1cvs20060214-2 But I can confirm quite some problems with wpa_supplicant and will give the updated wpa_supplicant a try later today. The strange thing is, that it has been working quite well with the NetControl stuff. NM still seems to do some things different in that area...
(In reply to comment #1) > But I can confirm quite some problems with wpa_supplicant and will give the > updated wpa_supplicant a try later today. Can you please specify "quite some problems"?
(In reply to comment #2) > > But I can confirm quite some problems with wpa_supplicant and will give the > > updated wpa_supplicant a try later today. > > Can you please specify "quite some problems"? I'v seen the same problem you'v characterized above. After using NM to connect to a hidden WPA2-enc'ed network, it keeps on scanning. Stopping NM, killing the wpa_supplicant, unloading all ath_* modules and then loading all the stuff again, makes it work sometimes -- but not always ;(
I want to add that my experience matches Timo's and I would love to see a newer wpa_supplicant. I have had much better luck using wpa_supplicant's development branch (0.5.x) and many of those fixes are in 0.4.8. I know it is late, Joachim, but 0.4.8 would really save the day. ;-)
I gave 0.4.8 a try and I can not say it magically fixed all problem with madwifi. But at least it seems it doesn't break anything, so I don't have objections to updating. It's mainly a bugfix release anyway. Andreas, is this ok? It should be crypto-regulations safe.
No one claimed that it fixes all madwifi problems, but at least some. Regarding the orinoco card next to me: 0.4.8 made it working for the first time using NM and wpa_supplicant.
Yes, the biggest gain is that 0.4.8 fixes orinoco problems.
Joe, submit it - and we review it then.
Package submitted.
Package checked in.
Again I have got the problems described above using an intel PRO Wireless 2200 with NetworkManager-0.6.2-34 and wpa_supplicant-0.4.8-14. Using the traditional way with ifup works quite fine.
Please attach /var/log/NetworkManager.
This is not a blocker.
Created attachment 84645 [details] /var/log/NetworkManager as tar.bz2 Here my log.
Maybe one additional remark: The problem occurs since an update to kernel 2.6.16.16-SL101_BRANCH_20060518185902. Also an update of the ipw2200 and ieee80211 to the actual versions did not help. I'm trying a downgrade of the kernel now.
OK, I traced down the reason thanks to Daniel Stefan Mader: It is the update of dhcdbd from 1.12-14 to 1.12-14.2. After downgrading again everything works as expected.
Hello, since my name already occurs: let me add that this patch should be removed immediately. The trouble is caused by an official patch/package, and many users will install it!
This is probably what was reported as bug 177443.
The issue with dhcdbd is fixed already, it just takes some time to sync the mirrors.
I just installed dhcdbd 1.12-14.2, dhcp 3.0.3-23.1, dhcp-client 3.0.3-23.1. But the problem persists.
Then please reopen the dhcdbd bug, not this one.
And again because of the topic I post here: I finally traced down the problem: It occurs using the most recent ipw2200 driver. Using the version originally present in the kernel everything works fine. I do not know which change is responsible but it would be nice to support newer drivers due to their support for radiotap headers etc. Maybe someone with a deeper knowledge of that stuff can have a look at this.