In Argentina it’s quite difficult to buy a wifi router which is configured correctly for use in this country (with the exception of those that come “free” with your cable etc.). The majority of network equipment that you find here is bought (over the counter) in other countries, and imported through “unofficial” channels. This presents a problem with wifi routers, which are often configured for another regulatory domain — as generally those who use them don’t bother (or don’t know how) to fix them.
I live in an highly congested wifi zone (a kismet scan run from my laptop yesterday found an incredible 4200 distinct stations!). A few hundred of these are access points, most have 802.11d enabled, and many of these transmit a country code that is not AR (i.e. Argentina). Aside from probably being immoral, that’s not such a big deal. But …
Enter Mac OS X.
Apple, being the well behaved company they are, create operating systems which strictly obey the regulatory restrictions of the country they are in. When you turn on wifi on your apple hardware, before transmitting *anything*, it listens for wifi beacons, and the first one it hears (which includes an 802.11d country code) dictates the wifi channels it will allow you to use. In the system logs this shows up as follows:
09/06/2012 17:26:44.000 kernel: en1: 802.11d country code set to 'AR'. 09/06/2012 17:26:44.000 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 149 153 157 161 165
This is fine when the first one it hears is correct (as it is above). But if the first one it hears is incorrect, then it will incorrectly restrict you to the channels available in *that* country. And often that restriction means you cannot connect to *your* access point, especially if you are using 5GHz channels (i.e. channel 34 or higher). For example, two country codes I often get are CN (i.e. China – permitting only channels 149 to 165 in the 5GHz band), and CZ (i.e. Czech Republic – permitting only channels 36 to 140 in the 5GHz band). There is no overlap between these two countries (at least in the uncongested 5GHz band) – so whatever channel you chose, sometimes you won’t be able to connect to it.
And apparently there is no way to disable wifi regulatory compliance in OS X.
When I discovered the cause of this (which appears to the end user as an intermittently broken wifi router), I had hoped to mitigate it by enabling 802.11d in my dd-wrt routers, setting the country code to ‘AR’, and shortening the beacon interval (to increase the likelihood that this would be the first beacon the client “hears”). There is no GUI for this in dd-wrt (there used to be in the past, not sure why they removed it), but it should be possible to do this using broadcomm’s wl command:
wl -i eth1 radio off # disable the radio wl -i eth2 radio off # disable the radio wl -i eth1 country AR # set the 2.4GHz radio - this gives an error wl -i eth2 country AR # set the 5Ghz radio - this also gives an error wl -i eth1 regulatory 1 # no response, but I think this fails also, as 'wl -i eth1 regulatory' returns nothing wl -i eth2 regulatory 1 # again, no response (also tried "on" for this, which gives an error) wl -i eth1 radio on # enable the radio again wl -i eth2 radio on # enable the radio again
(example above is for the 2-radio e4200, hence the repeated commands for eth1 and eth2).
But anyway, this doesn’t work. The lines above give errors, and 802.11d simply isn’t enabled.
I have accidentally discovered that if you
nvram set wl0_reg_mode="on" nvram set wl1_reg_mode="on" nvram commit
and then restart the router, then you *can* get 802.11d broadcasts enabled, but they are for the country AL (i.e. Albania), helpfully noticed by dd-wrt forum poster Shii here to be the first entry in the
allCountries array in country.c. Unfortunately changing the highly tempting
wl#_country_code values (both by default set to “EU”) to something else seems to make no difference, you still get “AL” in the 802.11d broadcasts. And unfortunately Albania has extremely restrictive wifi rules, which forbid the use of 5GHz channels altogether (or at least that’s what linux thinks, and I assume that it’s correct).
Update (Jan 2013): Ok, I don’t have a fix for this yet, but I’ve just discovered a useful way to identify which AP is sending the incorrect 802.11d broadcasts (at least on OSX).
1. While holding down the option/ALT key on your keyboard, click the Wifi icon on the menu bar.
2. One of the options in the menu should be “Open Wi-fi Diagnostics…” – click this
3. This will open the Diagnostics tool: go to the “File” menu and click “Network Utilities” (or just type Command+N).
4. In Network utilities, click the Wi-Fi Scan tab. This shows a bunch of useful info about nearby access points:
The last column “CC” (country code) clearly identifies the culprit.
Update (Jun 2013): The diagnostic tool has moved (at least in 10.8). It’s now to be found in option/ALT -> Wifi Icon -> Open Wireless Diagnostics… -> Window -> Utilities (or Command+2)