Q: What's your Airport Card Country code?

So in Brazil, Australia and Spain we all have immigrant neighbours with powerful routers or have bought our's from a dodgy street trader...

This is only a wireless n problem and I would guess a coding error is returning incorrect strings to the computer or an absence of information is causing it to default to a particular value.

Since it is happening all around the world I don't think it is a router problem either unless they have something in common (like maybe a batch of routers were coded for France but subsequently shipped to Spain and Australia etc). But then it is happening on many different makes of router.

This still seems to be an Apple problem.

While there are certain commonalities it is in actuality a quite rare issue or we'd see literally hundreds of posts in this thread.

What the precise cause of this issue is remains to be seen, but I'm trying to describe that the country code comes directly from a received beacon packet, and it takes more than one line of bad code to get "FR" from "AU."

Maybe there are not so many posts on this because we function even with the error. Though I did wonder if it affects the ability of the computer to detect changes in Time Zone etc which could cause knock-on problems for travellers and synchronisation issues on MobileMe.

How is this for a scenario:

There is a switch statement containing a list of country codes. ZW happens to be the last on the list and FR is the pass-through value (for no better reason than the original programmer was French). If a nonsense value is given to the computer perhaps one of these two values gets passed on.

Maybe the problem is in the original 802.11d data packet, not how it is processed.

putnik wrote:
Maybe there are not so many posts on this because we function even with the error. Though I did wonder if it affects the ability of the computer to detect changes in Time Zone etc which could cause knock-on problems for travellers and synchronisation issues on MobileMe.

The AirPort country code has nothing to do with the time zone settings.

putnik wrote:
There is a switch statement containing a list of country codes. ZW happens to be the last on the list and FR is the pass-through value (for no better reason than the original programmer was French). If a nonsense value is given to the computer perhaps one of these two values gets passed on.

Maybe the problem is in the original 802.11d data packet, not how it is processed.

If the problem is in the packet, it's in the router sending it.

I sincerely doubt the "default" is FR; it would be US if anything.

Same problem with Locale/Country code reported: Today it says FCC/XO
Yesterday, it stated FCC/DE and the connection to my SiteCom WL342 on channel 13 was fine.

Today .... it doesn't even see my network !!!
I'm in The Netherlands. (My MacBook is imported from Canada)

I chose ch13 as that is giving best signal results. ch11 is clogged with signals from nearby.
I worked just fine .... but a neighbor signal seems to distort my preference ?!? changes my country code ?!?

I am convinced it is really a problem in the Airport code.

I finally got an answer from Belkin about possibly changing the country code transmitted from my router. Not very helpful!

Thank you for contacting Belkin Technical Support.

We understand that you have have a query about the regulatory domain on the Belkin router. We apologize for the delayed response.

We are sorry to state that, we do not have regulatory domain option on the Belkin router.

I wrote back to point out that many people were having the same problem, but wont hold my breath for an answer. My computers still both think they are in France.

gdraanen wrote:
Same problem with Locale/Country code reported: Today it says FCC/XO
Yesterday, it stated FCC/DE and the connection to my SiteCom WL342 on channel 13 was fine.

I assume you live in Germany?

X0 is a transitional code the AirPort drivers use when listening for an actual regulatory domain.

your answer was in next line (The Netherlands)

The SiteCom 342 possibly comes from germany, but surely I know where I live ?!?

The Airport should definitely not limit the channel list based on the 'production country' signal from the nearest router. Instead it should be looking at the date/time-timecode/location.

As it is.... whenever I loose connection to my WL342 on Ch13, I have to connect to a different router (the XO code stays that way all day) .... until I move my WL342 from Ch13 to e.g. Ch11.
Once the connection to the WL342 router has been re-established .... the country goes back to DE, and I can then switch the WL342 to Ch13.

I say... it's an error on the Airport code that it assumes that a router will "know better" than the Mac itself ! The router may have been fabricated anywhere..... but the country where the Mac is at that moment determines the allowable FCC channels.

I'm in The Netherlands, and not bound by USA law. We have our own regulators and rules.
I want to use Ch13 because it's a "clean" channel so I get a good signal.

What can be done to 'fix' the Airport locale/county aligned with the clock ?
That would fix it to TimeZone + 'Closest city'.

gdraanen wrote:
The Airport should definitely not limit the channel list based on the 'production country' signal from the nearest router. Instead it should be looking at the date/time-timecode/location.

It's not the "nearest" router; at the present time it's the first beacon packet received with a valid regulatory domain field when passively scanning after the Wi-Fi radio is enabled. Taking the regulatory domain information from the beacon packet is part of the 802.11d specification:

http://standards.ieee.org/getieee802/download/802.11d-2001.pdf

One could argue that if you are connecting to a particular SSID, the driver should use the regulatory domain of the router in question, but that's now how things are currently implemented.

Further, it's not where a router was manufactured, but rather where a router is licensed for sale. For example, it is almost certainly against the law in the Netherlands to use a Wi-Fi router purchased in the United States unless that router is licensed for use on frequencies in the Netherlands.

If you're curious, you can see the list of ISO two-letter country codes here:

http://www.iso.org/iso/englishcountry_names_and_codeelements

Feel free to express your comments to Apple on the issue here:

http://www.apple.com/feedback/macosx.html

I have provided my feedback as you suggested. I want the Mac/Airport to behave in a predictable way, based on elements within MY control. I can tell the Mac where it is, and I can assure that MY router is sending out 'legal packets'. I can however not control what my neighboring systems are transmitting.
When MY Mac listens to any 'outside' signal first, I will disable even listening to MY signals.

This is unacceptable behavior, not shown by any of my other (Windows) systems.
Those can always connect to my Ch13.

I know you know where your Mac is, but if Apple made it user-settable, a user could manually set their machine to use frequencies illegal for use in their country, and I suspect that's Apple's main concern.

As stated in an Intel document:

802.11d In Operation

A Station (MU) that is enabled for operation across regulatory domains will default to passive scanning when it has lost connectivity with its ESS or when first powered on. Passive scanning is performed using only the receive capabilities of the station and is, thus, compatible with regulatory requirements. The timeout for determining the loss of connectivity is system dependent and beyond the scope of the standard.

When a STA enters a regulatory domain, it shall passively scan to learn at least one valid channel, i.e., a channel upon which it detects 802.11 frames. The Beacon frame contains information on the country code, the maximum allowable transmit power, and the channels to be used for the regulatory domain.

Optionally, the Beacon frame may also include, on a periodic basis, the regulatory information that would be returned in a Probe Response frame. Once the Station has acquired the information so that it is able to meet the transmit requirements of the regulatory domain, it shall transmit a Probe Request to an AP to gain the additional regulatory domain information contained in the Probe Response frame, unless the information was previously received in a Beacon fame. The Station then has sufficient information available to configure its PHY (radio) for operation in the regulatory domain.

http://download.intel.com/support/wireless/wlan/pro2011b/accesspoint/overview.pd f

I'm not trying to say that Apple's is the best or only way to handle 802.11 regulatory domains, but the standard is less than completely clear on how it must be interpreted.

This may not be an issue with your Windows systems because many Windows Wi-Fi drivers do not yet support 802.11d.

The Linux folks have gotten around this by programming wireless drivers thus:

Linux allows changing regulatory domains in compliance with regulatory restrictions world wide, including the US FCC. In order to achieve this devices always respect their programmed regulatory domain and a country code selection will only enhance regulatory restrictions. This is in accordance with the FCC part 15 country code selection knowledge base publication number 594280. As an example if your device was programmed for operation in the US which allows operation on channels 1-11 on the 2.4 GHz band and you visit Japan which allows operation on channels 1-14 and you change your regulatory domain to JP you will not be able to use channel 12, 13 or 14 (CCK). But if you have a device programmed for operation in Japan and visit the US and you select US as your regulatory domain you will have channel 12-14 disabled.

http://linuxwireless.org/en/developers/Regulatory/CRDA

Presumably on a secure network the wifi password would enable the computer to pair with the right router?

Message was edited by: putnik

It doesn't matter which router you connect to; the country code is based on the first beacon packet received with a valid regulatory domain while passively scanning for routers upon activation of the interface.