UNI Wireless
From CedarLUG
Contents |
[edit] Thawte Certificate Locations
UNI uses certificates issued by Thawte to verify that you are indeed connecting to the UNI network. Use of these certificates is optional on the client side, but recommended. Many distros include the needed pieces by default, at the following locations:
Ubuntu's default location is /etc/ssl/certs/Thawte_Server_CA.pem
Fedora stores it at /etc/pki/tls/certs/ca-bundle.crt
If those both fail, you can download it manually from http://www.thawte.com/roots/index.html
[edit] Paul Gray's wpa_supplicant solution
For posterity, and for those interested in "how this works" for me:
I use Debian with wpa-supplicant. I've used Broadcom, Intel, and (my favorite) Atheros chipsets very reliably with the setup described below.
The setup that I have integrates networking and wpa_supplicant through reverse /etc/network/interfaces hooks.
"Reverse hooks" is basically telling the network subsystem that you intend to use wpa_supplicant for the wireless interface, so go check the settings in /etc/wpa_supplicant/wpa_supplicant.conf for what to do. Each particular wpa_supplicant entry has an associated 'id_str' that tells how to configure the authentication based upon the access point you're associating with, which then points back into /etc/network/interfaces to tell the network subsystem how to subsequently configure the IP assignment after authentication has been carried out. It's not really as confusing as it sounds though. Take a look at my Atheros chipset using the ath9k driver:
--------- /etc/networking/interfaces --------------
auto wlan0
iface wlan0 inet manual
wpa-driver wext
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface home inet dhcp # This is wpa for my house in CF - see below
iface campus inet dhcp # This is wpa for campus - see below
------------ end snip ------------------
The magic automation then gets read from the corresponding entries in /etc/wpa_supplicant/wpa_supplicant.conf:
------- /etc/wpa_supplicant/wpa_supplicant.conf -----------
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
network={
ssid="WiFi-UNI"
scan_ssid=1
key_mgmt=WPA-EAP
eap=PEAP
identity="gray@ad.uni.edu"
password="N0,Th!$1sN0tmyP@$$w0rD"
id_str="campus"
ca_cert"/etc/ssl/certs/Thawte_Server_CA.pem"
phase1="peapver=0, tnc=soh, crypto_binding=0"
phase2="auth=MSCHAPV2"
}
network={
ssid="myhomeessidwhichdoesnotbroadcast"
scan_ssid=1
psk="anotherpasswordthatiwouldnotposthere"
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP WEP104 WEP40
eap=TTLS PEAP TLS
id_str="home"
}
------------ end snip ------------------
A suggestion that I have for those that run into problems with their wireless: Never reboot to solve the problem. Sometimes a module reload is all that you need to reset the hardware.
So how do you know that your hardware needs to reset or your driver reloaded?
The most helpful suggestion I can offer is this: See if your wireless card is both transmitting and receiving packets. The easiest way to do this is to fire up "wavemon" in a terminal. "wavemon" is an ncurses program that shows signal strength along with TX and RX statistics in real time. Easy. Visual. Immediate.
If you manually try to configure your wireless adapter in another console (dhclient wlan0, for example), and see (i) no association to your access point, (ii) no increase in the Tx stats when you're supposed to be issuing DHCP requests, or (iii) no increase at all in your Rx statistics, then it's not your negotiation that's failing...it's likely your driver.
Even if you're not associated with an AP, you should still be broadcasting and receiving beacons that would influence your Tx and Rx statistics.
If you see something out of sorts, the next thing to do would be to remove and reload your wireless module. To remove the module, you will need to clear out all things that are using the driver, including wpa_supplicant. What I do is:
/etc/init.d/networking stop ifdown --force wlan0 # <-- this clears any wpa_supplicant interference
Then,
rmmod ath9k (or rmmod iwl4965, bcm5974, etc)
and subsequently load it back up
modprobe -a ath9k
(you may want to tail dmesg after this step to see if there are firmware issues or other gems being dropped in your logs to help you.)
If you get errors about unloading the modules, then it's likely that you just need to remove other module dependencies in addition to your wireless driver. Follow your nose.
Start things back up:
/etc/init.d/networking start
[Configure your network accordingly...]
This method of "last resort" occasionally applies to my Dell Inspiron 1420 (Debian) after coming out of pm-suspend. Occasionally it goes into a continuous associate/drop/rekey cycle with an access point and needs a driver reset.
Another good command-line to run to see if your network card is seeing the network is:
iwlist wlan0 scan
This will show you if your card knows about the APs in the area. If it comes up blank and there are APs around, it's likely that a driver reload is required.
Or it means that you accidentally pressed that little "disable antenna" button on the side of the laptop again. But that would just be embarrassing to think that you tried all of the above diagnostics to fix your wireless driver only because your antenna was disabled.
[edit] Adding certificate support to Dr. Gray's Method
You simply need to add the following line to the network {} block:
ca_cert="/etc/ssl/certs/Thawte_Server_CA.pem"
Be sure to use the proper location for the cert.
[edit] Graphical NetworkManager Solution
Connecting to WiFi-UNI with:
Ubuntu 9.04 (Jaunty Jackalope) Ubuntu 8.10 (Intrepid Ibex) Fedora 11 (Leonidas)
1. Click the NetworkManager applet (a pair of superimposed monitors, typically in the upper bar on the right), and select IU Secure. The Wireless Network Authentication Required window will appear.
2. Configure the settings as follows:
* Next to "Wireless Security:", select WPA & WPA2 Enterprise.
* Next to "Authentication:", select Protected EAP (PEAP).
* Leave the "Anonymous Identity:" field blank.
* Click the button next to "CA Certificate:", and then browse to the Thawte certificate.
* Next to "PEAP Version:", choose Version 0.
* Make sure "Inner Authentication:" is set to MSCHAPv2.
* Next to "User Name:" and "Password:", enter your UNI AD username (ends in @ad.uni.edu) and passphrase, respectively.
Note: Do not check Show password, as it will display your Network ID passphrase in clear text.
3. Click Connect. If the connection fails, you will be prompted to re-enter configuration details.
When you successfully connect, you'll see a series of blue bars of increasing height in place of the superimposed monitors.
