[ath9k-devel] ath9k regulatory

[Luis R. Rodriguez <lrodriguez@atheros.com>]

On Mon, Jan 26, 2009 at 10:08:55AM -0800, Zoltan Devai wrote:
> 2009/1/26 Luis R. Rodriguez <lrodriguez at atheros.com<mailto:lrodriguez@atheros.com>>
> On Mon, Jan 26, 2009 at 05:35:13AM -0800, Zoltan Devai wrote:
> > I'm using a TP-Link TL-WN861N card. What could be the reason that channels 12 and 13 are
> > not allowed ?
> > Using compat-wireless 2009-01-25.
> <snip>
> 
> I take it the second DE regulatory request was yours?
> That's coming from loading cfg80211 with ieee80211_regdom=DE.

ieee80211_regdom module parameter should be used with the only 3
old regulatory domains built into the kernel:

EU
US
JP

This is only available if you have the old regulatory option is enabled
in the kernel:

CONFIG_WIRELESS_OLD_REGULATORY=y 

This will hopefully be removed soon (2.6.31), it provides three
regulatory domains statically into the kernel. The fact that CRDA is
called even though you selected "DE" is by chance I had forgotten
to make it only work for the 3 above. Regardless this is OK -- it is
calling CRDA for the DE regulatory domain to help you enhance your
regulatory settings.

> If your regulatory domain does not allow for it you will not be able to use that
> channel.
> I'm a bit confused now about who tells what the regulatory domain is.

Please have a read here:

http://wireless.kernel.org/en/developers/Regulatory

Let me try to summarize it for your case though. If the no one knows where we
are we will defualt to the world regulatory domain (unless OLD_REG is enabled
which defaults to the US), if a driver knows the regulatory domain it
should abide by then the wireless core is now switched to that regulatory
domain. If a user knows changes country and the card also has a programmed
regulatory domain the card will operate under the intersection of both.

> Does the (EEPROM on the) card override the user setting ?

It varies by driver, on some drivers, like rt2x00 drivers the documentation
provided indicates and recommends that the regulatory domain not be considered
from the EEPROM so alternatives are to be used. In some other cases the EEPROM
information must always be respected as is the case with Intel and Atheros'
drivers.

> Is there a way to give the users preference priority ?

The user can always specifify the regulatory domain that is the default. In
ath9k's case the EEPROM is always respected though.

> To confirm you can recompile ath9k with debugging enabled with the patch
> attached applied.
> Gives me this:
> # modprobe ath9k debug=0x00000080
> ath9k: 0.1
> PCI: enabling device 0000:00:02.0 (0140 -> 0142)
> ath9k: Country alpha2 being used: US
> Regpair detected: 0x3a
> phy0: Selected rate control algorithm 'ath9k_rate_control'
> cfg80211: Calling CRDA for country: US
> Registered led device: ath9k-phy0:radio
> Registered led device: ath9k-phy0:assoc
> Registered led device: ath9k-phy0:tx
> Registered led device: ath9k-phy0:rx
> phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xc2900000, irq=27
> cfg80211: Regulatory domain changed to country: US
>         (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>         (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
>         (5170000 KHz - 5250000 KHz @ 40000 KHz), (600 mBi, 1700 mBm)
>         (5250000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
>         (5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
>         (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> 
> If I do:
> # iw reg set DE
> cfg80211: Calling CRDA for country: DE
> command failed: No such file or directory (-2)
> cfg80211: Regulatory domain changed to country: DE
>         (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>         (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
>         (5150000 KHz - 5255000 KHz @ 40000 KHz), (N/A, 2301 mBm)
>         (5470000 KHz - 5650000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> 
> But iw list still is:
> # iw list
> Wiphy phy0
>         Band 1:
>                 HT capabilities: 0x104e
>                          * 20/40 MHz operation
>                          * SM PS disabled
>                          * 40 MHz short GI
>                          * max A-MSDU len 3839
>                          * DSSS/CCK 40 MHz
>                 HT A-MPDU factor: 0x0003 (65535 bytes)
>                 HT A-MPDU density: 0x0006 (8 usec)
>                 HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00
>                 Frequencies:
>                         * 2412 MHz [1] (20.0 dBm)
>                         * 2417 MHz [2] (20.0 dBm)
>                         * 2422 MHz [3] (20.0 dBm)
>                         * 2427 MHz [4] (20.0 dBm)
>                         * 2432 MHz [5] (20.0 dBm)
>                         * 2437 MHz [6] (20.0 dBm)
>                         * 2442 MHz [7] (20.0 dBm)
>                         * 2447 MHz [8] (20.0 dBm)
>                         * 2452 MHz [9] (20.0 dBm)
>                         * 2457 MHz [10] (20.0 dBm)
>                         * 2462 MHz [11] (20.0 dBm)
>                         * 2467 MHz [12] (disabled)
>                         * 2472 MHz [13] (disabled)
>                         * 2484 MHz [14] (disabled)

Yeap, this is by design -- your card has the "US" regulatory domain
and as such has those channels are disabled and you cannot enable them.
Reason for this is the device was not calibrated to operate on those
channels and as such proper behaviour cannot be guaranteed. For cards
where proper behaviour can be guaranteed you will be able to enable
those channels like on the b43 driver.

  Luis