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 #939 (closed defect: duplicate)

Opened 13 years ago

Last modified 12 years ago

T40p/168c:0012 (rev 01): madwifi-ng: Sets txpower to Off by default/elsewhere...

Reported by: anonymous Assigned to:
Priority: major Milestone:
Component: madwifi: other Version: trunk
Keywords: t40p txpower countrycode Cc:
Patch is attached: 0 Pending:



Using svn trunk revision 1747 under linux-2.6.19-rc1, madwifi-ng defaults txpower to `off'. When the driver accepts an attempt to reset the txpower via iwconfig (for example, when...

iwconfig ath0 txpower 17

...runs without error), the change to the transmit power is short lived: within a minute or so, the txpower reported by iwconfig once again shows up as `off'. This has a considerable affect on wireless range, which is reduced to around 12 feet, and even then, w/direct line of sight to the router: a DLINK di784. There is an immediate, noticeable difference when I subsequently reset the txpower as above: real 802.11a bandwidth goes from around 40Kbyte/s to the more normal 2Mbyte/s range. The Windows driver (via Windows or ndiswrapper) shows the latter performance level at all ranges I have tested.

I have read some information on country codes elsewhere on this site, and wonder if hal is having trouble detecting the correct value for this card:

# grep -r . /proc/sys/dev/{wifi0,ath}/* | egrep 'country|reg'

If I interpret the report on countrycodes at correctly, this looks like some sort of catch-all country code, which only allows the lowest common denominator as far as txpower threshold.

I have tried resetting the countrycode via the countrycode parameter to the ath_pci kernel module, but all values I have attempted (UNITED STATES - 840, CANADA - 124, FCC1_FCCA - 16, along with various other values randomly chosen from the linked-to-text-file) are met with the encouraging diagnostic-free modprobe run, but the following syslog diagnostic:

Oct  8 10:04:36 hostname ath_pci: (svn r1747)
Oct  8 10:04:36 hostname PCI: Enabling device 0000:02:02.0 (0340 -> 0342)
Oct  8 10:04:36 hostname ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Oct  8 10:04:36 hostname wifi%d: unable to collect channel list from hal; regdomain likely 97 country code 840
Oct  8 10:04:36 hostname ACPI: PCI interrupt for device 0000:02:02.0 disabled

...with the corresponding country code in place of 840.

As this is mentioned on your compatibility page ( ) I am unsure if this is a known issue that you are currently working on, or whether this should be actively tracked. As I am relatively new to madwifi, I may even be wrong in pursuing this countrycode avenue...may be a red herring.


System Information:

modprobe ath_pci produces the following syslog output:

ath_hal: (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
wlan: (svn r1747)
ath_rate_sample: 1.2 (svn r1747)
ath_pci: (svn r1747)
PCI: Enabling device 0000:02:02.0 (0340 -> 0342)
ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: H/W encryption support: WEP AES
wifi0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3
wifi0: Use hw queue 0 for WME_AC_BE traffic 
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 0 for WME_AC_VI traffic
wifi0: Use hw queue 0 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5211: mem=0xc0210000, irq=11

uname -a

Linux ctmobile 2.6.19-rc1 #2 PREEMPT Sat Oct 7 23:05:43 EDT 2006 i686 Intel(R) Pentium(R) M processor 1600MHz GenuineIntel GNU/Linux

madwifi-ng configuration

# grep -r . /proc/sys/dev/{wifi0,ath}/*

iwconfig output (wep key and essid removed)

# iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wifi0     no wireless extensions.

ath0      IEEE 802.11a  ESSID:"my-essid"  
          Mode:Managed  Frequency:5.3 GHz  Access Point: 00:13:46:A1:9B:9E   
          Bit Rate:18 Mb/s   Tx-Power=off   Sensitivity=0/3  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:My 128bit WEP Key [index]   Security mode:open
          Power Management:off
          Link Quality=50/94  Signal level=-41 dBm  Noise level=-91 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

lspci Information:

# lspci
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01)
# lspci -n
02:02.0 0200: 168c:0012 (rev 01)

txpower Settings

# iwlist ath0 txpower
ath0      8 available transmit-powers :
          0 dBm         (1 mW)
          5 dBm         (3 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)
          Current Tx-Power:off

Much more information on the hardware is available via the thinkWiki site mentioned on your compatibility page (see link above).

Change History

12/28/06 22:59:01 changed by Michael Helmling<>

This looks very much like my bug (#936) on a Thinkpad z60t. Could it be that IBM uses some hardware power saving mechanisms resetting the txpower?

06/23/07 02:50:34 changed by anonymous

it seems to be the same bug... I've already replied also on the other ticket, anyway I've tried disabling all the power management features from the BIOS (just to try) but nothing is changed

please ping me if there is something of useful that I can do

07/17/07 11:49:41 changed by mtaylor

  • status changed from new to closed.
  • resolution set to duplicate.

Duplicate of #936. Reopen if I am mistaken.

08/04/07 06:57:16 changed by ctt

This is the original poster. This does indeed appear to be the same issue. Sorry about the duplicate. I'll add a comment to #936 to point back here. Perhaps this information will be helpful. I still have the same hardware, although I have since switched to actively using a PCMCIA addon card which does not exhibit the same behavior. If any work is being done on trying to work around what appears to be a hardware related issue (I get this from reading #936), I would be happy to help with the debug effort.