GNOME Bugzilla – Bug 359369
MS-CHAPv2 802.1x Iauthentification support
Last modified: 2008-07-25 17:57:00 UTC
Networkmanager seems not to support this kind of config, while wpa_supplicant does; can this be implemented in 0.7 ? http://mail.gnome.org/archives/networkmanager-list/2006-October/msg00032.html
*** Bug 400605 has been marked as a duplicate of this bug. ***
A working wpa_supplicant.conf contains the following block: network={ ssid="<ssid>" scan_ssid=1 key_mgmt=WPA-EAP eap=PEAP identity="<username>" password="<password>" phase1="include_tls_length=1 peaplabel=0" phase2="auth=MSCHAPV2" } Of this, I believe that the only part NetworkManager doesn't handle is the phase2 part. Surely, this should be a small thing to fix...
Created attachment 82385 [details] [review] Adds EAP-MSCHAPv2 Support to NetworkManager Here's a patch that should add MSCHAPv2 support to NetworkManager. I'm having (unrelated) issues with the campus wireless network, so my testing isn't complete, but I can see that NetworkManager at least sends "SET_NETWORK 0 eap MSCHAPV2" to wpa_supplicant and gets an "OK" response.
Created attachment 82386 [details] [review] Adds EAP-MSCHAPv2 to knetworkmanager GUI
Jonathan; what does a working wpa_supplicant config block look like for you? Normally MSCHAPv2 is used as a phase2 method, not an eap= method...
The working wpa_supplicant block is posted above... you are correct, it's done via phase2=, not eap=. I guess I got excited when I saw an MSCHAPV2 EAP method in the wpa_supplicant documentation. I'll look into the wpa_supplicant a little more deeply and see if I can get the tunnelled EAP to work.
Current 0.6.x branch SVN should support this already (though not sure about knetworkmanager), actually. The phase2 patch went in last week but needs more testing.
Well, then... that's good. I guess I should look for such things before I go trying to do it myself. At least I got to play around with NM's guts a bit. This patch that you speak of... I'd like to help test it.
Created attachment 82460 [details] [review] My Latest (Abandoned) Attempt I may as well post this... it's where I was when I found out that this had already been done.
You can try the 0.6.5-pre tarballs at http://people.redhat.com/dcbw/NetworkManager/0.6.5/ There aren't yet patches for knetworkmanager, to my knowledge though. But if you wanted to do the patch, that would be great :)
Well, I connected to the campus network once... they've been having some troubles lately, so I can't say why successive attempts fail. Still, I connected to an MSCHAPv2 network... thanks!
Well, 0.6.5-pre "sorta" works. It doesn't always succeed in connecting, but that could be network's fault (as it is somewhat flakey... pure wpa_supplicant doesn't *always* work). One problem that I definitely have, though: the nm-applet forgets my key type (TKIP) and phase2 auth (MSCHAPV2). I often have to select them again, sometimes with a pop-up dialog, sometimes by clicking "Connect to other wireless network".
I'm grateful to the developers for striving to implement this, my university also uses 802.1X and without NetworkManager supporting it, it sucks to have to use wpa_supplicant to connect. However, I hope this is not only about implementing MSCHAP support, but all 802.1X methods supported by wpa_supplicant - http://hostap.epitest.fi/wpa_supplicant/ - listed there? The network I want to connect to uses EAP-TTLS/PAP. If this bug only concerns MSCHAP specifically, should I file another bug for EAP-TTLS/PAP? If this bug IS an effort for implementing 802.1X support, then could the title please be changed to avoid confusion, and bug #340595 added to the duplicates?
Using the 0.6.5-pre version of nm-applet downloaded from http://people.redhat.com/dcbw/NetworkManager/0.6.5, I can see options for EAP-TTLS/{PAP,MSCHAP,MSCHAPV2,GTC}. So, it should work for you...
Is bug #353594 a duplicate of this one?
Looks like a dupe to me... this means that Bug #353594 should also be fixed in 0.6.5-pre.
FYI: EAP-TTLS/PAP, which was mentioned in Bug #353594, works with the 0.6.5, therefore that bug is closed.
*** Bug 413981 has been marked as a duplicate of this bug. ***
This fixed now so closing.