Sorry for mistake, networkmanager version is 0.7.1.

Are you using an ASCII passphrase or a hex key? I already filed a bug about hex keys not working.

ASCII passphrase. My password is quiet complicated. But i changed it for tests to simple one, and effect was the same. What's more, i was trying to connect using hex key and again - effect was the same.

See also https://bugzilla.redhat.com/show_bug.cgi?id=505292 - it looks like this is related to the version of NetworkManager. The same snapshot (revision 963263 committed 2009-05-04 10:57 UTC) works on Fedora 10 (NetworkManager-0.7.1-1.fc10), but not on Fedora 11 (NetworkManager-0.7.1-4.git20090414.fc11).

We also found the probable cause: with the new NetworkManager, we have this additional line in the logs:
Jun 10 20:00:44 nbecker1 NetworkManager: <info>  Config: added 'auth_alg' value
'OPEN'
which makes no sense for WPA networks.

Can't confirm. I've just tested networkmanager 0.7.0, without change. Still
hans on 4 way handshake. Should older versions of networkmanager be checked?

And why auth_alg=OPEN makes no sense? As far as i know authentication is independed of wpa authorization.

I suspect there may be multiple different bugs with similar symptoms.

It's not the NetworkManager version, we had affected users try downgrading it to the same version as in Fedora 10 and it didn't help.

We'll, i've just updated kubuntu on my father's notebook, from 9.04 to 9.10 alpha. Same problem, we had to disable NetworkManager and use tradicional ifup/down way. Looks like it may be a big problem in nearest future.

Created attachment 34535 [details]
psk patch

Ok, i've just fixed my networkmanager. I'll try to explain what's wrong, i hope you'll understand my english :).

File libs/storage/settings/802-11-wireless-securitydbus.cpp contain code responsible for hashing wpa passphrase. First i thought there's something wrong with pbkdf2_sha1 function, but it's ok (tested). Then i removed hashing at all (patch attached), and everything works fine.

I suppose that problems are connected with storing hashed passphrare.

The current NM snapshots accept unhashed passphrases and will hash them themselves. However, your patch breaks support for versions <= 0.7.1 (this includes the latest stable release, which is 0.7.1) which don't do that.

That said, we can try that patch in Fedora >= 11.

By the way, most likely this also addresses https://bugs.kde.org/show_bug.cgi?id=191879 . But I think applying this unconditionally to the current NM plasmoid sources is the wrong fix, as it relies on an unreleased snapshot of NM. The hashWpaPsk function needs to be fixed instead (it can be a no-op for NM >= 0.7.2, but not for <= 0.7.1).

I would try to fix hashWpaPsk, but i'm not familiar with structures used in code, and exams on my mind, so i don't have time. Anyway, i hope somebody can fix that now.

Duplicate of #191951

I think there's more than one bug. One of the users at https://bugzilla.redhat.com/show_bug.cgi?id=505292 tried the workaround patch from comment #7 and it did NOT fix the issue for him.

*** Bug 196874 has been marked as a duplicate of this bug. ***

*** Bug 199037 has been marked as a duplicate of this bug. ***

*** Bug 191951 has been marked as a duplicate of this bug. ***

The unnecessary auth-alg key is no longer sent for non-WEP connections as of r1002366

Łukasz:  If I understand correctly, on current fedora/kubuntu (which? both?) passing through the WPA passphrase as-is fixes the bug for you?

This is my understanding of NM git head:

if the 'psk' string is a 64 bit hex string, 
->  hex PSK, do nothing 
otherwise
->  hash the passphrase itself 

so IFF the version you are using when you patched out the hashing has this feature, in theory your patch is not make any difference to the hashing and it succeeds for another reason.  Of course it is also possible that their is some subtle encoding bug that I don't know about in the hashWpaPsk() function - my bet is that calling toLatin1() to get the bytes of the passphrase fails on non latin1 characters...

It's hard to tell which NM versions do have hashing - current openSUSE Factory NM 0.7.1 does not.  If you can get the sources of your NM, look in src/supplicant-manager/nm-supplicant-config.c for "if (psk_len == 64)" for the relevant code.

I used the greek string "Επικοινωνία" as a WPA passphrase and it fails in KDE and with nm-applet (with client side hashing), surprisingly.

Can you check whether you have any "funny foreign letters" in your passphrase and try again without them?

I checked the spec, ascii only and 8 to 63 chars in length. so the greek example above is pointless.  Am adding validation to the UI.

That's right - when I use psk hex, applet connects correctly. And there are no foreign letters in my passphrase, only common letters and numbers.

SVN commit 1002613 by wstephens:

Validate WPA-PSK secrets are either a valid passphrase or a valid PSK.
CCBUG: 195824


 M  +2 -0      internals/CMakeLists.txt  
 A             internals/wpasecretidentifier.cpp   [License: LGPL]
 A             internals/wpasecretidentifier.h   [License: LGPL]
 M  +8 -6      ui/security/wpapskwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1002613

I was able to reproduce this just now.  Both knetworkmanager (monolithic, but
that's not significant) and nm-applet were sending the same PSK and had the
same other settings. 

I restarted my router, killed and restarted NetworkManager and wpa_supplicant,
and the problem went away.

Can you check the hashed key being sent by knetworkmanager or kded4 (in the
console output (if you are using the plasmoid, killall kded4 & sleep 2 && kded4
in a shell) and compare that to the hashed key stored by nm-applet?  If these
are the same try restarting wpa_supplicant.

Unfortunately I can't check it now. Hopefully I'll do it in 3 hours. Sorry for delay, it's independent of me.

Ping, please try latest SVN this weekend, have made more fixes.

Unfortunately, still the same problem here. What's more, even hashed psk doesn't work. Interesting fact is, that when i was trying for the last time, after restarting networkmanager, icon stuck to mobile phone or something (not wireless signal, as usual), and i definitely don't have any of mobile broadband device.

See the tooltip on mobile phone icon on the plasmoid, then install knetworkmanager instead.

#194128 has a number of confirmations that WPA-PSK is working now.  Closing this report too.

*** Bug 205165 has been marked as a duplicate of this bug. ***