2009-08-07 10:50:17

by Chris Clayton

[permalink] [raw]
Subject: ath5k - strange regulatory domain change

Hi,

Because of some problems with my Belkin Wireless G card (model
F5D7010) and the rt61pci driver, I've started to use a "no-name" card
that is supported by the ath5k driver.

A problem is that I have come across is that for some reason the CN
regulatory domain is being set automatically. This doesn't happen with
the Belkin (rt61) card. I have the following line in
/etc/modprobe.d/modprobe.conf to set the regulatory domain to GB:

options cfg80211 ieee80211_regdom=GB

Output from dmesg when the ath5k card is inserted is:

pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:03:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
cfg80211: Calling CRDA for country: GB
cfg80211: Regulatory domain changed to country: GB
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
ath5k 0000:03:00.0: enabling device (0000 -> 0002)
ath5k 0000:03:00.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
ath5k 0000:03:00.0: registered as 'phy0'
ath: EEPROM regdomain: 0x809c
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x52
ath: Country alpha2 being used: CN
ath: Regpair used: 0x52
phy0: Selected rate control algorithm 'minstrel'
cfg80211: Calling CRDA for country: CN
ath5k phy0: Atheros AR2417 chip found (MAC: 0xf0, PHY: 0x70)
cfg80211: Regulatory domain changed to country: CN
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
NET: Registered protocol family 17
wlan0: authenticate with AP 00:1f:33:80:09:44
wlan0: authenticated
wlan0: associate with AP 00:1f:33:80:09:44
wlan0: associate with AP 00:1f:33:80:09:44
wlan0: RX AssocResp from 00:1f:33:80:09:44 (capab=0x431 status=0 aid=2)
wlan0: associated

The "problem" doesn't happen with kernel 2.6.30.4:

pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:03:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
cfg80211: Calling CRDA for country: GB
ath5k 0000:03:00.0: enabling device (0000 -> 0002)
ath5k 0000:03:00.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
ath5k 0000:03:00.0: registered as 'phy0'
cfg80211: Regulatory domain changed to country: GB
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
phy0: Selected rate control algorithm 'minstrel'
ath5k phy0: Atheros AR2417 chip found (MAC: 0xf0, PHY: 0x70)
NET: Registered protocol family 17
wlan0: authenticate with AP 00:1f:33:80:09:44
wlan0: authenticated
wlan0: associate with AP 00:1f:33:80:09:44
wlan0: RX AssocResp from 00:1f:33:80:09:44 (capab=0x431 status=0 aid=2)
wlan0: associated

I am running the latest -git kernel:

[chris:~/kernel/linux-2.6]$ git describe
v2.6.31-rc5-246-g90bc1a6

.config is attached.

Of course, I could set the reg domain in /sbin/ifup when configuring
the interface, but that would be papering over the cracks.

Happy to provide additional diagnostics or test patches.

Thanks

Chris

--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson


Attachments:
.config (49.80 kB)

2009-08-07 15:35:34

by Frans Pop

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

Chris Clayton wrote:
> That's a regression in my book. Oh well! I do have the iw and crda
> applications installed, so I've taken that route of setting the
> regulatory domain to GB.

Somewhere in that thread I pointed to Luis explained that using the
cfg80211 module parameter is deprecated if you're using those
applications. So I think that is indeed the correct way to solve it.

If you did not have those applications installed, the GB setting from the
module parameter would still be honored.

Cheers,
FJP

2009-08-07 14:01:10

by John W. Linville

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

On Fri, Aug 07, 2009 at 01:56:43PM +0100, Chris Clayton wrote:
> Thanks Frans,
>
> 2009/8/7 Frans Pop <[email protected]>:
> > Chris Clayton wrote:
> >> Because of some problems with my Belkin Wireless G card ?(model
> >> F5D7010) and the rt61pci driver, I've started to use a "no-name" card
> >> that is supported by the ath5k driver.
> >>
> >> A problem is that I have come across is that for some reason the CN
> >> regulatory domain is being set automatically. This doesn't happen with
> >> the Belkin (rt61) card. I have the following line in
> >> /etc/modprobe.d/modprobe.conf to set the regulatory domain to GB:
> >>
> >> options cfg80211 ieee80211_regdom=GB
> >
> > This issue has already been discussed extensively (after I reported it).
> > Please see the following thread: http://lkml.org/lkml/2009/7/8/421. It
> > contains a lot of information from the wireless maintainers.
> >
>
> To sum this up then (as I understand things):
>
> 1. I am the system administrator (root);
> 2. I am using a valid (albeit deprecated from 2.6.31) method to tell
> the wireless infrastructure that I want the regulatory domain set to
> GB;
> 3. GB is a valid code; and
> 4. the wireless infrastructure sets the regulatory domain to CN.
> 5. in 2.6.30, the wireless infrastructure does what I (the root user)
> tell it to do.
>
> That's a regression in my book. Oh well! I do have the iw and crda
> applications installed, so I've taken that route of setting the
> regulatory domain to GB.

Are you actually getting the wrong regulatory rules enforced? Or are
you merely bothered that it is reporting "CN" instead of "GB"?

John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.

2009-08-07 13:02:13

by Chris Clayton

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

Thanks Frans,

2009/8/7 Frans Pop <[email protected]>:
> Chris Clayton wrote:
>> Because of some problems with my Belkin Wireless G card ?(model
>> F5D7010) and the rt61pci driver, I've started to use a "no-name" card
>> that is supported by the ath5k driver.
>>
>> A problem is that I have come across is that for some reason the CN
>> regulatory domain is being set automatically. This doesn't happen with
>> the Belkin (rt61) card. I have the following line in
>> /etc/modprobe.d/modprobe.conf to set the regulatory domain to GB:
>>
>> options cfg80211 ieee80211_regdom=GB
>
> This issue has already been discussed extensively (after I reported it).
> Please see the following thread: http://lkml.org/lkml/2009/7/8/421. It
> contains a lot of information from the wireless maintainers.
>

To sum this up then (as I understand things):

1. I am the system administrator (root);
2. I am using a valid (albeit deprecated from 2.6.31) method to tell
the wireless infrastructure that I want the regulatory domain set to
GB;
3. GB is a valid code; and
4. the wireless infrastructure sets the regulatory domain to CN.
5. in 2.6.30, the wireless infrastructure does what I (the root user)
tell it to do.

That's a regression in my book. Oh well! I do have the iw and crda
applications installed, so I've taken that route of setting the
regulatory domain to GB.

Interestingly, if I make no attempt to set the regulatory domain at
all, it get sets to World and CN never comes into it. It's only if I
try to set it to GB via the module parameter that it gets set to CN.
To me, that seems broken.

Thanks again,

Chris

> Cheers.
> FJP
>



--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson

2009-08-07 14:57:31

by Chris Clayton

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

Hi John,

2009/8/7 John W. Linville <[email protected]>:
> On Fri, Aug 07, 2009 at 01:56:43PM +0100, Chris Clayton wrote:
>> Thanks Frans,
>>
>> 2009/8/7 Frans Pop <[email protected]>:
>> > Chris Clayton wrote:
>> >> Because of some problems with my Belkin Wireless G card ?(model
>> >> F5D7010) and the rt61pci driver, I've started to use a "no-name" card
>> >> that is supported by the ath5k driver.
>> >>
>> >> A problem is that I have come across is that for some reason the CN
>> >> regulatory domain is being set automatically. This doesn't happen with
>> >> the Belkin (rt61) card. I have the following line in
>> >> /etc/modprobe.d/modprobe.conf to set the regulatory domain to GB:
>> >>
>> >> options cfg80211 ieee80211_regdom=GB
>> >
>> > This issue has already been discussed extensively (after I reported it).
>> > Please see the following thread: http://lkml.org/lkml/2009/7/8/421. It
>> > contains a lot of information from the wireless maintainers.
>> >
>>
>> To sum this up then (as I understand things):
>>
>> 1. I am the system administrator (root);
>> 2. I am using a valid (albeit deprecated from 2.6.31) method to tell
>> the wireless infrastructure that I want the regulatory domain set to
>> GB;
>> 3. GB is a valid code; and
>> 4. the wireless infrastructure sets the regulatory domain to CN.
>> 5. in 2.6.30, the wireless infrastructure does what I (the root user)
>> tell it to do.
>>
>> That's a regression in my book. Oh well! I do have the iw and crda
>> applications installed, so I've taken that route of setting the
>> regulatory domain to GB.
>
> Are you actually getting the wrong regulatory rules enforced? ?Or are
> you merely bothered that it is reporting "CN" instead of "GB"?
>

I'm not sure whether it's wrong or not. To these dmesg snippets from
my original post look wrong because one of the frequency ranges listed
for CN is outside those listed for GB and one of the CN max_eirp
entries is not preent in the GB list. Whether that is OK or not I
don't know and can't find (lay user) documentation to tell me.

cfg80211: Regulatory domain changed to country: GB
? ? ? ? (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
? ? ? ? (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
? ? ? ? (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
? ? ? ? (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
? ? ? ? (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)

cfg80211: Regulatory domain changed to country: CN
? ? ? ? (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
? ? ? ? (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
? ? ? ? (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)


Thanks

Chris

> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> [email protected] ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>



--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson

2009-08-07 15:31:07

by John W. Linville

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

On Fri, Aug 07, 2009 at 03:57:30PM +0100, Chris Clayton wrote:
> 2009/8/7 John W. Linville <[email protected]>:
> > On Fri, Aug 07, 2009 at 01:56:43PM +0100, Chris Clayton wrote:

> >> To sum this up then (as I understand things):
> >>
> >> 1. I am the system administrator (root);
> >> 2. I am using a valid (albeit deprecated from 2.6.31) method to tell
> >> the wireless infrastructure that I want the regulatory domain set to
> >> GB;
> >> 3. GB is a valid code; and
> >> 4. the wireless infrastructure sets the regulatory domain to CN.
> >> 5. in 2.6.30, the wireless infrastructure does what I (the root user)
> >> tell it to do.
> >>
> >> That's a regression in my book. Oh well! I do have the iw and crda
> >> applications installed, so I've taken that route of setting the
> >> regulatory domain to GB.
> >
> > Are you actually getting the wrong regulatory rules enforced? ?Or are
> > you merely bothered that it is reporting "CN" instead of "GB"?
> >
>
> I'm not sure whether it's wrong or not. To these dmesg snippets from
> my original post look wrong because one of the frequency ranges listed
> for CN is outside those listed for GB and one of the CN max_eirp
> entries is not preent in the GB list. Whether that is OK or not I
> don't know and can't find (lay user) documentation to tell me.
>
> cfg80211: Regulatory domain changed to country: GB
> ? ? ? ? (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> ? ? ? ? (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
>
> cfg80211: Regulatory domain changed to country: CN
> ? ? ? ? (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> ? ? ? ? (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)

It looks like a mismatch to me. Luis, can you sort this out?

John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.

2009-08-07 11:24:45

by Frans Pop

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

Chris Clayton wrote:
> Because of some problems with my Belkin Wireless G card (model
> F5D7010) and the rt61pci driver, I've started to use a "no-name" card
> that is supported by the ath5k driver.
>
> A problem is that I have come across is that for some reason the CN
> regulatory domain is being set automatically. This doesn't happen with
> the Belkin (rt61) card. I have the following line in
> /etc/modprobe.d/modprobe.conf to set the regulatory domain to GB:
>
> options cfg80211 ieee80211_regdom=GB

This issue has already been discussed extensively (after I reported it).
Please see the following thread: http://lkml.org/lkml/2009/7/8/421. It
contains a lot of information from the wireless maintainers.

Cheers.
FJP

2009-08-07 18:16:07

by John W. Linville

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

On Fri, Aug 07, 2009 at 10:51:17AM -0700, Luis R. Rodriguez wrote:
> On Fri, Aug 7, 2009 at 10:39 AM, Frans Pop<[email protected]> wrote:

> > Probably the simplest option would be to just display some identification
> > of the domain group itself and point users to documentation which
> > explains what countries fall under what groups. That would at least avoid
> > the confusion caused by randomly picking a matching country.
> > Variation could be to display the country if the group only contains one
> > country, but that could also be considered an inconsistent user
> > interface.
>
> Or maybe see if the currently set regulatory domain matches an alpha2
> in the group, if so then just display the same alpha2. Will take a
> look.

That makes sense to me...

--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.

2009-08-07 17:51:37

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

On Fri, Aug 7, 2009 at 10:39 AM, Frans Pop<[email protected]> wrote:
> On Friday 07 August 2009, you wrote:
>> The way the EEPROM was programmed for this type of
>> regulatory domain was to give you a group number under which other
>> countries fall under. If you ended up getting a direct alpha2
>> programmed in the EEPROM instead you would still end up matching the
>> alpha2 to a group number. The group number leads you to a regulatory
>> domain that all those countries in that group number adhere to. So it
>> was a way to group up regulatory domain rules between countries. The
>> "CN" you see just so happens to be the alpha2 for the first country in
>> the same group regulatory domain group.
>>
>> What we can do is to elaborate on that on the dmesg and also maybe
>
> That would be very welcome.
>
>> pick the most common country on the group so it will tend to match the
>> country users are on.
>
> I think that would just be moving the problem from one group of users to
> another, possibly only marginally smaller, group of users.
>
> As far as I can see the largest group is ETSI1_WORLD and contains 33
> countries, followed by NULL1_WORLD (is that a real group?) with 22.
> That's probably too many to list them all.
> OTOH, all other groups contain at most 7 countries, which could possibly
> be listed.
>
> Probably the simplest option would be to just display some identification
> of the domain group itself and point users to documentation which
> explains what countries fall under what groups. That would at least avoid
> the confusion caused by randomly picking a matching country.
> Variation could be to display the country if the group only contains one
> country, but that could also be considered an inconsistent user
> interface.

Or maybe see if the currently set regulatory domain matches an alpha2
in the group, if so then just display the same alpha2. Will take a
look.

Luis

2009-08-07 17:13:25

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

On Fri, Aug 7, 2009 at 8:16 AM, John W. Linville<[email protected]> wrote:
> On Fri, Aug 07, 2009 at 03:57:30PM +0100, Chris Clayton wrote:
>> 2009/8/7 John W. Linville <[email protected]>:
>> > On Fri, Aug 07, 2009 at 01:56:43PM +0100, Chris Clayton wrote:
>
>> >> To sum this up then (as I understand things):
>> >>
>> >> 1. I am the system administrator (root);
>> >> 2. I am using a valid (albeit deprecated from 2.6.31) method to tell
>> >> the wireless infrastructure that I want the regulatory domain set to
>> >> GB;
>> >> 3. GB is a valid code; and
>> >> 4. the wireless infrastructure sets the regulatory domain to CN.
>> >> 5. in 2.6.30, the wireless infrastructure does what I (the root user)
>> >> tell it to do.
>> >>
>> >> That's a regression in my book. Oh well! I do have the iw and crda
>> >> applications installed, so I've taken that route of setting the
>> >> regulatory domain to GB.
>> >
>> > Are you actually getting the wrong regulatory rules enforced?  Or are
>> > you merely bothered that it is reporting "CN" instead of "GB"?
>> >
>>
>> I'm not sure whether it's wrong or not. To these dmesg snippets from
>> my original post look wrong because one of the frequency ranges listed
>> for CN is outside those listed for GB and one of the CN max_eirp
>> entries is not preent in the GB list. Whether that is OK or not I
>> don't know and can't find (lay user) documentation to tell me.
>>
>> cfg80211: Regulatory domain changed to country: GB
>>         (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>>         (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>>         (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>>         (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>>         (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
>>
>> cfg80211: Regulatory domain changed to country: CN
>>         (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>>         (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>>         (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
>
> It looks like a mismatch to me.  Luis, can you sort this out?

There is no regression at all, ath5k *got* regulatory domain as of
2.6.31, before that the EEPROM was never read for regulatory domain
treatment. So what you see happening on 2.6.31 is interpretation of
the EEPROM as the vendor designed it and using the regulatory
infrastructure to help compliance. The "CN" is the first alpha2 that
the atheros card's programmed EEPROM regulatory domain code matches
to, so all there is here is a lack of clarity to the user of what was
done and that can be fixed.

Let me elaborate: Atheros EEPROM can be programmed by 3 types of
regulatory domains, I've documented this on the wiki for the shared
ath.ko module [1]. When you get a "regpair" there is no direct 1-1
country mapping. The way the EEPROM was programmed for this type of
regulatory domain was to give you a group number under which other
countries fall under. If you ended up getting a direct alpha2
programmed in the EEPROM instead you would still end up matching the
alpha2 to a group number. The group number leads you to a regulatory
domain that all those countries in that group number adhere to. So it
was a way to group up regulatory domain rules between countries. The
"CN" you see just so happens to be the alpha2 for the first country in
the same group regulatory domain group.

What we can do is to elaborate on that on the dmesg and also maybe
pick the most common country on the group so it will tend to match the
country users are on.

I am seeing if we can deprecate the group stuff on Atheros EEPROM but
that will take some time.

[1] http://wireless.kernel.org/en/users/Drivers/ath

Luis

2009-08-07 17:39:50

by Frans Pop

[permalink] [raw]
Subject: Re: ath5k - strange regulatory domain change

On Friday 07 August 2009, you wrote:
> The way the EEPROM was programmed for this type of
> regulatory domain was to give you a group number under which other
> countries fall under. If you ended up getting a direct alpha2
> programmed in the EEPROM instead you would still end up matching the
> alpha2 to a group number. The group number leads you to a regulatory
> domain that all those countries in that group number adhere to. So it
> was a way to group up regulatory domain rules between countries. The
> "CN" you see just so happens to be the alpha2 for the first country in
> the same group regulatory domain group.
>
> What we can do is to elaborate on that on the dmesg and also maybe

That would be very welcome.

> pick the most common country on the group so it will tend to match the
> country users are on.

I think that would just be moving the problem from one group of users to
another, possibly only marginally smaller, group of users.

As far as I can see the largest group is ETSI1_WORLD and contains 33
countries, followed by NULL1_WORLD (is that a real group?) with 22.
That's probably too many to list them all.
OTOH, all other groups contain at most 7 countries, which could possibly
be listed.

Probably the simplest option would be to just display some identification
of the domain group itself and point users to documentation which
explains what countries fall under what groups. That would at least avoid
the confusion caused by randomly picking a matching country.
Variation could be to display the country if the group only contains one
country, but that could also be considered an inconsistent user
interface.

Cheers,
FJP