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 #1996 (new defect)

Opened 13 years ago

Last modified 13 years ago

No beacon on specific frequencies

Reported by: Ken Roberts <ken@glaserelectronics.com> Assigned to:
Priority: major Milestone:
Component: madwifi: other Version: trunk
Keywords: beacon Cc:
Patch is attached: 0 Pending:

Description

Note 1: Sometimes, 5.26G would work, mostly not
Note 2: Test of frequency changed via scripting and command line

===============================

Geode(TM) Integrated Processor by AMD PCS
Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC (rev 01)
    168c:001b (rev 01)
    Subsystem: Z-Com, Inc. Unknown device 0065
    Flags: bus master, medium devsel, latency 96, IRQ 9
    Memory at e0040000 (32-bit, non-prefetchable) [size=64K]
    Capabilities: [44] Power Management version 2                                                                            

=================

Linux 2.6.21.5-smp kernel
madwifi-ng-3653 (patch-kernel)

dmesg output of module load:

ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133)
wlan: svn r3653
ath_pci: svn r3653
MadWifi: ath_attach: HAL managed transmit power control (TPC) disabled.
MadWifi: ath_attach: Interference mitigation is supported.  Currently disabled.
MadWifi: ath_attach: Switching rfkill capability off.
ath_rate_sample: 1.2 (svn r3653)
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic
wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic
wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic
wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic
wifi0: ath_announce: Use hw queue 4 for XR traffic
wifi0: ath_announce: Use hw queue 7 for UAPSD traffic
wifi0: ath_announce: Use hw queue 8 for CAB traffic
wifi0: ath_announce: Use hw queue 9 for beacons
ath_pci: wifi0: Atheros 5212: mem=0xe0040000, irq=9

===============================

Tested output:

RegDomain: 0x00
Country code: 840
Beacon interval: 300mS
TxPower setting: 5

Frequency list (iwlist ath0 freq)
Channel     : Frequency : Beacon status (another machine in monitor mode)
Channel 36  : 5.180 GHz : OK
Channel 40  : 5.200 GHz : OK
Channel 42  : 5.210 GHz : OK
Channel 44  : 5.220 GHz : OK
Channel 48  : 5.240 GHz : OK
Channel 50  : 5.250 GHz : No beacon
Channel 52  : 5.260 GHz : No beacon
Channel 56  : 5.280 GHz : No beacon
Channel 58  : 5.290 GHz : No beacon
Channel 60  : 5.300 GHz : No beacon
Channel 64  : 5.320 GHz : No beacon
Channel 149 : 5.745 GHz : OK
Channel 152 : 5.760 GHz : OK
Channel 153 : 5.765 GHz : OK
Channel 157 : 5.785 GHz : OK
Channel 160 : 5.800 GHz : OK
Channel 161 : 5.805 GHz : OK
Channel 165 : 5.825 GHz : OK

Change History

06/13/08 21:42:36 changed by Ken Roberts <ken@glaserelectronics.com>

Currently testing using countrycode=826.
5.26G will work under CC=826. Will post results of other frequencies as available.

06/13/08 21:45:50 changed by Ken Roberts <ken@glaserelectronics.com>

Output of ath_info on card:

-==Device Information==-
MAC Version:  2424  (0xa0)
MAC Revision: 5414  (0xa5)
5Ghz PHY Revision: SChip (0x63)
 -==EEPROM Information==-
EEPROM Version:     5.3
EEPROM Size:        16K
Regulatory Domain:  0x0
 -==== Capabilities ====-
|  802.11a Support: yes  |
|  802.11b Support: no   |
|  802.11g Support: no   |
|  RFKill  Support: no   |
|  32KHz   Crystal: no   |
 ========================
GPIO registers: CR 00000000 DO 00000000 DI 00000017                                                                              

06/13/08 21:57:20 changed by Ken Roberts <ken@glaserelectronics.com>

Forgot to mention that it's in AP mode, not ad-hoc mode

(follow-up: ↓ 6 ) 06/16/08 19:10:48 changed by Ken Roberts <ken@glaserelectronics.com>

Client using CC=840 will connect to AP using CC=826 on frequency 5.26. Tested unencrypted and WPA/WPA2 modes.

(in reply to: ↑ 5 ; follow-up: ↓ 7 ) 06/17/08 23:20:53 changed by Ken Roberts <ken@glaserelectronics.com>

Replying to Ken Roberts <ken@glaserelectronics.com>:

Client using CC=840 will connect to AP using CC=826 on frequency 5.26. Tested unencrypted and WPA/WPA2 modes.

When client CC=840 and AP CC=826, there appears to be a memory leak in the client (kernel panic - no memory and no processes to kill). AP appears to be rock solid.
Problem occurs when using WPA/WPA2 (hostapd/wpa_supplicant).
Have not verified unencrypted/WEP modes yet.

(in reply to: ↑ 6 ) 06/18/08 22:00:34 changed by Ken Roberts <ken@glaserelectronics.com>

Replying to Ken Roberts <ken@glaserelectronics.com>:

Replying to Ken Roberts <ken@glaserelectronics.com>:

Client using CC=840 will connect to AP using CC=826 on frequency 5.26. Tested unencrypted and WPA/WPA2 modes.

When client CC=840 and AP CC=826, there appears to be a memory leak in the client (kernel panic - no memory and no processes to kill). AP appears to be rock solid.
Problem occurs when using WPA/WPA2 (hostapd/wpa_supplicant).
Have not verified unencrypted/WEP modes yet.

UPDATE - Memory leak was in trunk-r3653. Fixed by upgrading to trunk-r3727.

06/19/08 03:58:39 changed by mentor

  • priority changed from critical to major.

I believe this would not stop a release, so dropping to major.

(follow-up: ↓ 10 ) 06/29/08 18:54:35 changed by mrenzmann

Blind guess: could this be related to radar interference avoidance - and thus be intentional?

(in reply to: ↑ 9 ) 07/03/08 11:53:36 changed by Ken Roberts <ken@glaserelectronics.com>

Replying to mrenzmann:

Blind guess: could this be related to radar interference avoidance - and thus be intentional?

Possible - but why is there no beacon, period?. I would expect a delay due to radar detection, but I believe it should still start beaconing after a grace period.

Is there a way to turn off the radar checks to see if it is related?

07/03/08 12:05:04 changed by strasak@bubakov.net

Observed this one too, even with doth 0 and nbd's patch which should make radar detection optional. Even more strange is, that if man do the following - in case doth is 0, haven't tried the same with doth 1:

first, card is set to 5,4-5,7 or other DFS-mandatory frequency set 

wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode ap
iwconfig ath0 channel 100 essid blah
iwpriv ath0 doth 0
ifconfig ath0 192.168.168.1

wlanconfig ath1 destroy
wlanconfig ath1 create wlandev wifi0 wlanmode monitor
iwconfig ath1 channel 100
ifconfig ath1 up

there are no beacons - tcpdump shows nothing

iwconfig ath0 channel 165 - or 160 or whatever channel from  non-DFS set
ifconfig ath0 down
ifconfig ath0 up
sleep 5
iwconfig ath0 channel 100
ifconfig ath0 down
ifconfig ath0 up

voila, beacons are there

just puting interface down and up, or switching to channels within DFS-mandatory branch and puting down/up have no effect 

07/15/08 20:05:07 changed by Ken Roberts <ken@glaserelectronics.com>

Updated to dfs-r3762
At least 5.32G and 5.28G are beaconing after timeout period at this point. One step closer

07/15/08 20:42:28 changed by Ken Roberts <ken@glaserelectronics.com>

OK - after some initial checks, r3762 appears to fix the beacon issue, but now getting "stuck beacon" issues