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

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
NetMan fails to do WPA auth

Created attachment 139759
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
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
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
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!