Re: regulatory domain settings overwritten

[Erich Titl <erich.titl@think.ch>]

[-- Attachment #1: Type: text/plain, Size: 4816 bytes --]

Hi Julian

on 27.11.2012 23:55, Julian Calaby wrote:
> Hi Erich,
> 
> On Tue, Nov 27, 2012 at 11:53 PM, Erich Titl <erich.titl@think.ch> wrote:
>> Hi Julian
>>
...

> 
> Sorry about that, the last time I explained this, it was for a Chinese
> resident, and I got the codes mixed up.
> 
> This "default" is part of the specification of how the hardware
> operates. If it hasn't been configured otherwise, it defaults to US
> operation. I'm sure that the Windows driver behaves in exactly the
> same way - this isn't some feature of the Linux driver, it's how the
> card is supposed to work.

I understand that well, but how is the driver supposed to know what the
default is?
In my case I got a card imported by a local OEM which gets them from
Taiwan directly.

..

> 
> Laws say otherwise. Each country has a different set of regulations
> for how they expect a WiFi card to operate. To make a card that is
> fully compliant with all these sets of regulations would require it to
> be tested against in a way which can prove that it complies with all
> those regulations. In general, as I understand it, cards are usually
> built for a particular market, and tested that they comply with that
> market's regulations, usually then ignoring any other country's
> regulations. Cheaper manufacturers may just use a reference design,
> which is probably built to comply with US regulations, and then just
> use the defaults.

Yes, but in my case the card says 'OK, use the default' and then the
default happens to be hard coded as US in he driver. In my book this is
different from a card saying, 'OH, I believe I am a US card, so please
behave US conformant'.

> 
> The card is not "open", it's using the default configuration. The
> default configuration is that it's configured for US operation.

No, it is not, the card pretends nothing, the driver does.

> 
>> So under the worst thinkable circumstances this code won't work for my
>> environment as, for example, the intersection of the world regdomain and
>> the US regdomain would AFAIK cut away channels 12 and 13, which are
>> perfectly legal at my domicile and are used by some AP's.
> 
> If you're using access points on channels 12 and 13, then yeah, using
> a card that is configured for US operation won't work for you.

Indeed and that is what I am ranting about.

> 
>> I could (and will probably have to) recompile the driver using another
>> regdomain file, but this is not really satisfactory either. IMHO the
>> regdomain should be chosen as seen fit and not imposed by hard coded
>> limits in the driver.
> 
> You could recompile the driver to use the Swiss country code as the
> default, however then you'd be using the card in a way which is
> outside of it's specification.
> 
> It is possible that your particular card cannot work predictably
> enough on channels 12 and 13 to comply with the Swiss regulations
> which is why it's been left at the default configuration. 

The driver itself cannot be made responsible for the malfunction of the
card. If the card was restricted in any way, the manufacturer can and
IMHO _must_ use the EEPROM value to restrict it's use. This was _not_
done here, as the manufacturer cannot know what the driver author thinks
is the default.

It's also
> possible that it can comply with the regulations perfectly, but has
> never been tested and had the EEPROM set to indicate that it can
> comply with them.

Yes of course, it could be that way, but my past experience in IT leads
me to believe that manufacturers shy away from market specific hardware
design. This is why the CM9 does not specify a country code, but a
'default' setting.

> 
> The simple fact of the matter is that the card is set to use the
> default configuration. The default configuration is for US operation,
> simple as that. This isn't short sighted Linux developers assuming
> that everyone is in the US, this is a design decision by the company
> that produced the card to give it a sensible default it can comply
> with.

Oh, I don't pretend the developers are short sighted, just that the
person writing the code sat possibly somewhere in the US midwest and his
perception of the world might be restricted to the county border, been
there, seen it. The driver IMHO should be written in a way that it can
meet the local regulatory law, and the default should not be US imposed
by the driver.

Nevertheless, I have patched the driver to do exactly that, if there is
no regdom specified in the EEPROM then use the one specified in the
cfg80211 options. The behaviour of the driver can be controlled right
now by a compile time flag, I might even turn that into a flag passed as
an option at load time.

cheers

Erich


[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]