We interrupt our not-so-regularly scheduled philosophy to bring you this report about the travails of Linux users on university computer networks.
To solve this problem, the university deploys a piece of software called XpressConnect. The way it works is that you first connect to an open wireless network where you are redirected to a web page to login and register your computer, at which point you can download the software to automatically configure your wireless settings. (There are some rather obvious security issues here: a bad actor could set up a decoy network and trick users into installing malware. This is especially problematic since the university is here actually telling users to install a new CA certificate, so a bad actor could pull THAT trick without raising any questions, even for somewhat savvy users. But leave that aside - I just needed the blasted thing to work.) An obvious problem here is that this requires your computer to be able to run the software. The university does not provide any means of obtaining the correct certificates without running the software, so manual configuration is effectively impossible. For devices like game consoles that can't run this kind of software, there is a 'media' network that uses a simpler configuration, but the university says they're going to be policing this network and kicking off any device that has a web browser (?!).
Fortunately, XpressConnect runs on a variety of platforms. Configuration on my iPhone was seamless, for instance. It even supports Linux - sort of. That's what this post is about.
Well, it turns out, the software is trying to detect your exact distro and version, and if you don't exactly match one of the distro/version combinations it recognizes, it refuses to run. There does not appear to be a manual override in the software. (Though maybe it's just undocumented -- there's no '-h' or '--help' or anything to say if the software takes command-line options.) This has been a problem with XpressConnect for at least a few years now. The blog post I just linked gives instructions for spoofing Ubuntu 10.04 (Lucid), but on my machine that caused the software to crash. Apparently, though, Ubuntu 14.04 (Trusty) is similar enough to the current Debian to make the software work. So I created the file
/etc/lsb-release (which does not typically exist on Debian) with the following content:
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"
This caused the software to run correctly, installing certificates in my
~/.certificates/ directory and configuring my wifi.
/var/log/syslog, I found the following:
Aug 17 09:29:18 parmenides wpa_supplicant: wlan21: CTRL-EVENT-EAP-STARTED EAP authentication started
Aug 17 09:29:18 parmenides wpa_supplicant: wlan21: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
Aug 17 09:29:18 parmenides wpa_supplicant: OpenSSL: tls_read_pkcs12 - Failed to use PKCS#12 file error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
Aug 17 09:29:18 parmenides wpa_supplicant: OpenSSL: pending error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
Aug 17 09:29:18 parmenides wpa_supplicant: OpenSSL: tls_connection_private_key - Failed to load private key error:00000000:lib(0):func(0):reason(0)
Aug 17 09:29:18 parmenides wpa_supplicant: TLS: Failed to load private key '/home/kenny/.certificates/Secure_WiFiKey.pem'
Aug 17 09:29:18 parmenides wpa_supplicant: TLS: Failed to set TLS connection parameters
Aug 17 09:29:18 parmenides wpa_supplicant: EAP-TLS: Failed to initialize SSL.
Aug 17 09:29:18 parmenides wpa_supplicant: wlan21: EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS)
Aug 17 09:29:18 parmenides wpa_supplicant: wlan21: CTRL-EVENT-EAP-FAILURE EAP authentication failed
Aug 17 09:29:20 parmenides wpa_supplicant: wlan21: Authentication with d8:c7:c8:e9:69:d4 timed out.
Aug 17 09:29:20 parmenides wpa_supplicant: wlan21: CTRL-EVENT-DISCONNECTED bssid=d8:c7:c8:e9:69:d4 reason=3 locally_generated=1
Aug 17 09:29:20 parmenides wpa_supplicant: wlan21: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="VU-Secure" auth_failures=1 duration=10 reason=AUTH_FAILED
~/.certificates, delete the wifi configuration it created, delete XpressConnect, and go back to the web interface to download. Once XpressConnect worked on the 'first' try, I had matching certificates.
(This printed several times for each connection attempt.) This one does not seem to be the fault of XpressConnect, so I took my problem to the wpa_supplicant folks on the HostAP listserv. wpa_supplicant lead developer Jouni Malinen helpfully responded the same day. Apparently the problem has something to do with a mismatch between the EAP fragment size and the MTU setting on the wireless device. My MTU was set to 1280 (I didn't change it, I don't know how it got like that); I was told the standard setting was 1500. You can set your MTU to 1500 by running (as root) the following command:
Aug 17 11:34:20 parmenides wpa_supplicant: l2_packet_send - sendto: Message too long
It appears that NetworkManager generally will not change this value. However, it may not persist across reboots. It is possible to set the MTU specifically for a network configuration in NetworkManager. To do so, right-click the NetworkManager icon and select "Edit Connections..." Edit the connection in question, and select the 'Wi-Fi' tab. At the bottom is a field for MTU. By default it's set to 'Automatic'. Set it to 1500 and hit 'Save'.
ifconfig wlan0 mtu 1500
Hooray for functioning wifi and a new school year! We now return to our not-so-regularly scheduled philosophy...Posted by Kenny at August 18, 2015 10:51 AM
Return to blog.kennypearce.net