Thursday, 5 April 2012

5GHz WiFi on your Mac got you down? 802.11d is your problem

Early one stormy morning our house was struck by lightning. Along with a TV, the phone, an ADSL modem and the sensors on our garage door I lost my prized Cisco 1142 wireless access point. My neighbour had it worse. Just about everything electrical was destroyed (his DSL filters were little more than charred remains).

While waiting three weeks for the phone lines in the street to be repaired by Telstra I pondered what I should replace the Cisco with. I had received the Cisco WAP as part of a training course at work. As they cost a fortune buying one was out of the question, but I wanted something comparable with the ability to do channel bonding in the 5GHz range (channel bonding is part of the 802.11n spec that lets you to combine two adjacent non-overlapping 20MHz channels into one 40MHz channel effectively doubling your wireless bandwidth. As there are more non-overlapping channels in the 5GHz band than in the 2.4GHz band and less consumer devices using that band it means less interference and more wifi awesomeness). Given the number of Apple devices in the house I figured I would give Apple's AirPort Extreme a try (plus I could setup Time Capsule backups of my MacBook Pro by connecting an external drive to the USB port on the Extreme as an added bonus even though technically this isn't supported by Apple).

After setting up the Extreme I was suitably impressed with the signal strength and the throughput on the 5GHz band. However, every now and again on wake my MacBook Pro running Lion wouldn't reconnect to the SSID I had setup for the 5GHz band. In fact it couldn't even see the SSID when I would run a Wi-Fi scan using a scanner like iStumbler. The SSID was still visible on my iPad and other devices with 5GHz antennas so I knew the problem was with the MacBook Pro (and possibly Lion) and not the Extreme. Turning the Wi-Fi off and on would result in it being able to be able to reconnect but usually only after a few cycles.

Looking at the logs in the Console utility I noticed something odd. Every time I switched the Wi-Fi off and on I would get messages regarding 802.11d, country codes and a list of supported channels:

5/04/12 8:27:12.000 PM kernel: en1: 802.11d country code set to 'GB'.
5/04/12 8:27:12.000 PM kernel: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140
5/04/12 8:28:45.000 PM kernel: en1: 802.11d country code set to 'X1'.
5/04/12 8:28:45.000 PM kernel: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48 52 56 60 64 149 153 157 161 165
5/04/12 8:28:46.000 PM kernel: en1: 802.11d country code set to 'US'.
5/04/12 8:28:46.000 PM kernel: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140 149 153 157 161 165


The country codes alternated between GB (Great Britain), AU (Australia), US (United States) and X1 each with a different set of supported channels listed (You can see which 5GHz channels are supported in which countries here). According to Wikipedia 802.11d is "is an amendment to the IEEE 802.11 specification that adds support for additional regulatory domains". In other words it's a way for the wireless adapter in your device to simply listen for a beacon that tells it which regulatory domain it's in and then enable only the channels that are allowed in that domain. This makes it a lot easier/cheaper for hardware manufacturers as they only need to make one chipset rather than one for each regulatory domain (In the past you had to purchase a wireless device that was configured for your domain e.g. Japan, Europe, US, etc.). It also means you can take your hardware overseas and shouldn't have any problems.

There is a big problem with this.

Essentially, when the MacBook Pro is waking up it looks around for an 802.11d beacon. This beacon can come from any wireless access point nearby and not just my access point (i.e. any of my neighbours' access points). Once it has found a beacon it simply sets the supported channels in the hardware to match. The problem is my neighbours have their APs set to the wrong domains instead of AU (They're not tech savvy so I know it's not their fault).

Why didn't I experience this problem when I was using the Cisco access point?

I live close to a small airport (not the Apple kind!). When I first installed the Cisco 1142 I had it set to Dynamic Frequency Selection (DFS) for the 5GHz band. This is a scheme that not only tries to select a channel with little interference but also kills broadcasting for a period of time if it detects a radar signal. After I had installed the Cisco and the wireless had shutdown on me a couple of times I clued in to the fact that it was most likely radar from the airport or a plane overhead causing it. Fortunately that radar is in what's called the U-NII Worldwide radio band between 5470 and 5725 MHz or channels 100 and 140. This is a chunk of spectrum roughly in the middle of the 5GHz band used by wireless devices so I simply set the Cisco to use one of the channels below the U-NII radar band such as 40 and never looked back.

Turns out channel 40 is in all regulatory domains except China so it didn't matter which 802.11d beacon the MacBook Pro picked up as channel 40 was always supported and I was oblivious to any problem. Remembering the issues I had with radar shutting down the Cisco WAP, when I setup the AirPort Extreme I made sure I set it on a fixed 5GHz channel only this time I chose channel 149 which is above the U-NII radar band. Turns out channel 149 isn't useable in Europe, Turkey, Israel and South Africa so when the MacBook Pro was picking up a Great Britain 802.11d beacon it was switching off that channel in the MacBook Pro's hardware and that's why I couldn't reconnect to wireless.

I've now set it to channel 36 on the Airport Extreme and it's all good. That is until everybody else nearby tries to crowd into the same channel space with their access points...



Now off to my neighbours to fix the country codes in their access points!