One of the recent fun challenges at work has been to get the developer R61i laptops running CentOS 5.1 to talk to our wireless AP (or their home AP). I’ve gone through 3 different drivers in an effort to get it working, and it’s come down to the one I really didn’t want to use - NDISwrapper. Unfortunately, even NDISwrapper doesn’t work properly.
The first driver tested was the ipw3945 from the Intel sourceforge site. This is the one that requires the binary-blob regulatory daemon that supposedly does way more than Intel claim it does (there’s a BSD driver for the same card, and the author reckons that the daemon has things like signal strength algorithms etc built in). This driver could find the card, but I could never get a link to the access point. Using wpa_supplicant gave me:
Removed BSSID 00:03:6f:95:45:88 from blacklist
State: ASSOCIATED -> COMPLETED
CTRL-EVENT-CONNECTED - Connection to 00:03:6f:95:45:88 completed (reauth)
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Setting scan request: 0 sec 100000 usec
Added BSSID 00:03:6f:95:45:88 into blacklist
State: COMPLETED -> DISCONNECTED
Yes, somehow, the driver or wpa_supplicant decided to blacklist the very access point that it was configured to talk to. That’s not very useful. Then there was the need to remove the ieee80211 module as well, and reload it, otherwise I got lots of wonderful errors like “ipw3945: Unknown symbol alloc_ieee80211“. That’s understandable though, because the module got updated, and had to be reloaded.
The second driver to be tested was the iwlwifi driver - again an Intel project. This one doesn’t have the regulatory daemon, but does have a firmware microcode. Not a problem, the various third-party repositories have copies of all of this, pre-built in RPM format (ATrpms in this case, and it’s 20 tiny versions behind the Intel release). Download, install, try to load.
mac80211: Unknown symbol ieee80211_led_rx
Ah, very useful. Missing symbols in the ieee80211 module. The problem is, where I got the mac80211 module from doesn’t seem to have a newer ieee80211 module with the appropriate symbols. I don’t need the LEDs to work, but there’s no trivial way to override missing symbols. This, therefore, means I can’t see if the iwlwifi driver actually works.
Finally, the solution that actually gets iwconfig to show ‘associated’ is to use ndiswrapper. I really didn’t want to go this route, but if it works, then it works and solves an outstanding ticket in my queue. I grabbed the Dell driver from the ndiswrapper wiki link. Unfortunately, it only half works. wpa_supplicant is able to find the card and drive the requests (using wext as the card type, not ndiswrapper, go figure), but watching iwconfig shows that the card is constantly losing the association with the access point, and eventually gives up the ghost. Ping tests show about 20% packet loss (and the AP is less than 50 feet away), with ping times in the 500ms to 5000ms range.
wpa_supplicant goes into spam loops too:
May 19 16:46:58.397419: State: COMPLETED -> ASSOCIATED
May 19 16:46:58.397447: Associated with 00:03:6f:95:45:88
May 19 16:46:58.397458: WPA: Association event - clear replay counter
May 19 16:46:58.397468: EAPOL: External notification - portEnabled=0
May 19 16:46:58.397477: EAPOL: SUPP_PAE entering state DISCONNECTED
May 19 16:46:58.397487: EAPOL: SUPP_BE entering state INITIALIZE
May 19 16:46:58.397505: EAPOL: External notification - portValid=0
May 19 16:46:58.397524: EAPOL: External notification - portEnabled=1
May 19 16:46:58.397533: EAPOL: SUPP_PAE entering state S_FORCE_AUTH
May 19 16:46:58.397542: EAPOL: SUPP_BE entering state IDLE
May 19 16:46:58.397557: Cancelling authentication timeout
May 19 16:46:58.397567: State: ASSOCIATED -> COMPLETED
May 19 16:46:58.397578: CTRL-EVENT-CONNECTED - Connection to 00:03:6f:95:45:88 completed (reauth)
Not very useful. It also appears that it just caused the laptop to lock up when called from kNetworkManager. Wonderful.
