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
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
|
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.
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.
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"}.
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.
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)
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>".
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
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?)
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.