I can't get NetworkManager 0.6.4 to authenticate over WPA with my Motorola SBG900E access point/cable modem. If I use wpa_supplicant 0.4.8, then it works totally fine. I'vm using a Powerbook 12" notebook with a bcm43xx (Airport Express) interface. Options for wpa_supplicant are -ieth1 -Dwext, and the configuration file is: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="Motorola" scan_ssid=1 key_mgmt=WPA-PSK psk="xxxxxxxxx" } I have attached portions of /var/log/messages for the NetworkManager case (which fails) and wpa_supplicant (which succeeds).
Created attachment 139758 [details] NetMan fails to do WPA auth
Created attachment 139759 [details] wpa_supplicant succeeds to do WPA auth
Somebody on the Gnome Bugzilla reckons that this could actually be an endianness issue specific to PowerPC - this would make sense.
Probably - can you provide a link to the bug/discussion in there?
I'm really sorry for taking so long to write back - but I've good news! The problem was indeed an endianness issue, and a patch has been applied upstream. Have a look at the Gnome Bugzilla here: http://bugzilla.gnome.org/show_bug.cgi?id=420216 Here's the bug on Launchpad FYI: https://bugs.launchpad.net/network-manager/+bug/101857
I've some not so good news. The problem persists on a clean install of F8, which has the 0.7 branch of NM with the supposed fix included.
Created attachment 288571 [details] info for nm wpa ppc bug collection of relevant system info for nm wpa ppc bug
"Me too!" - I fresh installed fedora 8 on powerbook (17" aluminium from 2005). WEP works, and needles to say WPA works from OsX. The opposite end of WLAN is WRT54G box with DD-WRT install. And works (has always worked) with other flavor of linux on other laptops and handhelds with no problem. It continuously tries connecting, asks the passwd and retries. I also attach wpa_supplicant.log, messages, lspci and some sw versions. This is a pity since it pretty much leaves the installation useless at home. And I tried with bluetooth service on and off, since someone was experiencing problems with that.
Well, it's quite likely to be a PPC endianness issue. PSK gets broken somewhere on its way to wpa_supplicant. Is there any easy way to make wpa_supplicant log the actual PSK it gets from NM?
If you're able to rebuild the wpa_supplicant RPM, I can happily provide you one that dumps the network that is about to be joined, which does list the PSK. By default of course it's not shown for security reasons. Let me know; would be great if you could check this out and report back if the PSK is as expected.
Of course I'd be willing to - please provide the needed bits.
http://people.redhat.com/dcbw/wpa_supplicant-0.5.7-16.1.fc8.src.rpm Build it, install the resulting RPM, remove /var/log/wpa_supplicant.log, 'killall -TERM wpa_supplicant', then wait 10 seconds and try an association with NetworkManager. After that /var/log/wpa_supplicant.log should have a dump of the network to which wpa_supplicant tried to connect, along with the PSK. Thanks!
Built, installed, made sure old version isn't running... But the new one doesn't actually write anything extra to wpa_supplicant.log! It looks exactly same as the one that Ilkka provided. Did you or me miss something?
Ok, the missing part is that wpa_supplicant should be started manually with -dd option. Here's how the dump looks, hope that helps: WPA: clearing own WPA/RSN IE *** Dumping ssid 0x10080768 ssid : "Motorola" scan_ssid : 0 bssid : (null) psk : <very long (32 bytes) hex number - and my psk is in fact a word with 10 letters> proto : WPA RSN key_mgmt : WPA-PSK pairwise : CCMP TKIP group : CCMP TKIP WEP104 WEP40 auth_alg : eap : (null) identity : (null) anonymous_identity : (null) eappsk : (null) nai : (null) password : (null) ca_cert : (null) ca_path : (null) client_cert : (null) private_key : (null) private_key_passwd : (null) dh_file : (null) subject_match : (null) altsubject_match : (null) ca_cert2 : (null) ca_path2 : (null) client_cert2 : (null) private_key2 : (null) private_key2_passwd : (null) dh_file2 : (null) subject_match2 : (null) altsubject_match2 : (null) phase1 : (null) phase2 : (null) pcsc : (null) pin : (null) engine_id : (null) key_id : (null) engine : 0 eapol_flags : 3 wep_key0 : (null) wep_key1 : (null) wep_key2 : (null) wep_key3 : (null) wep_tx_keyidx : 0 priority : 0 eap_workaround : -1 pac_file : (null) fragment_size : 1398 mode : 0 proactive_key_caching : 0 disabled : 0 id_str : (null) peerkey : 0 DONE
Created attachment 291830 [details] patch against wpa_supplicant-0.5.7-21.fc8 coincidently I also dragged my laptop home yesterday to try this one out. Too bad I didn't realize to run the wpa_supplicant by hand with the -dd option, so the log doesn't contain anything useful. But I applied the patch to the current wpa_supplicant. I attach it here if you want to test with it instead the old one. It just required the print functions added to config.[ch]. Recompile wpa_supplicant-0.5.7-21.fc8.src.rpm by dropping this patch into SOURCES directory and using the spec I'll attach next.
Created attachment 291831 [details] the spec to create debug version of package wpa_supplicant-0.5.7-21.fc8 the spec to create wpa_supplicant-0.5.7-22.fc8 - a dcbw's patch applied to latest wpa_supplicant.
Created attachment 291864 [details] debug log with dumped psk took a dump now with -dd option. Start reading the file backwards, since there are the better tries. Some of those at the beginning might have timed out while typing the passwd etc... I set the wpa psk key to router as an ascii string of "123456789abcdef". So it could be compared from the dump. I suppose that would need to be converted to hex first to find it from the dump.
Ilkka, can you try the same version of wpa_supplicant on a working box (e.g. intel based), and see how the PSK looks there?
I need to think of how to do it. I don't have any Fedora Intel wlan machine.
Created attachment 291894 [details] for the comparison of psk, this one works Didn't need to do it with Intel CPU. I just configured manually and it works. The psk is just the same in the log as with the $ wpa_passphrase ikke 123456789abcdef network={ ssid="ikke" #psk="123456789abcdef" psk=7b78f3012eea81e993487b67bf6d57c3d69d73db9e4b93bfc5c928dcc5d5dc84 }
Can you attach the log for this working case? Perhaps by carefully comparing the two side by side we can figure something out.
Well, it's there, isn't it? Check my previous posting, it's actually an attachement with comment.
Oh yeah. So this 7b78f3012eea81e993487b67bf6d57c3d69d73db9e4b93bfc5c928dcc5d5dc84 passkey is nowhere to be seen in the original non-working log. Instead, there is c37ffca5d378dfeff4f903edb13952eaf19dfc8cc0933e0588cd674f248f3713. Somewhere on the way from NM to wpa_supplicant the transformation is performed incorrectly. That's how it looks to me.
Could those of you using WPA from PowerPC-based machines please ensure that you're using the latest available version of NetworkManager? You should have at least 0.7.0-0.6.7.svn3204, which fixes a bug with WPA passphrase hashing on big endian machines.
No joy. I've updated to NetworkManager-0.7.0-0.8.svn3235.fc9 and wpa_supplicant-0.5.7-21.fc8, and now NM tries to connect for a while, then brings up the password dialog and after I type in the password, it immediately reverts to the wired network.
My version was the latest in fc8, NetworkManager-0.7.0-0.6.6.svn3138.fc8. I just upgraded it to NetworkManager-0.7.0-0.8.svn3235.fc9 now that you instructed to. Will see if it works once I drag the mac to home.
This writing is a living proof that version NetworkManager-0.7.0-0.8.svn3235.fc9 works! Thanks. So it was after all the bug that was already fixed months ago in trunk. Hmmm... in the middle of writing here the link just dropped. But after asking the pw again it re-connected. Thumbs up it keeps rocking!
Ilkka, which wireless driver are you using? svn3235 doesn't seen to work for me - see above.
I use the default, the new broadcom driver b43. My HW is (like mentioned in the first log of mine in more detail): 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) It seems linux is more picky about the signal that OsX or something, the connection cuts off once in the while. The router is in the same room though...
Hmm, after a reboot the problem went away for me as well. Finally NM works here. I haven't had any connection dropouts yet, but if there will be, it needs to be filed as a separate bug.
After locating this report tonight, I updated NetworkManager and wpa_supplicant from the F8 testing repo. After a re-boot, I am now able to connect to a LinkSys Router/WAP using WPA2 Personal. I also note the updated NM GUI. Prior to this, the behavior was similar to other reports, with no successful WPA connections, though I could connect to open wireless networks without problems. The current versions of the apps that I have mow are: NetworkManager-gnome-0.7.0-0.6.7.svn3370.fc8 NetworkManager-openvpn-0.7.0-8.svn3302.fc8 NetworkManager-glib-0.7.0-0.6.7.svn3370.fc8 NetworkManager-0.7.0-0.6.7.svn3370.fc8 NetworkManager-vpnc-0.7.0-0.6.3.svn3109.fc8 wpa_supplicant-0.5.10-4.fc8 My wifi card is in a Dell Inspiron 5150 laptop with a P4 CPU: 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 02) and I use the b43legacy driver via b43-fwcutter. My kernel is the latest for F8 stable: 2.6.24.4-64.fc8 Thanks!
A follow up to my comment above. I am noting that the wireless connection periodically drops and falls back to the wired connection. The following is found in dmesg: wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:18:39:df:fc:29 wlan0: RX authentication from 00:18:39:df:fc:29 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:18:39:df:fc:29 wlan0: RX AssocResp from 00:18:39:df:fc:29 (capab=0x411 status=0 aid=2) wlan0: associated wlan0: switched to long barker preamble (BSSID=00:18:39:df:fc:29) ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present wlan0: disassociate(reason=3) eth0: no IPv6 routers present wlan0: RX deauthentication from 00:18:39:df:fc:29 (reason=16) wlan0: deauthenticated A Google search shows many references to the 'reason=*' above, but I cannot locate a description of what the reasons are.
(In reply to comment #32) This should be filed as a separate bug.
Bug #442046 added.
WPA-PSK/WPA2-PSK tested working with 2.6.26.5-28.fc8, NM svn4022.4.fc8, supplicant 0.5.10-6.fc8 with ipw2200 against a Linksys WRT54GC. If this is still an issue with the latest F8 kernel and using the b43 driver, please re-open. THanks!