Bug 213088 - WPA auth not working, bcm43xx
WPA auth not working, bcm43xx
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Depends On:
  Show dependency treegraph
Reported: 2006-10-30 14:56 EST by Alex Kanavin
Modified: 2008-10-20 10:58 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-20 10:58:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
NetMan fails to do WPA auth (14.83 KB, text/plain)
2006-10-30 14:56 EST, Alex Kanavin
no flags Details
wpa_supplicant succeeds to do WPA auth (6.17 KB, text/plain)
2006-10-30 14:57 EST, Alex Kanavin
no flags Details
info for nm wpa ppc bug (13.90 KB, text/plain)
2007-12-14 02:08 EST, Ilkka Tengvall
no flags Details
patch against wpa_supplicant-0.5.7-21.fc8 (3.89 KB, patch)
2008-01-16 03:09 EST, Ilkka Tengvall
no flags Details | Diff
the spec to create debug version of package wpa_supplicant-0.5.7-21.fc8 (13.21 KB, text/plain)
2008-01-16 03:12 EST, Ilkka Tengvall
no flags Details
debug log with dumped psk (219.74 KB, text/plain)
2008-01-16 11:24 EST, Ilkka Tengvall
no flags Details
for the comparison of psk, this one works (21.29 KB, text/plain)
2008-01-16 16:25 EST, Ilkka Tengvall
no flags Details

  None (edit)
Description Alex Kanavin 2006-10-30 14:56:47 EST
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:



I have attached portions of /var/log/messages for the NetworkManager
case (which fails) and wpa_supplicant (which succeeds).
Comment 1 Alex Kanavin 2006-10-30 14:56:47 EST
Created attachment 139758 [details]
NetMan fails to do WPA auth
Comment 2 Alex Kanavin 2006-10-30 14:57:44 EST
Created attachment 139759 [details]
wpa_supplicant succeeds to do WPA auth
Comment 3 Shane O'Brien 2007-06-21 21:37:58 EDT
Somebody on the Gnome Bugzilla reckons that this could actually be an endianness
issue specific to PowerPC - this would make sense.
Comment 4 Alex Kanavin 2007-07-02 19:50:50 EDT
Probably - can you provide a link to the bug/discussion in there?
Comment 5 Shane O'Brien 2007-08-31 15:57:21 EDT
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:

Here's the bug on Launchpad FYI:
Comment 6 Alex Kanavin 2007-11-09 22:56:07 EST
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.
Comment 7 Ilkka Tengvall 2007-12-14 02:08:03 EST
Created attachment 288571 [details]
info for nm wpa ppc bug

collection of relevant system info for nm wpa ppc bug
Comment 8 Ilkka Tengvall 2007-12-14 02:12:17 EST
"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.
Comment 9 Alex Kanavin 2007-12-14 10:15:57 EST
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?
Comment 10 Dan Williams 2007-12-14 11:21:32 EST
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.
Comment 11 Alex Kanavin 2007-12-14 11:47:02 EST
Of course I'd be willing to - please provide the needed bits.
Comment 12 Dan Williams 2007-12-14 14:32:00 EST

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.

Comment 13 Alex Kanavin 2007-12-14 15:27:06 EST
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?
Comment 14 Alex Kanavin 2008-01-15 22:47:19 EST
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
  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
Comment 15 Ilkka Tengvall 2008-01-16 03:09:44 EST
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.
Comment 16 Ilkka Tengvall 2008-01-16 03:12:36 EST
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.
Comment 17 Ilkka Tengvall 2008-01-16 11:24:27 EST
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.
Comment 18 Alex Kanavin 2008-01-16 12:50:58 EST
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?
Comment 19 Ilkka Tengvall 2008-01-16 14:44:09 EST
I need to think of how to do it. I don't have any Fedora Intel wlan machine.
Comment 20 Ilkka Tengvall 2008-01-16 16:25:10 EST
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
Comment 21 Alex Kanavin 2008-01-16 16:38:58 EST
Can you attach the log for this working case? Perhaps by carefully comparing the two side by side we can 
figure something out.
Comment 22 Ilkka Tengvall 2008-01-17 04:51:27 EST
Well, it's there, isn't it? Check my previous posting, it's actually an
attachement with comment.
Comment 23 Alex Kanavin 2008-01-17 08:59:43 EST
Oh yeah. So this 7b78f3012eea81e993487b67bf6d57c3d69d73db9e4b93bfc5c928dcc5d5dc84
passkey is nowhere to be seen in the original non-working log. Instead, there is

Somewhere on the way from NM to wpa_supplicant the transformation is performed
incorrectly. That's how it looks to me.
Comment 24 Dan Williams 2008-01-17 12:12:52 EST
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.
Comment 25 Alex Kanavin 2008-01-17 13:23:16 EST
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.
Comment 26 Ilkka Tengvall 2008-01-18 02:54:40 EST
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.
Comment 27 Ilkka Tengvall 2008-01-18 09:35:32 EST
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!
Comment 28 Alex Kanavin 2008-01-18 10:58:56 EST
Ilkka, which wireless driver are you using? svn3235 doesn't seen to work for me
- see above.
Comment 29 Ilkka Tengvall 2008-01-18 15:52:52 EST
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...
Comment 30 Alex Kanavin 2008-01-22 15:12:46 EST
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.
Comment 31 Marc Schwartz 2008-04-11 01:08:30 EDT
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:



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:

Comment 32 Marc Schwartz 2008-04-11 08:39:58 EDT
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.
Comment 33 Alex Kanavin 2008-04-11 09:10:12 EDT
(In reply to comment #32)

This should be filed as a separate bug.
Comment 34 Marc Schwartz 2008-04-11 09:45:20 EDT
Bug #442046 added.
Comment 35 Dan Williams 2008-10-20 10:58:39 EDT
WPA-PSK/WPA2-PSK tested working with, 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!

Note You need to log in before you can comment on or make changes to this bug.