Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

What's your Airport Card Country code?

I live in Brazil, and bought my 17" MBP from Canada in June, and my airport Country Code right now is ZW (Zimbabwe). When i'm at college, it jumps to US. And at home, it changes to ZW. This is a problem as in some countries some frequencies are now allowed. I have the 10.6.1 SL.

It's seems that either I have a faulty Airport Card, or Snow Leopard changes the card locale depending which routers are available for connection.

So, I wanted to know if anyone is seeing somethig weird as I am in the Airport Country Code.

Here's what I see in my info. The problem is that I can't use Wireless N in this country code.

Software Versions:
Menu Extra: 6.0 (600.22)
configd plug-in: 6.0 (600.27)
System Profiler: 6.0 (600.9)
Network Preference: 6.0 (600.22)
AirPort Utility: 5.4.2 (542.23)
IO80211 Family: 3.0 (300.20)
Interfaces:
en1:
Card Type: AirPort Extreme (0x14E4, 0x8D)
Firmware Version: Broadcom BCM43xx 1.0 (5.10.91.19)
Locale: FCC
Country Code: ZW
Supported PHY Modes: 802.11 a/b/g
Supported Channels: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
Wake On Wireless: Supported
Status: Connected


To check this out, it's under

About This Mac/

More Info.../

Airport/

17" 2.88 Ghz MBP 5.2 500GB 5.4K Hitachi, Mac OS X (10.5.7)

Posted on Sep 30, 2009 6:25 PM

Reply
32 replies

Oct 30, 2009 2:08 AM in response to putnik

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."

Oct 30, 2009 5:20 AM in response to putnik

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.

Oct 30, 2009 9:11 AM in response to putnik

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.

Oct 30, 2009 9:11 AM in response to putnik

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.

Nov 23, 2009 12:08 PM in response to andre.mengatti

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.

Nov 23, 2009 1:31 PM in response to Dogcow-Moof

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.

Nov 23, 2009 3:06 PM in response to Dogcow-Moof

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'.

Nov 23, 2009 8:50 PM in response to gdraanen

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

Nov 24, 2009 2:07 PM in response to Dogcow-Moof

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.

Nov 25, 2009 10:18 AM in response to gdraanen

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

Dec 1, 2009 4:03 AM in response to Dogcow-Moof

If computers all round the world are passively receiving incorrect country codes, then the router manufacturers or retailers must be guilty of gross negligence in supplying illegal equipment designed for other countries with different wireless regulations.

By the way I have got a further answer to my question to Belkin. Quote: "Unresolved, Closed".

What's your Airport Card Country code?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.