Hello,

I'm trying to fix problems with WPA-EAP authentication on Nokia N900. Please tell me all problems you know and which should be fixed.

I have already fix for those bugs:
Allow to use certificate without passphrase for EAP-TLS - https://bugs.maemo.org/show_bug.cgi?id=1574
Cancelling EAP-TLS passphrase dialog loose wifi connection until reboot - https://bugs.maemo.org/show_bug.cgi?id=11243
Autoconnect to WPA-EAP networks - https://bugs.maemo.org/show_bug.cgi?id=3399
Remember passcode for EAP-TTLS/EAP-GTC and EAP-PEAP/EAP-GTC auth types - https://bugs.maemo.org/show_bug.cgi?id=6960
Allow to select EAP-TTLS/PAP auth type - https://bugs.maemo.org/show_bug.cgi?id=1635
Allow to use WEP ciphers in WPA networks - https://bugs.maemo.org/show_bug.cgi?id=10341 and https://bugs.maemo.org/show_bug.cgi?id=5401

First three bugs are fixed in CSSU-Devel and others have manual solution (see bug trackers). See this thread about CSSU-Devel: http://talk.maemo.org/showthread.php?t=84292

Please test and let me know if WPA-EAP is now working better on Nokia N900

To use existing EAP-TLS certificate without passphrase, update all maemo-security-certman-applet related packages to version >= 0.1.5, reboot device and in Certificate Manager reset passphrase (choose certificate --> Password --> uncheck Password protection). After that N900 will connect to EAP-TLS protected wifi network without asking for passphrase.

EAP-PEAP/EAP-MSCHAPv2 : unable to connect to Windows-based NPS/Radius server without further intervention by administrator. This is not really useable because few, if any, administrators will be willing to adjust their network based on user request when "all" other devices work. Referenced Microsoft Technet article [1] has further details on this. The problem happens on all Nokia devices, including Symbian. Perhaps you can find a way to fix it in N900?

Explanation of the problem from Microsoft:
"Solution" from Nokia:
I think this is bogus solution. While I think MS deviated from the standards, but Nokia should have realized network control is usually too far from the user. For what it's worth, the Nokia-proposed solution actually does work as I've tested it on my own install. But in my organization they refused to make such a tweak and partly, it's understandable.

This bug was never reported correctly in the bug-tracker because the Nokia gives a bogus error, "Authentication Failed" and at the time, most testers focused on certificates, etc. It turns out that certificate is the least of the problem. This is usually the "real" bug.

This is probably a bit selfish of me, haha, but iI would even venture to say Bug 3399 is lower priority than this one

[1] https://social.technet.microsoft.com...m=winserverNAP

Maemo Certificate Manager can import EAP-TLS certificate only in PKCS12 format with .pfx extension. It must contains:
* private key
* client certificate
* server certificate
* all CA certificates in signed trust chain

If certificate is in PEM format, first must be splitted into separate parts and then converted to PKCS12.

Use this command for creating PKCS12 file "cert.pfx" without password:
$ openssl pkcs12 -export -nodes -passout pass: -out cert.pfx -inkey private_key.pem -in client_certificate.pem -certfile server_cert_with_all_ca_certs.pem

Just to note that EAP-MSCHAPV2 is not supported on Maemo. Even EAP-MSCHAPv2 does not generate any keying material, so it not only theoretically could be used for WPA.

Probably you mean EAP-MSCHAPV2 in some tunnel (EAP-PEAP or EAP-TTLS).

To make everything sure, these methods are suppored by Maemo 5 and all these auth methods are *different*:

There is also difference between EAP-TTLS/MSCHAPV2 and EAP-TTLS/EAP-MSCHAPV2, so make sure you choose correct one!

In Maemo UI is bug, there is written "EAP PAP". But it is just "PAP" in EAP-TTLS tunnel. There is no "EAP-PAP" auth type!

Edited my post
I meant. EAP-PEAP/EAP-MSCHAPV2

So the above 'rant' still applies. Thanks

@sicelo: Problem is of course in eapd daemon. This daemon uses openssl for all crypto stuff. So there are two options how to fix this bug:

1) Rewrite eapd and fix that bug directly in eapd.
2) Drop that optional AVP message in openssl layout and so eapd will now know about it

Technically second option should be easier, compile openssl in debug mode and dump all messages. See which one is that AVP type 12 and patch openssl to drop/ignore it.

If you will be able to do that I could accept patch/hack based on getpid() for openssl to CSSU which drop that message only for eapd process.

This should be possible and maybe also easy to implement. You just need that MS server for testing (which I do not have).

Installing MS server is easy. You can install in a VM even, and get hostapd to auth against it. Testing does not even need a CAL/license. I am willing and interested to help in this regard.

My openssl foo is non-existent however, so as of now, I know absolutely nothing. If you're able to give me some guidance/pointers, I'd be happy to try (maybe on my 2nd N900 ) I do have SB

If you're able to provide a deb of the needed openssl build, i could get all needed logs relating to the tests.

This needs manual work and debugging with openssl library. I do not know exactly where is problem in that MS server, so it is not easy for me... You will need to try debugging yourself.