FS#48327 - [wpa_supplicant] 2.5 won't work with eduroam.

Attached to Project: Arch Linux
Opened by Cláudio Pereira (claudiop) - Thursday, 25 February 2016, 00:18 GMT
Last edited by Jonathan Roemer (pid1) - Thursday, 08 September 2016, 19:08 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

wpa_supplicant as of 2.5 doesn't work with (some?) eduroam networks. Tried on two different networks, in one of them with some different distributions(some with 2.4, https://bugs.archlinux.org/task/44731), and all of them are problematic. The only distributions I tried that managed to connect were the Ubuntu 14.04 derivatives.

Tried to use NetworkManager and Wicd (since I don't know how to use wpa_supplicant directly) and both yield the same results, an authentication failure and eventual disconnect.

As of 2.4 a solution that worked was to copy the NetworkManager settigs (/etc/NetworkManager/NetworkManager.conf) from *buntu 14.04. Somehow it was different from the settings generated by NetworkManager (as of Oct-Nov 2015) and it managed to connect. Right now it doesn't works either way.

Here are some logs (maximum verbosity): https://gist.github.com/claudioap/bcccc928ad0fdb44ebd5
I left the v2.3 process running for about a minute so it probably has a lot of redundant information.
I censored a lot of hex dumps since I was able to match my username(student id, which I want to keep private) in some of them, ask if you need any of them.

This clearly is very similar to bug #44731, and I posted there my non-verbose logs there(http://pastebin.com/njiNp6Ju) and some cards I tried.
So far tried on those cards: http://pastebin.com/YFdJfxyE
The card that worked with the NetworkManager config hack was an bcm4313 running the broadcom blob.

Please note that the first logs came from one eduroam network and the latter(the pastebin) from a different one (as of Jan 19).

I didn't mention because was sort of implicit, but downgrading to 2.3 fully solves the connection issues.
This task depends upon

Closed by  Jonathan Roemer (pid1)
Thursday, 08 September 2016, 19:08 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Server-side issue, not an Arch bug nor an upstream issue. Workarounds and future solutions in comments.
Comment by Mantas Mikulėnas (grawity) - Saturday, 12 March 2016, 10:15 GMT
It's most likely realm-specific – *no matter where* you connect from, the auth requests are handled by the same server based on your username's "@domain"... So "two different networks" don't mean much.

Just as a wild guess, try {phase1="tls_disable_tlsv1_2=1"} or even {phase1="tls_disable_tlsv1_1=1 tls_disable_tlsv1_2=1"}? (I know the Debian version of FreeRADIUS is a bit buggy when it comes to recent TLS versions.)

Also try switching between {eap=PEAP}, {eap=TTLS & phase2="auth=PAP"}, {eap=TTLS & phase2="auth=MSCHAPV2"}, and {eap=TTLS & phase2="auth=EAP-MSCHAPV2"}.
Comment by Cláudio Pereira (claudiop) - Friday, 25 March 2016, 03:22 GMT
I'm sorry for not updating this. I forwarded this bug report to one of the universities, but so far none has reached me, I'll try to contact the other.
I have no idea on how to use wpa-supplicant directly, I always used either NetworkManager or Wicd, and have no idea about how to use those parameters.
Once I get back to school (vacation week) I'll try to sort this out hoping it is specific to my authentication server and that doesn't affect anyone else.
Comment by Mantas Mikulėnas (grawity) - Friday, 25 March 2016, 10:49 GMT
Ah, via NM you can set the 802-1x.eap, 802-1x.phase2-auth, 802-1x.phase2-autheap parameters (e.g. via "nmcli con edit" or "nmcli con modify"). Though it doesn't let you disable individual TLS versions.

A direct wpa_supplicant config (for testing) would look like this: https://gist.github.com/grawity/bda6233d3b58ced735fa – many of the 802-1x.* parameters in NM correspond directly to wpa_supplicant ones.

(tbh, it would be useful to have a test account of some sort, so I could try from here directly)
Comment by Ben Eyal (beneyal) - Wednesday, 06 April 2016, 15:49 GMT
After pulling lots of hair lately, I can attest that the following configuration works on wpa_supplicant 2.3, but on 2.5 I get CTRL-EVENT-DISCONNECTED, reason=3 after such a short time that it seems that no actual attempt is being made, and the request is rejected right off the bat:

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="BGU-WPA"
key_mgmt=WPA-EAP
auth_alg=OPEN
eap=PEAP
phase2="auth=MSCHAPV2"
identity=<username>
password=<password>
}

Also, my uni's eduroam config is just like the one above, only the ssid is different. wpa_supplicant 2.5 returned the same error for eduroam as it did for BGU-WPA. I have made sure with the uni's IT that these settings are 100% correct.

In order to be sure with high probablity that this is solely a wpa_supplicant issue, I did the following:
1. Download Arch Linux ISO dated April 1st, 2016
2. Use dd to create a bootable USB, as per the instructions at https://wiki.archlinux.org/index.php/USB_flash_installation_media#In_GNU.2FLinux
3. Boot from USB
4. Create a new file "bguwpa.conf" with the settings above
5. Run "wpa_supplicant -i wlo1 -D nl80211 -c$HOME/bguwpa.conf" => CTRL-EVENT-DISCONNECTED reason=3
6. Run "wpa_supplicant -v" => 2.5
7. Install Arch Linux to a USB drive using ISO dated April 1st, 2016, as per the instructions at https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key
8. chroot into the USB
9. Install "wpa_supplicant" version 2.5 (at the time of this writing) and "dhcpcd"
10. Install "downgrader" from the AUR
11. Downgrade wpa_supplicant to version 2.3 (and made sure using "wpa_supplicant -v")
12. Run command from (5) => CTRL-EVENT-CONNECTED, wpa_supplicant running but not giving anymore output
13. Run "dhcpcd wlo1" => successfully assigned IP
14. Run "wget google.com" (since pings don't work at the uni) => successful

This seems to be a problem only with WPA/WPA2-Enterprise networks, since I could connect without a problem to a plain WPA network with the config from "wpa_passphrase <ssid> <password>".
Comment by alleut (alleut) - Wednesday, 11 May 2016, 13:58 GMT
I have reported a similar bug for an earlier version, and I can state than 2.5 still unable to connect to any MSCHAPv2 enabled network.
Comment by Cláudio Pereira (claudiop) - Wednesday, 11 May 2016, 19:17 GMT
Sorry for the lack of reply but I've been waiting all this time for an answer from my university but no one is willing to help it seems.
I still have to find who's in charge for the eduroam authentication. I'm being bounced from one guy to another, but they have no clue on what I'm talking.
If someday I find the correct guy I'll try to get some information and then I'll dump it here.

The department in charge of the network of the other university already told me that it is almost for sure related to the authentication server. Their logs say "Login incorrect (Home Server says so) [mylogin@university]".
"It is probably correct to say it is related to the radius server on your university" - They said
Comment by Mantas Mikulėnas (grawity) - Thursday, 12 May 2016, 07:14 GMT
Well yes, all other eduroam servers just pass EAP through to the home server, so wpa_supplicant will be talking SSL/TLS directly to your university's RADIUS server no matter where you go.

The two log files have a pretty obvious difference – in v2.3 (line 432) OpenSSL starts with requesting ver=0x301 (TLS 1.0) and succeeds, while in v2.5 (line 635) it asks for ver=0x303 (TLS 1.2) and immediately fails.

So, seriously now, could you *please* try running wpa_supplicant directly & with phase1="tls_disable_tlsv1_2=1" in the network configuration? You've been given several complete examples of how to do it. Stop NM & wpa_supplicant.service, run `wpa_supplicant -i wlan0 -c foo.conf -d -d -d`, and see if it works.

(Alternatively, could you share at least the @realm name so that I could test from here?)
Comment by Cláudio Pereira (claudiop) - Friday, 13 May 2016, 16:38 GMT
Sorry grawity, when I first saw your comment I was under a lot of work, and after it simply forgot to test using what you told me.
The problem is TLS 1.2
Here are some logs: https://gist.github.com/anonymous/d5989101a00ae7e1e5b1b681323c7094

Looking up "disable TLS1.2 Network Manager" I can see that there were many related annoyances, not only with this kind of networks.
Something related to server-side DH keys which are too short.
Yet I found no way to enforce the TLS downgrade on NM.

I guess this bug is solved, its neither Arch's nor an upstream problem, but is there any way I can set NM (or Wicd if needed) to call wpa_supplicant with the TLS 1.2 disable switch?
I'd like to add a workaround to the Wiki so that people with the same issue can have an easy fix. "Just downgrade to 2.3" doesn't seem like a proper fix.
Comment by Mantas Mikulėnas (grawity) - Friday, 13 May 2016, 18:11 GMT
There is a related NM feature request: https://bugzilla.gnome.org/show_bug.cgi?id=765059

Loading...