Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #508 (new defect)

Opened 13 years ago

Last modified 12 years ago

Setting TXpower Issues

Reported by: dyqith@gmail.com Assigned to:
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

Here's some information I found for txpower issues related to the following tickets:

http://madwifi.org/ticket/487 (txpower not working in adhoc mode/sta/ap) http://madwifi.org/ticket/470 (something wrong with setting txpower) http://madwifi.org/ticket/421 (txpow card measurement off) http://madwifi.org/ticket/393 http://madwifi.org/ticket/306

1) CHANNEL MUST be SET before txpower can be changed!!! (Should this be so or should it be changed ?) (works in adhoc, ap, sta modes) This means to have the device reset, i.e. have it "up" first.

2) Currently, a lot of the error messages coming from txpower changes is because the value the user is setting is too high, which produces the error. Thus, I propose to use the giwrange (i.e. iwlist ath0 txpower) to show the range of txpower it can be set at)

3) I think there's a race condition issue between the ath_update_txpow (uses vaps) and the wlanconfig ath0 destroy command, needs some locking intervention

4) Doing an iwconfig ususally shows the wrong value of txpower if nothing was set. Should we set the txpower to something more meaningful first (goes for all outputs)

5) There are a bunch of values lying around that can be used: ieee80211_ioctl_siwtxpow() uses the ic->ic_bsschan->ic_maxregpower which is NOT the cards max, its the reg domain max (which can be higher than card, thus for users, txpow doesn't change if set above card but below the reg domain max)

ieee80211_ioctl_giwtxpow() uses the vap_.iv_bss->ni_txpower which should be correct (derived from ic->ic_txpowlimit)

ath_update_txpow() <- for all intents and purposes its correct. ic->ic_txpowlimit <-- is the MAX limit we can send out (from card AND from the regdomain)

Questions and comments before I get started ? Need people to verify/agreed with the above/give alternatives, etc...

I'm going to be very busy next week, so I would like to get started soon. --dyqith

Attachments

txpower-20060404.diff (7.6 kB) - added by dyqith on 04/04/06 19:20:50.
enhances txpower control
txpower-20060406.diff (7.6 kB) - added by dyqith on 04/06/06 19:51:15.
fixed some weird stuff in the patch
txpower-20060412.diff (7.6 kB) - added by dyqith on 04/12/06 16:38:11.
txpower changes

Change History

04/03/06 21:36:16 changed by strasak@bubakov.net

sounds reasonable, go for it, i could test your patches or whatever on various HW i have here and report results.
ignus

04/03/06 22:09:08 changed by Ron Dippold

There's also:

http://madwifi.org/ticket/429

04/04/06 16:22:39 changed by dyqith

  • owner set to dyqith.

04/04/06 16:22:46 changed by dyqith

  • status changed from new to assigned.

04/04/06 19:20:50 changed by dyqith

  • attachment txpower-20060404.diff added.

enhances txpower control

04/04/06 19:32:15 changed by dyqith

  • patch_attached set to 1.

First draft of the patch is up. Some notes: I changed a few things in the code, to hopefully make it more meaningful.

1) ic->ic_txpowlimit is now the global limit (of card + regulations) aways. Previously, I think it was changing all the time because calling the ath_hal_getmaxtxpow and ath_hal_gettxpowlimit didn't return the correct results.

2) Only one VAP's txpower can be changed at a time (if using ATH_CAP_TPC, diff. VAPs can use different power, I think) NOT TESTED. I think this was the original meaning for ATH_CAP_TPC, at least.

3) No locking features yet. I didn't want to conflict with the locking features in http://madwifi.org/ticket/472 I'll update that one's locking features to support txpow changes too (soon).

4) Doing "iwlist ath0 txpower" should show the max your card/regulatory stuff will allow.

5) Previously, different vap's stations were not really clamping back to the txpower you set. I (hopefully) changed that.

6) Channel should not need to be set to change txpower now, BUT, the interface has to be "up" still.

7) Different tx descriptors use different power settings: ath_tx_startraw : ph->power or 60 ath_grppoll_start : ic->ic_txpowlimit ath_tx_start : ni->ni_txpower or 60

If anyone has an opinion on why this is so, please let me know. I'll skim through the 802.11 standards to see why.

After this, I won't make any more big changes until next week. In the mean time, please try the patch.

04/06/06 08:14:06 changed by anonymous

Patch is defect, do not compile against latest snapshot.

04/06/06 08:33:00 changed by dyqith

What's the snapshot you tried against ? and what's the compile errors ?

I'll take a look tomorrow (approx. 10hrs) from now.

04/06/06 19:51:15 changed by dyqith

  • attachment txpower-20060406.diff added.

fixed some weird stuff in the patch

04/06/06 19:51:59 changed by dyqith

Okay, New patch is up, The last patch didn't diff properly and left out a '}'.

This one should work.

04/06/06 22:45:10 changed by anonymous

Seems to give better control, but i still can't reach my card's power i have an EMP-8602 6G: 802.11a/b/g 400mW

bash-3.00# iwlist ath0 txpower ath0 8 available transmit-powers :

0 dBm (1 mW) 7 dBm (5 mW) 9 dBm (7 mW) 11 dBm (12 mW) 13 dBm (19 mW) 15 dBm (31 mW) 17 dBm (50 mW) 19 dBm (79 mW) Current Tx-Power:19 dBm (79 mW)

04/06/06 23:30:58 changed by dyqith

I'm not sure what to say, the number you're getting from "iwlist ath0 txpower" should be the max (19dBm) you can set per the regulation of the card and the regional domain. If its a 400mW card, maybe its internally fudging the numbers like here: http://madwifi.org/wiki/UserDocs/Ubiquiti

You might have to test the card through an actual power analyzer to see the signal power its generating.

04/08/06 14:26:19 changed by pstaszewski@artcom.pl

Applied And working for: (WMIA-166AG)ar5414 and (cm9)ar5213

04/08/06 17:36:04 changed by dyqith

To: pstaszewski@artcom.pl, Does this fix up http://madwifi.org/ticket/508 and http://madwifi.org/ticket/306 for you ?

04/08/06 17:50:20 changed by dyqith

To: pstaszewski@artcom.pl, I meant http://madwifi.org/ticket/470

04/10/06 23:07:11 changed by pstaszewski@artcom.pl

Yes this patch is working for me with 3 cards.

For cards that have more than 19dBm like this from 470 ticket when i do: iwlist athX tx i can get output says that i can't set more than 19dBm But when i do iwconfig athX txpower 23dBm , iwconfig show that card txpower on card is set to 23dBm , after that when i do iwlist athX tx i see max for 23dBm.

(Ticket 470) Could be closed.

04/11/06 06:54:51 changed by mrenzmann

Some questions/comments about that patch:

Why do you move set_node_txpower() to if_ath.c?

Please add a "XXX:" to the initial comment of ath_update_txpower(), so that it's clear that the locking is still needed.

And one minor formatting issue: please use 

if (blabla) {
   ...
} else {
   ...
}

rather than 

if (something)
{
   ...
}

04/11/06 07:06:33 changed by mrenzmann

And some answers to your initial questions:

1) CHANNEL MUST be SET before txpower can be changed!!! (Should this be so or should it be changed ?)

I think this is correct (not sure though). The reason is that each channel might have its own regulatory limits. For example, in Germany (and other ETSI-regulated countries) some of the 11a channels might only be used with lower TX power in outdoor setups, but with higher limits in indoor installations. Unless we know which channel is about to be used, it will be hard to make a correct assumption about whether the user-selected TX power is allowed or not.

3) I think there's a race condition issue between the ath_update_txpow (uses vaps) and the wlanconfig ath0 destroy command, needs some locking intervention

This probably is the case for a lot of other situations, too. Iirc we have a ticket about locking stuff, and that area should receive some more attention IMO.

4) Doing an iwconfig ususally shows the wrong value of txpower if nothing was set. Should we set the txpower to something more meaningful first (goes for all outputs)

Yes, I think this would be a good idea, although deciding about what "more meaningful" actually means might become a difficult thing :)

04/11/06 07:35:06 changed by dyqith 

Why do you move set_node_txpower() to if_ath.c?

I think the ath_update_txpow clamps the tx power from the user to the regulatory one. Leaving it in the ieee80211_wireless.c makes it so the nodes can all get higher values than the regulatory one. ath_update_txpow also updates all the VAPs, so I thought it might as well update all the VAP's nodes too.

Will also fix the coding format :) 

ticket about locking stuff...

Yeah, I'm working on that ticket too... I'm getting a few kernel panics from NULL pointer derefs, which shouldn't really happen. 

Yes, I think this would be a good idea, although deciding about what "more meaningful" actually means might become a difficult thing :)

This patch changes the starting txpower to be 0. I think it makes more sense than 50.

04/12/06 16:38:11 changed by dyqith

  • attachment txpower-20060412.diff added.

txpower changes

04/12/06 16:39:34 changed by dyqith

New patch up, includes changes mentioned by mrenzmann.

Signed-off-by: Daniel Wu <dyqith@gmail.com>

04/17/06 12:04:05 changed by kelmo

Hi, this patch seems to be working here, at least in reference to previous behaviour where not much worked at all in the way of txpower setting or getting. Still early days yet.

04/17/06 20:12:56 changed by dyqith

If there's no complaints in the next 24 hours, I'll merge this patch in.

04/18/06 19:45:38 changed by dyqith

  • status changed from assigned to closed.
  • resolution set to fixed.

patched in r1512.

Please reopen this ticket if patch becomes bad.

05/10/06 14:30:20 changed by madiwifi@v2r.com.br

  • status changed from closed to reopened.
  • resolution deleted.

HI,

I have two SR5 in two endpoints. One configured as Master (AP), and the other as STA.

The STA system uses an old driver without patch: ath_hal: 0.9.16.13 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, DFS) wlan: 0.8.4.2 (Atheros/multi-bss) ath_rate_sample: 1.2 ath_pci: 0.9.4.5 (Atheros/multi-bss) wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 5.9 phy 4.3 radio 3.6 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 5212: mem=0xa0000000, irq=10

the AP system uses more new (patched): ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) wlan: 0.8.4.2 (svn 1518) ath_rate_sample: 1.2 (svn 1518) ath_pci: 0.9.4.5 (svn 1518) wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 5.9 phy 4.3 radio 3.6 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 5212: mem=0xa0000000, irq=10

The Distance Between Antenna Sites is 7 Km (4.35 miles). I use a 30 dbI antennas. In http://tranzeo.com/cgi-bin/wireless.cgi I see that the RX power maybe -50dBm, with -21dBm tx.

STA do not have a patch txpower (ticket/508) AP system have a 1518 svn (with patch included in SVN, right?)

I don't set tx power in STA (old) system, that uses default; I set tx power in 18 (or 17, or 16) dBm in AP system.

The power receive in STA is 10dB lower than the power receive in AP. So, the STA tx power is +10 dB than AP.

STA: ath0 IEEE 802.11a

Mode:Managed Frequency:5.805 GHz Bit Rate:24 Mb/s Tx-Power=18 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=31/94 Signal level=-64 dBm Noise level=-95 dBm

AP: ath0 IEEE 802.11a

Mode:Master Frequency:5.805 GHz Bit Rate:0 kb/s Tx-Power=17 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=42/94 Signal level=-53 dBm Noise level=-95 dBm

Well... The information in http://madwifi.org/wiki/UserDocs/Ubiquiti: "firmware add 10dB in txpower set with iwconfig" is not true, with patch

Can I help with more tests?

05/10/06 15:46:35 changed by dyqith

How reliable are the tests ? If you can test it using a spectrum analyzer that'll be great.

Otherwise, let me see if I can provide a hack that you can try to test these links of yours. (You'll probably have to patch both ends of the system).

05/14/06 13:05:11 changed by kelmo

  • milestone changed from version 0.9.0 - move to new codebase to version 0.9.x - progressive release candidate phase.

05/19/06 22:10:06 changed by pstaszewski@artcom.pl

i agree. SR5 and madwifi :

if i do: iwlist ath0 tx

then max txpower output is 19dBm on channel 56 and 60 sysctl -a | grep reg regdomain = 0

and countrycode =0

With mikrotik software i have max tx power 27dBm on rates 6,9,12,18,24 on rate 48 i have 21dBm on rate54 i have 20dBm

05/26/06 00:09:33 changed by dyqith

  • status changed from reopened to new.

05/26/06 00:09:42 changed by dyqith

  • status changed from new to assigned.

08/23/06 07:45:04 changed by keith@ksmith.com

Engenius EMP-8602 400mw power issues

First off, the dmesg stuff . . . 

ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
wlan: 0.8.4.2 (0.9.2)
ath_rate_sample: 1.2 (0.9.2)
ath_pci: 0.9.4.5 (0.9.2)
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 10.4 phy 6.1 radio 6.3
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0x80000000, irq=12

The Problem:

From the AP note the RSSI or S/N: 

ADDR               AID CHAN RATE RSSI  DBM IDLE  TXSEQ  RXSEQ CAPS ACAPS ERP    STATE     MODE
00:02:6f:3e:1c:e5    1    2   6M   17  -78  135   2371  23408 EPSs         0       23   Normal WME ATH

But the Station hears the AP much better . . . 

[netstation]/var/log<30>wlanconfig ath0 list
ADDR               AID CHAN RATE RSSI  DBM IDLE  TXSEQ  RXSEQ CAPS ACAPS ERP    STATE     MODE
00:0b:85:13:f7:70    1    2   1M   25  -70    0   1490  20352 EPSs F       3       43   Normal WME ATH

AP :: So I can jack the power to 19 and the AP RSSI S/N Numbers go WAY up 

ADDR               AID CHAN RATE RSSI  DBM IDLE  TXSEQ  RXSEQ CAPS ACAPS ERP    STATE     MODE
00:02:6f:3e:1c:e5    1    2   6M   22  -73  120   2790  31200 EPSs         0       23   Normal WME ATH

But it won't STAY The number continually floats back down to 15 after 20 seconds or so and the RSSI number drop accordingly along with thruput && bit-rate 

[netstation]/var/log<36>iwconfig ath0 txpower 19 && iwconfig ath0
ath0      IEEE 802.11g  ESSID:"CF-North"
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:0B:85:13:F7:70
          Bit Rate:1 Mb/s   Tx-Power=19 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:FEED-DEAF-DEAD-BEEF-6026-3510-07   Security mode:restricted
          Power Management:off
          Link Quality=25/94  Signal level=-70 dBm  Noise level=-95 dBm
          Rx invalid nwid:162  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[netstation]/var/log<37>ping ksmith.com
PING ksmith.com (66.226.231.194) 56(84) bytes of data.
64 bytes from ksmith.com (66.226.231.194): icmp_seq=1 ttl=63 time=44.3 ms
64 bytes from ksmith.com (66.226.231.194): icmp_seq=2 ttl=63 time=10.1 ms
64 bytes from ksmith.com (66.226.231.194): icmp_seq=3 ttl=63 time=10.0 ms
64 bytes from ksmith.com (66.226.231.194): icmp_seq=4 ttl=63 time=10.3 ms

--- ksmith.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3034ms
rtt min/avg/max/mdev = 10.085/18.727/44.331/14.782 ms
[netstation]/var/log<38>iwconfig ath0
ath0      IEEE 802.11g  ESSID:"CF-North"
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:0B:85:13:F7:70
          Bit Rate:1 Mb/s   Tx-Power=15 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:FEED-DEAF-DEAD-BEEF-6026-3510-07   Security mode:restricted
          Power Management:off
          Link Quality=25/94  Signal level=-70 dBm  Noise level=-95 dBm
          Rx invalid nwid:175  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

This is driving me crazy. This is an outdoor PTP link with patch and sector antenna's. There is a CM-9 on the AP with a 250mw outdoor amplifier. The 400mw card should be knocking the doors down. I have another CM-9 as a client on the same AP with no stomache upset, generally sits in the 6 or 11 MB range.

What is causing the downward float? I think it may be a b/g switching issue. I think possibly the power is getting lowered during the switch and won't com back up? But that shouldn't matter,

Any ideas?

11/08/06 21:12:43 changed by marc.dilasser@lekermeur.net

Txpower problem with madwifi

Hardware : Routerboard 532, minipci wireless card Wistron CM9 (same problem when testing with CM9-GP)

Software : Openwrt, Madwifi 0.9.2 

<4>ath_hal: module license 'Proprietary' taints kernel.
<6>ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC)
<6>ath_rate_sample: 1.2 (0.9.2)
<6>wlan: mac acl policy registered
<6>ath_pci: 0.9.4.5 (0.9.2)
<4>PCI: Enabling device 0000:00:05.0 (0000 -> 0002)
<6>ath_pci: switching rfkill capability off
<4>wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
<4>wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
<4>wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
<4>wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
<4>wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
<4>wifi0: H/W encryption support: WEP AES AES_CCM TKIP
<4>wifi0: mac 5.9 phy 4.3 radio 3.6
<4>wifi0: Use hw queue 1 for WME_AC_BE traffic
<4>wifi0: Use hw queue 0 for WME_AC_BK traffic
<4>wifi0: Use hw queue 2 for WME_AC_VI traffic
<4>wifi0: Use hw queue 3 for WME_AC_VO traffic
<4>wifi0: Use hw queue 8 for CAB traffic
<4>wifi0: Use hw queue 9 for beacons
<6>wifi0: Atheros 5212: mem=0x50000000, irq=143

This AP replace an older AP and the rssi seen by the stations is 10dB less than with the older ap.

I think the 'iwconfig ath0 txpower xx' does not set the txpower at xx dB, but 10 db less (or more).

Another point : the CM9 card can provide 18dB max, but increasing from 18 to 20 increase the rssi on the stations.

Looks like a value of antenna gain in the eeprom of the CM9, that is substracted from the value we fed.

(follow-up: ↓ 31 ) 04/30/07 14:22:39 changed by rozteck@interia.pl 

(void)ath_hal_getmaxtxpow(ah, &txpowlimit);
ath_hal_settxpowlimit(ah, maxtxpowlimit);
(void)ath_hal_getmaxtxpow(ah, &maxtxpowlimit);
ic->ic_txpowlimit = maxtxpowlimit;
ath_hal_settxpowlimit(ah, txpowlimit);

As I understand this piece of code in txpowlimit variable the current tx power limit is being stored and then it is being set to 9999 and checked again to get the maximum tx power value the card will accept. Then the value from txpowlimit variable is being restored. The question is: Shouldn't be used ath_hal_gettxpowlimit instead of ath_hal_getmaxtxpow here? I'm using SR2, SR4 and SR5 cards and on each the txpower values reported and available to set are much slower than the card can handle. When I use ath_hal_gettxpowlimit here I'm able to set the greater txpower values.

(in reply to: ↑ 30 ) 07/19/07 16:36:27 changed by Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>

Replying to rozteck@interia.pl:

Shouldn't be used ath_hal_gettxpowlimit instead of ath_hal_getmaxtxpow here?

See #306, second comment by vinaysagar@gmail.com (comment 31) and the ensuing discussion.

07/24/07 20:56:29 changed by dyqith

  • status changed from assigned to new.
  • owner deleted.

12/21/07 05:54:47 changed by cisien

i'm using the EnGenius? EMP-8602+s (600mW ouput), however I am unable to set the power higher than the countrycode/regdomain allow, dispite the fact my total power ouput is much lower than the legal limitations.

the dmesg stuff: 

ath_pci: 0.9.4.5 (0.9.4)
PCI: Fixing up device 0000:00:02.0
HAL returned 45 channels.
Channel   1 (2412 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   1 (2412 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   2 (2417 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   2 (2417 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   3 (2422 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   3 (2422 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   4 (2427 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   4 (2427 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   5 (2432 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   5 (2432 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   6 (2437 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   6 (2437 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   7 (2442 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   7 (2442 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   8 (2447 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   8 (2447 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel   9 (2452 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel   9 (2452 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel  10 (2457 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel  10 (2457 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel  11 (2462 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel  11 (2462 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel  12 (2467 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel  12 (2467 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel  13 (2472 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_CCK CF_2GHZ
Channel  13 (2472 MHz) Max Tx Power 18 dBm (hw limited) [18 hw 20 reg] Flags CF_OFDM CF_2GHZ
Channel  36 (5180 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 30 reg] Flags CF_OFDM CF_5GHZ
Channel  40 (5200 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 30 reg] Flags CF_OFDM CF_5GHZ
Channel  44 (5220 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 30 reg] Flags CF_OFDM CF_5GHZ
Channel  48 (5240 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 30 reg] Flags CF_OFDM CF_5GHZ
Channel  52 (5260 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 20 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel  56 (5280 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 20 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel  60 (5300 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 20 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel  64 (5320 MHz) Max Tx Power 16 dBm (hw limited) [16 hw 20 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 100 (5500 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 104 (5520 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 108 (5540 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 112 (5560 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 116 (5580 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 120 (5600 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 124 (5620 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 128 (5640 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 132 (5660 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 136 (5680 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
Channel 140 (5700 MHz) Max Tx Power 15 dBm (hw limited) [15 hw 27 reg] Flags CF_OFDM CF_5GHZ CF_PASSIVE_SCAN_ONLY PF_DFS_REQUIRED
ath_pci: switching rfkill capability off
ath_pci: switching per-packet transmit power control off
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 10.4 phy 6.1 radio 6.3
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0x40020000, irq=6

Having the ability to bypass the artificial limitations imposed by the regdomain/countrycode settings would be ideal in my situation.