Re: [regression] ath5k: Overrides regulatory domain set for cfg80211

Thanks again for your elaborate explanation Louis.

On Thursday 09 July 2009, Luis R. Rodriguez wrote:

EU is a valid regulatory domain only when the relic option
CONFIG_WIRELESS_OLD_REGULATORY is used. When you use OLD_REG and "EU"
you get stuck to a statically defined regulatory domain in the kernel.

quoted

 [Now I specify NL and it gives me US; how's that an improvement?]

Since you are using OLD_REG the default is "US", that was the behavior
prior to the new regulatory code so its left as is. So that is by
design following the old crap regulatory code design.

quoted

cfg80211: Calling CRDA for country: NL
 [no agent, so this does not actually change anything]

Users of OLD_REG who do not have new userspace should stick to using
the 3 static regulatory domains:

  1) US *
  2) JP
  3) EU

Right, so the EU I had originally was correct after all :-)

quoted

quoted

For further information please also read
Documentation/feature-removal-schedule.txt. Please use a valid
ISO-3166 alpha2 country code, I also advise to abandon the usage of
the ieee80211_regdom module parameter which we do eventually intend
on deprecating and if you know anyone using that please suggest the
same.

As mentioned above I do not currently have the option of abandoning
it.

Yes you do, but you don't seem to want to do anything beyond what your
distribution offers, which is different.

You're right :-)
However, I am also a Debian Developer and Debian may (just as we did for 
Etch), at some point want to offer a newer kernel than the current .26 
for stable (possibly .31). From that PoV it is important to ensure there 
are no incompatibilities with what's in Debian stable.
For that reason I am very conservative when it comes to installer newer or 
backported versions of packages.

quoted

That seems particularly bad in my case. For some weird reason this
Trust PCMCIA card seems to have AM in its EEPROM, which is Armenia...
The card was bought in the Netherlands (NL), which is also where I
live.

Yeah the short story of that is Armenia and Netherlands both have the
same regulatory rules, the first alpha2 that matched the same group
was picked up, which just so happened to be Armenia. In the future it
will be easier if cards are just programmed with the alpha2 country
code or with a world regulatory domain code, and just abandon the
grouping idea. That is something we will have to look forward to
change and promote for future device. What counts for regulatory
purposes is your device is complaint. The alternative was to keep all
the regulatory information statically in the kernel for each
regulatory group for Atheros devices.

Ah! I had no idea about that and I guess that this is the real issue here: 
a simple usability problem. If I had seen the correct countrycode (NL 
instead of AM), I probably never would have reported a regression. What 
prompted my mail was that, from a user PoV, the country being selected 
looked to be completely broken. How am I, as a simple user, supposed to 
know that Armenia uses the same domain as the Netherlands and that what 
the driver is doing is actually 100% correct (and even that my PCMCIA 
card is not as broken as I thought)?

Would it be possible to improve the info presented by the kernel? Maybe 
print an extra line with a list of countries that use the selected reg 
domain (depends I guess on what's the max. nr. of countries that share a 
domain). Or at least indicate that the country code is a somewhat random 
choice.

quoted

I can to some extend understand respecting hardware settings for APs,
but for a wireless NIC it seems a useless limitation.

You are right to a certain degree. The thing is wireless cards *can*
be used as APs on a regular desktops. Perhaps not with iwlagn, but
with ath5k and ath9k you can do AP, IBSS, Mesh, all of which actually
do start transmit with out any AP being around. For these cases you
*do* need to ensure proper regulatory compliance. And we haven't even
touched on DFS!

Well, IIUC you do know what mode the card is being used in, so in theory 
you could distinguish between them. I'm not pushing for that though.

End conclusion is that there is no regression and no backwards 
compatibility issue (which is good news), just a usability issue.

Thanks,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html