Comment 1 Andre Klapper 2009-10-23 14:56:12 UTC

Forwarding the internal comments:

"If we cannot determine the location we must default to US since all devices
must conform to FCC requirements.
In this case location info is just delayed and thus not yet available when
wlancond checks it after device mode changes from offline mode to normal mode. 
In practice only problem is that device does not get connected automatically to
WLAN (if channel is 12 or 13) immediately after mode change.
No problem during next automatic scanning or if user does a manual scanning.
The problem is valid, but there is no feasible fix for it ==> WONTFIX."

(In reply to comment #1)
> In practice only problem is that device does not get connected automatically
> to WLAN (if channel is 12 or 13) immediately after mode change.
> No problem during next automatic scanning or if user does a manual scanning.

Hm, that seems a bit buggy... Mine had been stuck to US since yesterday,
despite having had several "Fine accuracy" location fixes and cycling
offline/online mode a few times.  After a reboot it switched to EU 79" later.

What are the conditions that trigger a domain change exactly?

Comment 3 Andre Klapper 2009-10-23 16:20:29 UTC

(In reply to comment #2)
> What are the conditions that trigger a domain change exactly?

Wlancond get's DBUS signal from changed domain and then on the next connection
the domain is changed to correct one.

I think I am also seeing this effect. 

I'm using the N900 as an internet tablet, indoor only, without a SIM card, so
location data will never be available. Unless I'm missing something, there is
currently nothing I can do to make it realize it's in the EU? (this seriously
affects overall usability of the device in my case, therefore I've voted for
this bug, even if it's "WONTFIX" right now)

The device has regional settings, which are set to "Germany" in my case. Could
the WLAN driver perhaps use this as a fallback when no other location
information is available?

*** Bug 9424 has been marked as a duplicate of this bug. ***

Note that _scanning_ for channel 12 through 14 isn't harmful.

Well-configured access points emit regulatory domain information in their
beacon frames; country code, min/max channel, max transmit power. See 802.11d:
http://en.wikipedia.org/wiki/IEEE_802.11d-2001

That's what you should be using, if available, to learn the regulatory domain,
in precedence to the user's setting or the positioning information.

*** Bug 9517 has been marked as a duplicate of this bug. ***

As the duplicate bugs show, this is tied exclusively to the location determined
by the cellular network.  My own tests show that without a SIM installed the
domain stays set to US even with a "fine" GPS fix in effect and several
repeated WLAN scans.  This is both with an Amsterdam summit and a UK retail
device.

Additionally, even with a valid SIM installed the domain gets reset to US
whenever the cellular registration is lost (such as going into a building with
poor radio coverage).

Reopening as I'm fairly sure the current behaviour can be improved without
violating any foreign country violations (I suppose we should consider
ourselves lucky that Spain and France aligned with EU policy or we would be
stuck with channels 10 & 11 only).  Actually, according to
http://en.wikipedia.org/wiki/List_of_WLAN_channels, even in the US channels
12-13 can be used legally in low-power conditions.

I don't want to speculate randomly though, can we have a pointer to the
relevant FCC requirements so we can have an informed conversation about this?

Comment 9 Andre Klapper 2010-03-26 14:31:49 UTC

Forwarding internal comment:


(In reply to comment #6)
> Note that _scanning_ for channel 12 through 14 isn't harmful.

That's not true, we are doing active scanning which means that we send probe
requests on each channel.

> Well-configured access points emit regulatory domain information in their
> beacon frames; country code, min/max channel, max transmit power. See 802.11d:
> http://en.wikipedia.org/wiki/IEEE_802.11d-2001
> That's what you should be using, if available, to learn the regulatory domain,
> in precedence to the user's setting or the positioning information."

The keyword is "Well-configured". What if the AP is not well configured? Many
people don't know how to configure their access points.

(In reply to comment #9)
> (In reply to comment #6)
> > Note that _scanning_ for channel 12 through 14 isn't harmful.
> 
> That's not true, we are doing active scanning which means that we send probe
> requests on each channel.

Fair enough.

> > Well-configured access points emit regulatory domain information in their
> > beacon frames; country code, min/max channel, max transmit power. See 802.11d:
> > http://en.wikipedia.org/wiki/IEEE_802.11d-2001
> > That's what you should be using, if available, to learn the regulatory domain,
> > in precedence to the user's setting or the positioning information."
> 
> The keyword is "Well-configured". What if the AP is not well configured? Many
> people don't know how to configure their access points.

People don't configure the regulatory domain or country code of their access
points. AP vendors do, which is why they have different firmware for different
regions sometimes.

Disclaimer: I'm a software architect of a gateway stack that contains an AP
with millions of units deployed.

Even if you don't derive your domain from the beacon frames (it was just a
suggestion), this bug is unacceptable. I'm in Europe, and I cannot use channel
13 on my N900. That is just plain wrong, period.

There are a lot of mobile devices without SIM cards or GPS receivers (e.g.
portable media players) which, when bought in Europe, support WLAN channels 12
and 13. I can take those devices to the US easily. How do the manufacturers of
such devices comply to FCC regulations?

This is quite disappointing, I was hoping to have some dialog, or at least a
pointer to some document that mandates tying the domain to the cellular
registration (personally I doubt such exists, but thankfully it's not my job to
keep track of relevant regulations around the globe).

I'm not even sure what this policy is trying to accomplish besides annoying
non-US users. It's quite possible to set the domain from userland outside
wlancond (pretty much the same way one would do it on a softMAC laptop), we
just have to jump through a few hoops to do it and keep fighting wlancond
whenever it gets the wrond idea.

This bug needs to be re-activated and fixed. The reason given for its existence
seem reasonable as legal protection for Nokia by defaulting to  the minimum,
but it is ultimately the user who is legally responsible and who must have the
final control.

To not have a user method to override the automatic regulatory domain setting
arbitrarily cripples a *purchased* facility. It also does not allow for future
changes in such.

A case illustrates this:
A wifi signal is permanently, legally, fixed on wifi channel 13 to avoid
interference. A Nokia N900 mobile phone worked reliably using this channel. If
the SIM card is removed this channel cannot be seen. The phone is used for an
important VoIP telephone service but is now unusable simply because another
completely independent service is disabled. This is intolerable, and possibly
illegal here.

My suggestion for a fix is that Nokia produce and release a small app., GUI or
CLI, that changes the default regulatory domain to the user's choice. A
suppressible notification when outside this region could also be incorporated.

(In reply to comment #13)
> My suggestion for a fix is that Nokia produce and release a small app., GUI or
> CLI, that changes the default regulatory domain to the user's choice.

FYI if you're happy with a CLI solution, "iw set reg <country>" worked mostly
fine when I was using it with PR1.1 (I just rebuilt the debian package).  The
only issue IIRC was wlancond having a different idea of the domain and
resetting it from time to time between associations.

(In reply to comment #4)
> I think I am also seeing this effect. 
> 
> I'm using the N900 as an internet tablet, indoor only, without a SIM card, so
> location data will never be available. Unless I'm missing something, there is
> currently nothing I can do to make it realize it's in the EU? (this seriously
> affects overall usability of the device in my case, therefore I've voted for
> this bug, even if it's "WONTFIX" right now)
> 
> The device has regional settings, which are set to "Germany" in my case. Could
> the WLAN driver perhaps use this as a fallback when no other location
> information is available?

Hi there,

One of the main reasons I got the N900 was to be able to use VoIP in different
locations. Therefore, I don't have a SIM card in it either. The flat I recently
moved to offers a WiFi internet connection, which I payed in advance for.
However, now I have to notice that the AP here is running on channel 13, I have
no configuration access to it and I seriously did not expect that the N900
might have problems with that...

Pfeh, this whole regdomain stuff sucks.

Cheers, Linus

Today I removed the SIM card from one of my N900 devices and re-installed the
firmware. I own three (3) of them at this time. The first thing that happened
was that I did not get a connection to my AP.

Hit this bug.

Had to Re-Inserted a SIM card again (Nokia this is supposed to NOT be a mobile
phone right? Why do I then have to insert one to get "tablet" connectivity?)

Next the firmware sent out a SMS and subscribed me to "My Nokia" without having
any chance to avoid that. Is that legally allowed?

Got SMS back "Welcome ... blah blah"

Checked the other two bugs in VPN and VoIP connectivity that I have contributed
to in here, same deal. WONTFIX.

There are more bugs which file under "WONTFIX" because the platform already
abandoned. 

My Nokia my a**

Having spent over € 1000 and heavily invested into this platform, this is my
request to Nokia: fix these bugs or release the source code.

Rant over.