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

On Fri, Jul 10, 2009 at 4:43 AM, Frans Pop[off-list ref] wrote:

quoted

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

That'd be nice!

From that PoV it is important to ensure there
are no incompatibilities with what's in Debian stable.

And there shouldn't be.

Side note:

I'd suggest to disable OLD_REG and provide crda and iw on your shiny
new kernel. In the absence of crda you still have a really good world
regulatory domain with good world roaming capabilities. For setting
the regulatory domain you can look at what Fedora folks did with the
timezone info until the desktop catches up (geoclue and whatever).

For that reason I am very conservative when it comes to installer newer or
backported versions of packages.

Sure.

quoted

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)?

Yeah, its a good point.

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.

Perhaps an informative "group regulatory domain" printk may make
sense, you're right.

quoted

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.

Yup.

  Luis