WPA doesn't work with NetworkManager on big-endian (works with wpa_supplicant)

Bug #101857 reported by Shane on 2007-04-02
Affects Status Importance Assigned to Milestone
Fix Released
network-manager (Fedora)
Fix Released
network-manager (Ubuntu)
Alexander Sack

Bug Description

Binary package hint: network-manager

(from the same bug on the Gnome Bugzilla #420216):
Please describe the problem:
I have an iBook G4 with a Broadcom chipset, and I'm using the bcm43xx driver.

NetworkManager is unable to connect to any network with WPA encryption. It
works fine with unencrypted networks and wireless networks (I haven't actually
tested WEP networks, I don't have access to any, but from what I've read online
it seems to work fine with WEP networks). The bcm43xx driver can connect to WPA
networks using wpa_supplicant.

Steps to reproduce:
1. Using the bcm43xx driver, try to connect to a WPA network.
2. A dialogue will pop up asking you for the password: enter it.
3. NetworkManager will try to connect to the WPA network, but it'll never

Actual results:
It'll just keep trying to connect but it never will.

Expected results:
I'd expect it to connect on the basis that WPA networks work with

Does this happen every time?

Other information:
Here's a report for the same bug on Red Hat's bugzilla:

And I'm sorry for not filing this bug report earlier, it's been bothering me for quite a while. I just hope this'll be fixed in time for Feisty.

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).

Created attachment 139758
NetMan fails to do WPA auth

Created attachment 139759
wpa_supplicant succeeds to do WPA auth

Shane (duairc) wrote :

Sorry, I didn't mean to add that upstream thing about deluge, and I don't seem to be able to delete it. Could somebody that is able to delete please do so? Thanks.

Dennis Kaarsemaker (dennis) wrote :

Have you tried with the latest feisty kernels?

Shane (duairc) wrote :

Running feisty on the system at the moment and every package is up-to-date (including the kernel).

Shane (duairc) wrote :

Actually, it turns out there were updates to linux-restricted-modules and wpasupplicant that I didn't have installed. However, I've installed these and there's no difference.

Changed in deluge:
status: Unknown → Unconfirmed
Changed in network-manager:
status: Unknown → Unconfirmed
Changed in network-manager:
status: Unknown → Confirmed
Changed in deluge:
status: Unconfirmed → Rejected
CpuID (nathan-nightsys) wrote :

exactly the same issue here...been trying for weeks since moving from edgy to feisty. unencrypted networks seem fine, i cant remember if wep works or not though... havent tried wpa_supplicant on its own yet but pretty sure itll be the same result as you, working...

CpuID (nathan-nightsys) wrote :

hmm anyone here tried this with an x86/amd64 install? seems were both on ppc (powerbook 5,8 15inch here), and the redhat bug thats confirmed the issue is from a ppc user too...

willz06jw (willz06jw) wrote :

Same problem -- and it DOES work with WEP -- just not WPA.

Let me start by saying that I use ndiswrapper to (try to) connect to a WPA wireless Network using a Netgear WG111v1 and NetworkManager.

If I try to connect to the WPA network it just won't connect (No NetworkManager green button lights) even though it tries for a few minutes and then fails. If I change the security method to open WEP on my router it connects perfectly and automatically. My wireless adapter used to connect to the WPA network in version -9 of the kernel (with a modprobe reload of ndiswrapper every time I booted).

Note I have blacklisted prism54usb for ndiswrapper

Shane (duairc) wrote :

Interesting that your card doesn't work with ndiswrapper and NetworkManager, but I suspect that's a bug in ndiswrapper, or if it's a bug in NetworkManager, I'd imagine it's a separate one. This bus is about the bcm43xx driver, which works with wpa_supplicant, but not with NetworkManager. See if your driver works with wpa_supplicant - if it does, that means it's a NetworkManager bug; if otherwise, it's an ndiswrapper bug. Either way you should probably file a separate bug report.

hyde (uniprimus) on 2007-04-07
Changed in network-manager:
status: Unconfirmed → Confirmed
status: Confirmed → Unconfirmed
hyde (uniprimus) wrote :

I have the same problem. I can use NetworkManager to connect to unencrypted and WEP connections, but not WPA ones.

In Kubuntu (and so KNetworkManager), trying to connect to a WPA connection doesn't even get me a prompt for password.

Michael (michaeljt) wrote :

Same thing for KNetworkManager and an rtl8180 based wireless card. The problem in my case is that NetworkManager only uses wireless extensions for WPA, which means that the driver for the wireless card must support WE18 or higher to work with NetworkManager and WPA. It would be pretty simple to rewrite NetworkManager to support everything which wpa_supplicant does, but the NetworkManager developers say that any driver which does not support WE18 for WPA is legacy, needs to be rewritten and they will not support it. You can agree or disagree here, but it is their application, so I suppose they are entitled to decide there.

Shane (duairc) wrote :

Right, so basically the bug here is that NetworkManager doesn't support drivers that don't support WE18. Should NetworkManager be fixed to include support for these drivers, or should these drivers be fixed to include support for WE18?

willz06jw (willz06jw) wrote :

Well, I for one am forced to use old drivers because that is all that ndiswrapper will support for the WG111v1. If the NetworkManager guys don't write this in I am basically left with worthless hardware -- and that isn't good since most people that use Linux use older hardware because of newer hardware compatibility problems.

Josh Smith (saxsux) wrote :

I have the same problem; I'm using ndiswrapper for my laptop's built-in wireless card...

Efrain Valles (effie-jayx) wrote :

I have the same problem:

have you tried conecting to the the network by doing:

Connect to another wireless network:

Type the ESSID manually (the name of the network)
select the wireless security.

Have not tested it but it might work...

My card (bcm4318) doesn't connect to the network without doing this...

Tito's (rcarrasco) wrote :

Compaq Presario V3117LA
Network controller: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)
Ubuntu Feisty from scratch

The problem is with WPA/WPA2. All is fine using WEP

+ Using module bcm43xx always works but slow, very slow, near 150kbps (my bandwidth is 4mbps)
+ Using ndiswrapper is erratic. Most all the time nm-applet don't connect, sometimes works

Henrik Hodne (henrik-hodne) wrote :

I have a HP dc7100 with belkin F5D7001 network card. I also use Feisty Ubuntu (+ Windows XP also installed), and I don't even get the choice to use WPA.

Shane (duairc) wrote :

Somebody on the Gnome Bugzilla with the same problem posted this:

"Similar problem here, also on an ibook g4 with the bcm43xx driver (debian sid).

 - using wpa_supplicant : it works fine.
 - NetworkManager + entering the "ascii plaintext" password in the dialogue box
: doesn't works.
 - NetworkManager + entering the "hexadecimal string" (generated using the same
password and wpa_passphrase) : it works.

It seems to be a endianess problem, because it works fine with the same
settings (same WPA network+password, debian sid) on a x86 laptop".

I'm not able to test this at this time, but everything else would seem to point to it being an endianness issue. After all, the only reason I (and others) thought the bug was specific to bcm43xx was because that's the card that the iBook uses... but it could just be an endianness issue affecting PowerPC only.

Somebody on the Gnome Bugzilla reckons that this could actually be an endianness
issue specific to PowerPC - this would make sense.

Timothy Smith (tas50) wrote :

Is there any way you can test this with the new restricted device manager in Gusty Alpha 2. There have a been a lot of changes involving the firmware for the Broadcom cards that may affect this bug.

Probably - can you provide a link to the bug/discussion in there?

Wojtek Kaniewski (wojtekka) wrote :

09_fix_bigendian_words.patch in network-manager_0.6.4 is broken. It adds endianness checks to configure.in and configure, but doesn't add WORDS_BIGENDIAN define to config.h.in, so the code is still compiled the same way for little- and big-endian systems. Upstream version 0.6.5 already contains all the fixes, so Gutsy shoudn't be affected by this bug, only Feisty. As stated above, the workaround is to enter hexadecimal passphrase generated by wpa_passphrase.

Anyway, as I'm new to Ubuntu, I don't really know how to prepare a proper fix nor how to rebuild a patched package to test it. I've attached the fixed patch that should resolve all problems. It's pretty straightforward, but if you want me to test it first, please let me know how to rebuild a package or where to find some howto.

On Sun, Aug 12, 2007 at 02:59:07PM -0000, Wojtek Kaniewski wrote:
> 09_fix_bigendian_words.patch in network-manager_0.6.4 is broken. It adds
> endianness checks to configure.in and configure, but doesn't add
> WORDS_BIGENDIAN define to config.h.in, so the code is still compiled the
> same way for little- and big-endian systems. Upstream version 0.6.5
> already contains all the fixes, so Gutsy shoudn't be affected by this
> bug, only Feisty. As stated above, the workaround is to enter
> hexadecimal passphrase generated by wpa_passphrase.
> Anyway, as I'm new to Ubuntu, I don't really know how to prepare a
> proper fix nor how to rebuild a patched package to test it. I've
> attached the fixed patch that should resolve all problems. It's pretty
> straightforward, but if you want me to test it first, please let me know
> how to rebuild a package or where to find some howto.
> ** Attachment added: "09_fix_bigendian_words.patch"
> http://launchpadlibrarian.net/8787827/09_fix_bigendian_words.patch

If you want to help preparing an ubuntu update based on this patch,
feel free to stop by in #ubuntu-mozillateam on irc.freenode.net and
ping me (nick: asac).


 - Alexander

After some more research I found that sha1.c (the only endian-dependent file, AFAIK) didn't include "config.h" in any version (neither 0.6.4 in Feisty, nor 0.6.5 in Gutsy). I've rebuilt the package and NM started connecting to WPA networks. Not 100% of the time, but it seems that I've messed up my system, because even unmodified NM from Feisty with hex passphrase fails to connect.

Anyway, the first patch (09a_more_bigendian_fixes.patch) is an additional patch for 0.6.4. It DOES NOT replace any patch from the package like the one attached to the comment above. I hope that a broken out patch will be easier to understand and merge.

Wojtek Kaniewski (wojtekka) wrote :

The second patch fixes NM 0.6.5. I'm sending it upstream for review as well.

Wojtek Kaniewski (wojtekka) wrote :

NM developer applied the patch (42_bigendian.patch) to stable and trunk -- see GNOME bug #420216.

Changed in network-manager:
status: New → Fix Released
Alexander Sack (asac) wrote :

ok, will pull the patch. thanks.

Changed in network-manager:
assignee: nobody → asac
status: New → In Progress

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:

Alexander Sack (asac) on 2007-09-06
Changed in network-manager:
status: In Progress → Fix Committed
Alexander Sack (asac) wrote :

network-manager (0.6.5-0ubuntu10) gutsy; urgency=low

  * debian/patches/24pp_svn2754-lp101857-endianess.patch,series: prepatch patch
      by Wojtek Kaniewski to fix endianess issues in NetworkManager
      (LP: #101857).
  * debian/network-manager.postinst: apply patch contributed by Villalovos, John L
      <email address hidden> that prevents NetworkManager restart in postinst
      if invoke-rc.d --disclose-deny dbus force-reload fails. This is required to not
      start any service during chroot installs of ume.

 -- Alexander Sack <email address hidden> Thu, 06 Sep 2007 15:16:46 +0200

Changed in network-manager:
status: Fix Committed → Fix Released
J.P. (mackdieselx27) wrote :

Any word on getting the patch out to Feisty users?

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
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.


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.


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
  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

Created attachment 291830
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
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
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
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

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

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:



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:


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.

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!

Changed in network-manager:
status: Confirmed → Fix Released
bquenin (bquenin) wrote :

Hi, I'm sorry to reopen this "dead" bug, but i have the exact same problem on Ubuntu 8.10 with the b43-legacy driver ...

Alexander Sack (asac) wrote :

open a new bug if you think you see something similar ... this is closed for ages.

Changed in network-manager:
importance: Unknown → Medium
Changed in network-manager (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.