Binary package hint: network-manager
My name is Luke Hoersten and I'm the Purdue Linux Users Group
president. Last year, Purdue University released a new wireless system
for students to connect called PAL2.0 (Purdue Air Link). It uses
WPA-Enterprise and unfortunately doesn't work with NetworkManager.
It's keeping many students from switching to Ubuntu (Purdue has 40,000
students so the amount of perspective Linux users is high).
The way PAL2.0 works is as such:
1. Students first connect to an ESSID called PAL2.0-Instructions which
serves one web page to tell Windows users how to connect to PAL2.0.
It's essentially a hidden ESSID.
2. NetworkManager connects to PAL2.0-Instructions fine. Then with NM,
one must use the "Connect to Other Wireless Network..." feature and
type PAL2.0 as the ESSID to connect to.
3. Maybe every 1 in 500 times NM is able to find PAL2.0, prompt for
the WPA-Enterprise info, and connect.
Most of the time it never connects and even sometimes crashes nm-applet.
I've got in contact with the head wireless IT guy at Purdue and asked
him for any and all info he can give. I'd appreciate if you could go
through his email and see if you can find why PAL2.0 and NM don't play
nice. Here's what he said:
---------- Forwarded message ----------
From: Case, Brandon J
Date: Sep 3, 2007 9:49 AM
Subject: RE: FW: PAL2.0 and Ubuntu
To: Luke Hoersten
Luke,
The authentication method for PAL2.0 is formally known as
WPA-Enterprise. It's configured like any other WPA-Enterprise network
would be. WPA technically specifies some kind of encryption and some
kind of authentication mechanism with EAP (be it TLS, TTLS, PEAP, etc.).
We use TKIP encryption for two reasons: it's guaranteed to work with any
WPA-compliant wireless card and most of our access points don't support
WPA2 since they are older (you'll notice we only have 11b service most
everywhere on campus). We also are using PEAP for authentication since
it's the only password-based method available: all others require a
client certificate.
To understand the PAL2.0 connection process you'll need to know some
basics about wi-fi, mainly that associated and authenticated are two
different states and that one can't happen without the other happening
first. It's always associate, then authenticate. In the case of
PAL2.0-Instructions there is no secure authentication method specified
("open" in the SSID configuration) so there is no formal authentication
process. With PAL2.0 you can associate but before any kind of even Layer
2 connectivity is allowed you must be authenticated by the access point.
In our case this is done with a standard RADIUS authentication process
(using I2A2 as the actual username/password database) and this is where
your credentials are verified and the necessary encryption keys are
negotiated. After you've been authenticated the access point allows
Layer 2 traffic which lets you obtain a DHCP address and off you go.
Our access points have VLAN support so yes there is only one set of
access points on campus that run PAL2.0-Instructions, PAL2.0, PAL and
the other SSIDs we use from time to time. From each AP, the BSSID is the
same for every SSID: the MAC address of its radio interface. The AP
keeps track of clients by SSID even though technically they're all on
the same BSSID. There is another method of handling multiple SSIDS
called mbssid which essentially successively adds to the radio MAC
address every time there is a new SSID, resulting in a unique BSSID for
each SSID. This also allows each SSID to be broadcast instead of just
one. Again, most of our access points do not support this but a handful,
comparatively, do so for consistency's sake (necessary when you manage
~1400 access points) we leave mbssid off.
The only spot of troubleshooting details I can give that would be
helpful are from my attempts to get NetworkManager working. I noticed in
/var/log/syslog that wpa_supplicant is trying to connect, repeatedly, to
an all 0's BSSID. Eventually it blacklists it but it seems as if
sometimes it connects and sometimes it does not without any real rhyme
or reason why. I had the same results with ndiswrapper and the madwifi
driver (Dell 1450 abg USB adapter and Intel 3945ABG respectively). This
could be the result of PAL2.0 not being broadcast but if the driver
properly sends and receives probe requests and responses it should be
able to determine the proper BSSID for PAL2.0 before it tries to
associate.
Let me know if you need any more details, I know that was a lot.
Brandon
Thanks for (finally) open this bug.
So if I understand what you say correctly, your APs have to be hidden because you cannot use mbssid, right?
Anyway, please attach the syslog for now.
Thanks,
- Alexander