FS#51358 - [wpa_supplicant] The old bug: breaks WPA2 Enterprise PEAP MSCHAPv2 connection

Attached to Project: Arch Linux
Opened by alleut (alleut) - Thursday, 13 October 2016, 09:52 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Friday, 18 November 2016, 20:46 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
The same bug persists: impossible to connect to a WPA2 Enterprise with 1:1.26-1.
Old 1:2.3-1 works fine
Old ticket on the problem: https://bugs.archlinux.org/task/47320
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Friday, 18 November 2016, 20:46 GMT
Reason for closing:  Not a bug
Comment by Carl Mueller (cmlr) - Sunday, 16 October 2016, 22:55 GMT
A fix was posted on the wpa_supplicant mailing list:
http://lists.infradead.org/pipermail/hostap/2016-October/036460.html
Comment by Carl Mueller (cmlr) - Thursday, 27 October 2016, 13:44 GMT
On second thought, the above fix doesn't fix it for me.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 04 November 2016, 16:40 GMT
That fix is for EAP_PWD. So, indeed it won’t fix it for you.

Also, the old bugs are not related to this new one. Here, firing wpa_supplicant by hand you get this:
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
TLS: Unsupported Phase2 EAP method 'MSCHAPv2'
wlp6s0: EAP: Failed to initialize EAP method: vendor 0 method 25 (PEAP)
wlp6s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

Downgrading to 1:2.5-3 solves this, temporarily at least. Do we need to be suscribed to post on upstream ml?
Comment by Idares (Idares) - Sunday, 06 November 2016, 17:47 GMT
Try to change phase2 method from 'MSCHAPv2' to 'MSCHAPV2' (all uppercase).
Comment by Carl Mueller (cmlr) - Monday, 07 November 2016, 14:08 GMT
No, changing from 'MSCHAPv2' to 'MSCHAPV2' didn't work for me.
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 07 November 2016, 16:04 GMT
It does indeed work for me. But I consider this a workaround, MSCHAPV2 being less explicit than MSCHAPv2.
Comment by Carl Mueller (cmlr) - Monday, 07 November 2016, 19:19 GMT
OK, wpa_supplicant 1:2.6-1 is working for me when I changed the netctl setting from
'phase2="auth=EAP-MSCHAPv2"'
(which worked before) to
'phase2="auth=MSCHAPV2"'

But the newest version which is in staging, wpa_supplicant 1:2.6-2, doesn't work for me with this new setting.
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 07 November 2016, 19:21 GMT
So 'phase2="auth=EAP-MSCHAPv2"' and 'phase2="auth=MSCHAPv2"' do not work anymore, but 'phase2="auth=MSCHAPV2"' does. Looks like they “sanitized” the recognized names.
Comment by Mantas Mikulėnas (grawity) - Saturday, 12 November 2016, 11:11 GMT
They never recognized those two names in the first place, as the debug log would have shown. Previous versions would just ignore it and accept anything the server offers.
Comment by Bruno Pagani (ArchangeGabriel) - Saturday, 12 November 2016, 23:34 GMT
OK, so basically all online documentation around eduroam is wrong in telling to use 'phase2="auth=MSCHAPv2"', including cat.eduroam.org (well, it seems this one has been updated to correctly set MSCHAPV2 instead now).
Comment by Mantas Mikulėnas (grawity) - Sunday, 13 November 2016, 00:01 GMT
Wouldn't surprise me. 99% of it is just copypasted from elsewhere, and nobody pays attention to debug logs if it works anyway.
Comment by Bruno Pagani (ArchangeGabriel) - Sunday, 13 November 2016, 00:03 GMT
OK. So this bug could probably be closed now, probably just waiting for OP to confirm it fixes the issue.
Comment by Pierre Walthery (Odusseus) - Tuesday, 15 November 2016, 10:53 GMT
Hi everyone,

Not sure this is related, but after upgrading from wpa_supplicant 1:2.5-3 => 1:2.6-2 (or 1:2.6-1), I cannot connect to eduroam anymore:.

ssid="eduroam"
scan_ssid=1
key_mgmt=WPA-EAP
eap=TTLS
anonymous_identity="XXXXXXXXXXXXXXX"
# adjust the following CA line as required to match your filename
ca_cert="/etc/ssl/certs/AddTrust_External_Root.pem"
phase2="auth=MD5"
# in the following line, replace <username> with your University Remote Access account username, without angle brackets
# Remote access account is described at http://www.oucs.ox.ac.uk/network/remote/
# (not your SSO). Append @OX.AC.UK after your username so
# that eduroam knowns the authentication home site
identity="XXXXXXXXXXXXXXXXXX"
# in the following line, replace <password> with your University Remote Access account password, without angle brackets
password="XXXXXXXXXXX"

Shall I open a new bug?
Comment by Mantas Mikulėnas (grawity) - Tuesday, 15 November 2016, 11:08 GMT
It's not a bug – version 2.6 merely started rejecting configurations which weren't valid in the first place.

You're using "auth=MD5", which needs to be "autheap=MD5" as it's an EAP-only mechanism. (For comparison, PAP is non-EAP, and MSCHAPV2 can be either EAP-based or not.)

Or for that matter, skip the phase2= setting entirely and accept the server's default of MSCHAPV2. (That's what happened with 2.5 anyway, and it's what http://help.it.ox.ac.uk/network/wireless/services/eduroam/generic/index recommends. It's pretty rare for a network to be using EAP-MD5, really.)
Comment by Pierre Walthery (Odusseus) - Tuesday, 15 November 2016, 11:20 GMT
I see.
Thanks. Working fine now.

Loading...