Related link: http://www.washingtonpost.com/wp-dyn/articles/A38700-2004Apr24.html

I was interviewed last week for this article, which is part of a bundle of articles on 802.11. Most of what I talked about found its way into print, but there were a few items I mentioned that didn’t make the final cut that I’ll list here. As long as I’m at it, I might as well toss in a few points that I didn’t mention because they were beyond the scope of the article:

• Major trade shows that have Internet connections dropped on to the floor will have problems with channel overlap. CeBIT is hardly unique–I’ve seen the same problems at Networld+Interop in Las Vegas. The best we can do is keep the power down to avoid overlaps between the APs, and be friendly by limiting transmit power to cover only the area you want.
• There is no way for an 802.11 network to control client power settings. There is some standards work that would enable APs to send messages to clients to adjust power settings, but it’s not done yet. If the client computers are set for maximum power, their range will be much greater than the low-power APs, and a single client may potentially interfere with several APs. (I did not mention this because it was beyond the scope of the story.)
• I’m pleased to see the microwave oven mentioned only in passing. By definition, microwave ovens should be shielded pretty well because they need to keep the energy in the oven to cook the food. Three years ago, Rob Flickenger ran some tests, and found the microwave didn’t really affect throughput. If your microwave is affecting throughput, you should replace it because it might pose a danger.
• In suburban residential areas, homes are probably far enough apart that automatic channel assignment technologies can help out. Dynamic channel assignment is one of the new features of new high-end 802.11 equipment targeted at the corporate market. It may be only a matter of time before the capabilities filter down to lower-end devices.
• We talked a lot about cordless phones. My general rule is that expensive cordless phones are better for non-interference with 802.11. Part of the reason is that the cheaper phones assume that they own the entire ISM band and modulate accordingly, using the entire 80 MHz of spectrum. Higher-end cordless phones use frequency-hopping technology, which is somewhat kinder to other users of the band. Anecdotally, the Siemens Gigaset doesn’t seem to interfere with 802.11b networks. (The Gigaset is a multi-handset system, and they probably need to use fancier technology so the handsets don’t interfere with each other.) However, some of the people I know with the Gigaset aren’t particularly fond of it for other reasons.
• Naturally, the easiest way to avoid having your cordless phone interfere with your 802.11 is to make your cordless phone an 802.11 station. If you subscribe to a VoIP service that uses SIP, you have several choices. I haven’t yet subscribed to a VoIP service because I need to have a land line to support my DSL service, and long distance is very cheap these days. Between free night and weekend calls on my mobile phone and a cheap long distance provider, I just don’t need to subscribe to an additional telephony service. What I’d like is to get an 802.11 cordless phone. I don’t really care whether the phone is done as a SIP gateway appliance that I can plug into my phone, or an VoIP-to-phone line bridge I can plug into my home Ethernet.
• One small correction: I think the high-tech neighborhood I referred to in the article was North Carolina, not Florida. For a previous Associated Press story, I referred the reporter to fellow O’Reilly author Chuck Musciano. The AP story refers to his neighborhood in North Carolina.

One other amusing note about the story. I built the network at my parents’ house a bit more than a year ago. It’s much simpler than my home network, so I find it amusing that their network was mentioned in the press before mine!

Do you have a cordless phone in the same frequency band as your 802.11 network? If so, what has your experience with interference been?

Related link: http://sourceforge.net/projects/madwifi/

As part of my ongoing saga with xsupplicant, I wanted to use a modern card that is widely deployed. The Hermes chipset is everywhere, but it is no longer an interesting hardware design. I recently worked with a client to get xsupplicant running on Atheros-based cards. xsupplicant installation is the same as in my previous note; this message is a guide for the Atheros card only.

Test Configuration

I did this on a SuSE 9.0 system, which uses kernel version 2.4.21. I did try briefly to get it running on a 2.6 kernel using a different distribution, but I didn’t have enough time to figure it out.

The target card is a Linksys WPC55AG card, which is based on a dual-band/tri-mode Atheros chipset. It supports a+b/g. There was no hardware version apparent on the card. Atheros chips do not have firmware, which is a boon. There is a single Linux driver, the madwifi project, for all Atheros-based cards. It consists of three components, a hardware driver (ath_pci), a hardware abstraction layer (ath_hal), and an 802.11 module (wlan). The HAL is a binary-only package; I worked with ath_pci ver 0.8.5.4, and wlan version 0.7.3.1.

The reason for the HAL is to satisfy regulatory requirements. In order to meet regulatory requirements, the card needs to enforce certain channel and power limits. The binary-only HAL allows Atheros to meet this requirement by distributing the HAL to prevent users from arbitrarily setting the card to do something that might not be allowed.

Requirements

You must have UUCP tools for uudecode. The madwifi driver depends on the binary-only HAL to comply with regulatory requirements. It is distributed as a uuencoded file, so you will need to get uudecode to recover the binary-only object. On most Linux distributions, this is in the sharutils package.

The driver is updated regularly, and does not appear to be packaged for distribution on a regular basis. You will want to fetch the latest version from CVS. If you don’t have CVS, get the package from your favorite distribution.

Building the driver

You should fetch the latest version from CVS:

# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/madwifi co madwifi

That will copy the source for the driver to a directory called madwifi. To build the driver, use the standard open-source command set:

# cd madwifi
# make
  (lots of build messages)
# make install

In the case of this test system, I manually installed the driver. SuSE 9.0 includes the madwifi driver as part of the distribution, but the driver is too old to be effective. So, I determined where the driver was loading from in /lib/modules and manually copied my new modules over. When you install new modules, you will need to run “depmod -a”; make install may do this for you.

Using the driver

Loading the driver creates an interface prefaced with “ath”. Most likely, it will be ath0, since you will only have one Atheros card running in your system. (Older versions of madwifi used the prefix “wlan”. If you see “wlan”, you probably need to update your drivers.)

As in the case of Hermes-based cards, you need to set a static key to force the card and driver into the encrypted mode. It is a dummy key that won’t be used. madwifi uses iwconfig, so the command set is the same as it is for the Hermes card that was in the last note:

# iwconfig ath0 key 12345678901234567890123456
# iwconfig ath0 essid "MyNetwork"
# ifconfig ath0 up

After running those three commands, the card will come up and start scanning to find an AP. Once it associates, the AP MAC address will be filled in in iwconfig. You can run Xsupplicant just like before, and it will authenticate and plumb the keys. Afterwards, if you run iwconfig, you will see the key in use for your station:

# iwconfig ath0
ath0      IEEE 802.11  ESSID:"myssid"
          Mode:Managed  Frequency:5.28GHz  Access Point: 00:0B:0E:00:F0:43
          Bit Rate:36Mb/s   Tx-Power:off   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:E452-94AC-09DB-2200-1256-6D7D-74   Security mode:open
          Power Management:off
          Link Quality:31/94  Signal level:-64 dBm  Noise level:-95 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Related link: http://cvs.sourceforge.net/viewcvs.py/open1x/xsupplicant/src/eap_types/mschapv2/…

In many corporate environments, the Microsoft infrastructure is well-entrenched. Users and computers are defined in Active Directory, and the Internet Authentication Server (IAS) is a natural front-end. One of the major issues with using xsupplicant is that it has had PEAP support for quite some time, but the PEAP implementation was not interoperable with the IAS PEAP implementation.

This week, I’m at the Interop Labs, volunteering at the LAN Access Security Initiative. One of the major assets of a test event like this is the wide array of hardware and expertise that can be brought to bear on interoperability problems. Most vendors send high-level talent to the staging event, so there’s a deep pool of talent and knowledge to work on interoperability problems that come up.

When I learned that Chris Hessing and Terry Simons, two of the three Utah Geeks from the Open1X project were coming, I wanted to work on finding out why interoperability with the IAS PEAP implementation wasn’t working. We were able to quickly verify that the PEAP implementation in xsupplicant was essentially functional by testing it against FreeRADIUS, and succeeding. When running against IAS, though, the authentication would die part of the way through the sequence, and there would be no error in the IAS log. (I believe that no error was logged because the authentication sequence never completed, so there was no result to log. Unfortunately, the lack of usable log information makes troubleshooting much more difficult.)

Eventually, by comparing network traces from the FreeRADIUS authentication to the IAS authentication, and enabling EAP-MSCHAP-V2 authentication over the air on IAS, we were able to trace the problem to a set of boundary conditions on transmitting the response. It appears that part of the reason why authentication was failing against IAS is that Microsoft was performing stricter checks against the received authentication frames than other vendors.

One of the key points of this experience is the “reality check” role that open source tools can play. Wireless security standards are a complex beast. One of the key data points we obtained early on was that the xsupplicant PEAP implementation was fundamentally sound, though it had a minor implementation error. At the iLabs, we have a wide variety of implementations to play with, and our copies are donated by vendors as a technology demonstration. Most users will be unable to assemble a similar testbed composed of expensive commerical products, and will instead rely on zero-cost open-source tools such as FreeRADIUS.

Will you be using xsupplicant’s PEAP implementation against IAS? Or do you prefer TTLS instead?