gmane.linux.drivers.ath5k.devel

Bug 16436 - ath5k (AR5001) does not work after resume and fails with "ath5k phy0: gain calibration timeout"

2012-05-14T23:06:46

  Hi All,

I'm having constant troubles with ath5k driver with sympthoms described here: 

https://bugzilla.kernel.org/show_bug.cgi?id=16436 

This is very old bug as it is reported in 2.6 bugzila but there are lot's of comments (including mine)
about this happening in 3.3 Is someone working on this and can I help with something to get
this issue resoved quickly?

Best regards
   Stoian Ivanov

-------------------------------------

Хостинг компания ICN.BG дарява 5% от Вашата поръчка
в подкрепа на фондация "За Нашите Деца"!
 http://www.icn.bg/default.icn?show=home_______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Country settings no honored

Beat Meier — 2012-05-14T16:02:04

Hello

I try to enable channel 12 and 13 for reg domain AR which are allowed 
here for ath5k and WLM54AGP23 (168c:001b) card.
I have enabled this in the regdomain binary and installed it with my 
public key in /lib/crda.
I have also tried orig regdomain...
Kernel is 3.0.0, distribution debian-6.0
Country is set with hostapd, because iw reg set does not work...

Output is the following
[    7.453516] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    7.453616] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.474621] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.498654] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.525638] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.554621] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.295351] cfg80211: Calling CRDA for country: US
[    8.297104] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
[    8.298572] ath5k 0000:00:0e.0: registered as 'phy1'
[    8.370951] cfg80211: Regulatory domain changed to country: US
[    8.371495] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    8.372565] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2700 mBm)
[    8.377458] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 1700 mBm)
[    8.379754] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.380534] cfg80211:     (5490000 KHz - 5600000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.388459] cfg80211:     (5650000 KHz - 5710000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.390220] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 3000 mBm)
[    9.147424] ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
....
[   14.488129] cfg80211: Calling CRDA for country: AR
[   14.608818] cfg80211: Regulatory domain changed to country: AR
[   14.618512] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[   14.619584] cfg80211:     (2402000 KHz - 2494000 KHz < at > 40000 KHz), 
(N/A, 3000 mBm)

But the channels and power seems to be still from country US which was 
set at startup because
iw phy0 info gives the following output:

Wiphy phy0
         Band 1:
                 Frequencies:
                         * 2412 MHz [1] (27.0 dBm)
                         * 2417 MHz [2] (27.0 dBm)
                         * 2422 MHz [3] (27.0 dBm)
                         * 2427 MHz [4] (27.0 dBm)
                         * 2432 MHz [5] (27.0 dBm)
                         * 2437 MHz [6] (27.0 dBm)
                         * 2442 MHz [7] (27.0 dBm)
                         * 2447 MHz [8] (27.0 dBm)
                         * 2452 MHz [9] (27.0 dBm)
                         * 2457 MHz [10] (27.0 dBm)
                         * 2462 MHz [11] (27.0 dBm)
                         * 2467 MHz [12] (disabled)
                         * 2472 MHz [13] (disabled)
                         * 2484 MHz [14] (disabled)
                 Bitrates (non-HT):
                         * 1.0 Mbps
                         * 2.0 Mbps (short preamble supported)
                         * 5.5 Mbps (short preamble supported)
                         * 11.0 Mbps (short preamble supported)
                         * 6.0 Mbps
                         * 9.0 Mbps
                         * 12.0 Mbps
                         * 18.0 Mbps
                         * 24.0 Mbps
                         * 36.0 Mbps
                         * 48.0 Mbps
                         * 54.0 Mbps

So what's wrong that channels are not set right? With madwifi driver it 
worked to set the channels at least of JP.
If you set country JP with the orig regdomain database it's the same 
stuff channel 12-14 are not enabled.
It's seems that the card or what ever stores the first set country which 
is per default US at startup...
How can I set at startup the country?
I created file
   /etc/modprobe.d/cfg80211.conf
with

then the output is as follows (first set to JP after that someone set it 
to US and mi hostapd config has too JP...)
Waiting for /dev to be fully populated...[    7.370263] cfg80211: World 
regulatory domain updated:
[    7.376450] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    7.377540] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.422579] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.439165] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.448689] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.470357] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.477181] cfg80211: Calling CRDA for country: JP
[    7.653563] cfg80211: Regulatory domain changed to country: JP
[    7.655098] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    7.656166] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    7.660379] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(N/A, 2000 mBm)
[    7.662099] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(N/A, 2000 mBm)
[    7.662824] cfg80211:     (4910000 KHz - 4930000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.667378] cfg80211:     (4910000 KHz - 4990000 KHz < at > 40000 KHz), 
(N/A, 2300 mBm)
[    7.671834] cfg80211:     (4930000 KHz - 4950000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.672560] cfg80211:     (5030000 KHz - 5045000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.674333] cfg80211:     (5030000 KHz - 5090000 KHz < at > 40000 KHz), 
(N/A, 2300 mBm)
[    7.678376] cfg80211:     (5050000 KHz - 5060000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.680111] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    7.680835] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    7.685375] cfg80211:     (5490000 KHz - 5710000 KHz < at > 40000 KHz), 
(N/A, 2300 mBm)
[    8.272147] cfg80211: Calling CRDA for country: US
[    8.273895] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
[    8.275362] ath5k 0000:00:0e.0: registered as 'phy1'
[    8.348205] cfg80211: Current regulatory domain intersected:
[    8.349210] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    8.350192] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    8.354274] cfg80211:     (2457000 KHz - 2472000 KHz < at > 15000 KHz), 
(N/A, 2000 mBm)
[    8.355997] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(N/A, 1700 mBm)
[    8.356722] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    8.361272] cfg80211:     (5490000 KHz - 5600000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    8.362996] cfg80211:     (5650000 KHz - 5710000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.120072] cfg80211: Calling CRDA for country: US
[    9.128247] ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
[    9.305179] cfg80211: Current regulatory domain intersected:
[    9.311299] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    9.312393] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.322153] cfg80211:     (2457000 KHz - 2472000 KHz < at > 15000 KHz), 
(N/A, 2000 mBm)
[    9.326159] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(N/A, 1700 mBm)
[    9.327883] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.334162] cfg80211:     (5490000 KHz - 5600000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.335904] cfg80211:     (5650000 KHz - 5710000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
done.
....
[   17.687881] cfg80211: Calling CRDA to update world regulatory domain
[   17.768934] cfg80211: World regulatory domain updated:
[   17.770411] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[   17.771517] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.774193] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[   17.775206] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[   17.775991] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.777904] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.788909] cfg80211: Calling CRDA for country: 97


Don't know why country 97 is tried. hostap has JP in config file too...

Thanks for any help

Beat

How can I rename wlanX to athX ?

Beat Meier — 2012-05-12T15:18:30

Hello

Is it not possible to name the interface other than wlanX?
I want to use compatibility with cacti etc. to use either madwifi or 
mac802011 and try
to use athX instead of wlanX with mac80211 drivers...

Thanks

Beat

almost no client connection to ath5k driver in long distance link setup, why?

Beat Meier — 2012-05-11T19:05:29

Hello

I'm trying to use ath5k instead of madwifi with atheros cards.
In the labor it work nice, but in long distance links it fails

Setup:
AP in master mode: voyage-0.8.0 with kernel-3.0.0, hostapd 1:0.7.3-2, 
using wpa2-psk
Clients: Ubiquity with openwrt or buffalo hw with openwrt or repeater 
with madwifi

I have one client which connects to the ap with aht5k driver but the 
other clients same hw,sw does not connect.
NS2 from ubiquity too does not connect...
Buffalo use broadcom chipset, ns2 use atheros chipset

Only difference is that the clients that does not connect have a little 
bit bader signal...
On the madwifi ap it shows me the following signals on ap:

working buffalo client: -60 distance 3.0km
not working buffalo client: -70 distance 6.9km
not working buffalo client: -64 distance 2.3km
not working ns2: -82 distance 6.8km

I have also tried to set distance with: iw phy0 set distance 25000
iw versions: iw 3.1-1, libiw30 30~pre9-5

Here the log output of clients not working

May 10 20:47:20 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DISASSOCIATE.indication(00:15:6d:8c:cf:2c, 8)
May 10 20:47:20 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:21 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: deauthenticated due to inactivity
May 10 20:47:21 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DEAUTHENTICATE.indication(00:15:6d:8c:cf:2c, 2)
May 10 20:47:21 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: authentication OK (open system)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-AUTHENTICATE.indication(00:15:6d:8c:cf:2c, OPEN_SYSTEM)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge authentication response
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: association OK (aid 3)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge association response
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
WPA: event 2 notification
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.1X: unauthorizing port
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: disassociated
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DISASSOCIATE.indication(00:15:6d:8c:cf:2c, 8)
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:34 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: deauthenticated due to inactivity
May 10 20:47:34 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DEAUTHENTICATE.indication(00:15:6d:8c:cf:2c, 2)
May 10 20:47:34 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: authentication OK (open system)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-AUTHENTICATE.indication(00:15:6d:8c:cf:2c, OPEN_SYSTEM)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge authentication response
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: association OK (aid 3)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge association response


BTW: Have the same problem with repeaters with madwifi connecting to ap 
with athk5 driver.
In the 5.8GHz frequency the repeater connects but data traffic is very 
slow (1.2Mpbs) instead of 7Mbps in one direction the other is ok with 
5.9Mbps
but an iperf running will disconnect repeater (signal of -66 on 
madwifi/distance 13km), ap use CM9 card, repeater use CM9
In the 2.4GHz the client will not connect (signal of -83 on 
madwifi/distance 21km), ap use WLM54GP23 card repeater use WLM54GP23

Anybody using aht5k in long distance setup?
What can I do more to debug the problem?

Will to in the next days tests to use ath5k as client with 
wpa_supplicant to see if it will fail too ...

Any hints, solutions???

Thanks

Beat

ath5k phy0: failed to warm reset the MAC Chip

Paul Bolle — 2012-04-19T21:06:04

0) In the logs of a laptop I use I've found error pairs like this error
pair:
    <3>[13053.997856] ath5k phy0: failed to warm reset the MAC Chip
    <3>[13053.997871] ath5k phy0: can't reset hardware (-5)

The logs show it for a v3.3 based kernel and for the v3.4-rc2 kernel. I
can't say whether or not preceding kernels also triggered it.

1) I only noticed these errors because I tend to check these logs for
errors: I cannot link these errors to drops in (the quality of) wireless
connectivity.

2) The call chain involved should be:

drivers/net/wireless/ath/ath5k/base.c:
2737 ath5k_reset(...)
     {
2765         ret = ath5k_hw_reset(...);
2766         if (ret) {
2767                 ATH5K_ERR(ah, "can't reset hardware (%d)\n", ret);
2768                 goto err;
2769         }
     }

drivers/net/wireless/ath/ath5k/base.c:
1144 ath5k_hw_reset(...)
     {
1296         ret = ath5k_hw_nic_wakeup(...);
1297         if (ret)
1298                 return ret;
     }

 667 ath5k_hw_nic_wakeup(...)
     {
 728                 ret = ath5k_hw_nic_reset(...);
 729 
 730         if (ret) {
 731                 ATH5K_ERR(ah, "failed to warm reset the MAC Chip\n");
 732                 return -EIO;
 733         }
     }

 395 ath5k_hw_nic_reset(...)
     {
 421         ret = ath5k_hw_register_timeout(...);
     }

  65 ath5k_hw_register_timeout(...)
     {
  80         return (i <= 0) ? -EAGAIN : 0;
     }

Note that the -EAGAIN returned by ath5k_hw_register_timeout() and
ath5k_hw_nic_reset() is transformed to -EIO by ath5k_hw_nic_wakeup().

3) Do these message really indicate errors? Or can they perhaps be
downgraded to (say) KERN_INFO level (ie, <6> prefix)?


Paul Bolle

[PATCH] ath5k: Remove extraneous statements fromath5k_hw_proc_4word_tx_status and ath5k_hw_proc_2word_status.

Qasim Javed — 2012-04-06T01:40:15

Signed-off-by: Qasim Javed <qasimj-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
---
 drivers/net/wireless/ath/ath5k/desc.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/desc.c b/drivers/net/wireless/ath/ath5k/desc.c
index f8bfa3a..97b92c3 100644
--- a/drivers/net/wireless/ath/ath5k/desc.c
+++ b/drivers/net/wireless/ath/ath5k/desc.c
< at >< at > -441,10 +441,8 < at >< at > ath5k_hw_proc_2word_tx_status(struct ath5k_hw *ah,
 struct ath5k_desc *desc,
 struct ath5k_tx_status *ts)
 {
-struct ath5k_hw_2w_tx_ctl *tx_ctl;
 struct ath5k_hw_tx_status *tx_status;
 
-tx_ctl = &desc->ud.ds_tx5210.tx_ctl;
 tx_status = &desc->ud.ds_tx5210.tx_stat;
 
 /* No frame has been send or error */
< at >< at > -495,11 +493,9 < at >< at > ath5k_hw_proc_4word_tx_status(struct ath5k_hw *ah,
 struct ath5k_desc *desc,
 struct ath5k_tx_status *ts)
 {
-struct ath5k_hw_4w_tx_ctl *tx_ctl;
 struct ath5k_hw_tx_status *tx_status;
 u32 txstat0, txstat1;
 
-tx_ctl = &desc->ud.ds_tx5212.tx_ctl;
 tx_status = &desc->ud.ds_tx5212.tx_stat;
 
 txstat1 = ACCESS_ONCE(tx_status->tx_status_1);

10 MHz bandwidth with incorrect bitrate

Virág László — 2012-03-31T23:38:04

Hello everyone,

I'm quite new on this list. As the subject shows I have configured the
ath5k driver to operate on 10 MHz bandwidth (check by spectrum
analyzer). With this setup the desired bitrates were halved indicated
by throughput measurements (iperf, netperf, etc.). I know that
dividing the bandwidth
by two results a /2 decreasing in maximum datarate but I thought that
the driver and/or the Atheros SoC can correct the properties
(obviously not). Of course doubling the desired rate can solve the
problem but the PLCP header will indicate the doubled rate which is
not a perfect way for me.
Has anybody experienced this kind of phenomenon?
I wonder if there is a simple way to tell the SoC and/or the driver to
work on 10 MHz bandwidth with e.g. 6Mbps and the outcome will match
the desired options.
I don't know exactly how the Atheros SoC works, what kind of
properties can be defined, for example the proper options for doubled
datarate for the 10 MHz bandwidth considering the correct PLCP
information in the signal field which indicates the correct bitrate
for 10 MHz (not the doubled).

Thank you.
Laszlo

Problem with XR9

Qasim Javed — 2012-03-24T05:14:17

Hi everyone,

I have a question regarding a problem I have been facing while using
an Ubiquiti XR9 Wifi card. This is basically a Wifi card which
operates in the 900MHz band and is based on the Atheros 5414 (supports
802.11b/g) chipset. There is an open source driver (mainly maintained
by Atheros and contributions from others) called ath5k.

For a research problem, I wanted to measure the amount of time elapsed
between when a packet enters the MAC layer queues (in this case
mac80211 transmit queue) and when it is actually transmitted over the
air. Measuring the entry into the MAC layer is easy as the stack runs
on the Host CPU and can be instrumented. For the exact time when the
frame is actually transmitted, the card provides support for reading
that information. More specifically, whenever a frame is transmitted,
a transmission status descriptor can be read. This transmission status
descriptor contains the exact timestamp (in TUs) at which the last
successful frame transmission attempt was made.

Interestingly enough, when I take the difference of two timestamps, I
get really large values on the order of 200,000 microseconds. This
only happens when there is a lot of data to send such as when using
iperf. On the other hand, if I just use ping and then look at the
value measured above, they are fine. I measured the values when there
was no contention from any other node (experiments were carried out
over a testbed where nodes are connected via coaxial cables). So,
basically I get large bloated values only when there are lot of
transmission attempts back to back.

I tried moving the point at which the first timestamp is taken as
close to the hardware as possible i.e. just before the frame is DMA'ed
to the card. I get the same large values which indicates that delays
are not being incurred due to queues on the host. Also, instead of
depending on the card for providing the second timestamp (the time at
which the frame is put on air), I tried to measure it myself within an
interrupt handler which is invoked whenever the host CPU is
interrupted by an interrupt generated as a result of receiving a frame
on the Wifi card. Also, in this case I get large values as before.
This indicates that the mechanism used to take the transmit timestamp
on the card is working fine.

I did some further research using the "mpstat" tool and found that the
number of interrupts per second (corresponding to the received frames)
generated by the card goes down if the offered load exceeds a certain
threshold. This seems to indicate that there is some problem in the
code running on the cards's own processor as the number of interrupts
going down as a result of more offered load is ungraceful behavior.

I was wondering if you could offer some insight into this or ways to
solve this problem?

Thanks and regards,
-Qasim

Combined rate and antenna selection algorithm

jpo — 2012-03-15T09:11:29

Hello all,
I'd like to present and maybe get a little bit feedback from the community for a
rather unique problem we face in a production environment. We are using EMP-8602
PLUS-S cards in 802.11a mode (5GHz/BBDR) with an external TX amplifier attached
to one of the antenna ports. The second antenna port is not amplified. Normally
we achieve good results with this setup (up to 2km range outdoors).
Unfortunately it doesn't work well if sender and receiver are close together. In
this case the amplified signal is apparently to strong for the card to handle.
However, switching to the antenna port without the amplifier gives very good
results at close range.
Now we are looking for a way to automatically select the best antenna port. It
seems to me, that this problem is closely related to the rate selection problem
faced by the 802.11 stack, so enhancing one of the rate selection algorithms to
include the antenna into the search space might be the way to go.
Has anybody ever done this? Do you think that this might be the way to go? Are
there better heuristics to find the best antenna port? Any other comments?

Thanks in advance
  Joerg

Ath5k Hardware Timestamping of Transmitted Packets

Alexander Watson — 2012-03-14T20:57:29

Hello,

I am working on a project where I need to be able to accurately timestamp
both transmitted and received packets from an Atheros NIC. I am aware that
in its normal mode of operation and that Ath5k only timestamps received
packets and beacons.

To get around this,  I have tried running two NICs (Atheros based Ubiquiti
SR2s, wlan0 and wlan1), where wlan0 transmits data frames and the second
NIC wlan1 is in monitor mode. My intent was that the second NIC in monitor
mode would receive the transmitted packets from wlan0 and time stamp them
as well as other incoming packets. Unfortunately, there appears to be some
level of filtering at the driver or possibly kernel level that prevents the
second NIC from seeing the packets that have been sent out by the first NIC.

Notes:
** I have read about some people flagging outgoing packets in Ath5k as
beacons, which are timestamped by hardware, but am not sure where to look
or implement this in the driver.
 ** I am not concerned about providing normal 802.11 operation with this
system, just being able to transmit packets and accurately timestamp the
associated transmit and receive times.

Any suggestions about how to successfully timestamp transmitted and
received packets using Ath5k would be much appreciated. Preferably, I'd
like to do this with one NIC, but if there is an easier way to do this with
two NICs that will work as well.

Thanks
-Alex
_______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

ath5k disassociates when physical carrier sensing isdisabled

srinivas prasad — 2012-02-28T02:01:26

hi,
I am using voyage linux(3.0.0-voyage kernel) for my work. All my wireless
cards are atheros cards(Atheros Communications Inc. Atheros AR5001X+
Wireless Network Adapter (rev 01)) and I am using ath5k driver. I
incorporated the following change to create the interface for enabling and
disabling carrier sensing
https://www.pentoo.ch/svn/portage/trunk/net-wireless/compat-wireless/files/super_secret_patch.diff.
Whenever i disable physical carrier sense to induce maximum overlap of
packets at the AP, the client disassociates from it and is unable to
reconnect in any successive attempt. I get the following error message at
the client

[450677.830138] wlan0: authenticate with 00:0b:6b:da:f6:f3 (try 1)
[450677.832624] wlan0: authenticated
[450677.832746] wlan0: associate with 00:0b:6b:da:f6:f3 (try 1)
[450677.841921] wlan0: RX AssocResp from 00:0b:6b:da:f6:f3 (capab=0x401
status=0 aid=1)
[450677.841990] wlan0: associated
[450677.896076] wlan0: disassociated from 00:0b:6b:da:f6:f3 (Reason: 7)
[450677.898152] wlan0: deauthenticating from 00:0b:6b:da:f6:f3 by local
choice (reason=3)

Looking forward to any suggestions anyone might have regarding this. Thanks
for the help.

Thank you
Srini
_______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

ath5k phy0: gain calibration timeout

David Fries — 2012-02-27T03:12:32

Wireless network stopped working after 22 hours with ath5k, I have the
following message repeating, suspending to ram and back was enough to
get it talking again.
ath5k phy0: gain calibration timeout (2462MHz)

I previously was running 3.2-rc5 for a month and a half straight
without any wireless issues, I just upgraded to 3.3-rc1, the message
started 22 hours after booting the newer kernel.  This ath5k is
running hostapd 1:0.7.3-4 with WPA-EAP and had no clients for the 12
hours before the calibration message started, and had no clients for
hours after until I tried to connect and found I couldn't.
While I was unable to connect, I flipped
the laptop rfkill switch and the gain calibration timeouts continued,
disabling rfkill and they still continued.  That's when I did a
suspend to memory and resume and found it recovered.  While it was
working I tried rfkill and it no longer was talking after disabling
rfkill, I thought it was resuming previously, but I don't use that
very often.

I revered the following two comments and will see if I run into any
more problems.  I can test patches.
ath5k: We always do full calibration on AR5210
dafae6af0336958e9e2eb67cc5e4e31d6d13b308
ath5k: Calibration re-work
ce169aca0d823d38465127023e3d571816e6666c

Feb 24 21:54:23 Pulsar kernel: ath5k 0000:06:02.0: registered as 'phy0'
Feb 24 21:54:23 Pulsar kernel: ath: EEPROM regdomain: 0x63
Feb 24 21:54:23 Pulsar kernel: ath: EEPROM indicates we should expect a direct regpair map
Feb 24 21:54:23 Pulsar kernel: ath: Country alpha2 being used: 00
Feb 24 21:54:23 Pulsar kernel: ath: Regpair used: 0x63
Feb 24 21:54:23 Pulsar kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Feb 24 21:54:23 Pulsar kernel: ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
Feb 24 21:54:23 Pulsar kernel: device wlan0 entered promiscuous mode
Feb 24 21:54:23 Pulsar kernel: br0: port 2(wlan0) entering forwarding state
Feb 24 21:54:23 Pulsar kernel: br0: port 2(wlan0) entering forwarding state
Feb 24 21:58:59 Pulsar kernel: ath5k 0000:06:02.0: registered as 'phy0'
Feb 24 21:58:59 Pulsar kernel: ath: EEPROM regdomain: 0x63
Feb 24 21:58:59 Pulsar kernel: ath: EEPROM indicates we should expect a direct regpair map
Feb 24 21:58:59 Pulsar kernel: ath: Country alpha2 being used: 00
Feb 24 21:58:59 Pulsar kernel: ath: Regpair used: 0x63
Feb 24 21:58:59 Pulsar kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Feb 24 21:58:59 Pulsar kernel: ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
Feb 24 21:58:59 Pulsar kernel: device wlan0 entered promiscuous mode
Feb 24 21:58:59 Pulsar kernel: br0: port 2(wlan0) entering forwarding state
Feb 24 21:58:59 Pulsar kernel: br0: port 2(wlan0) entering forwarding state
Feb 24 23:02:31 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 1
Feb 24 23:02:31 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 2
Feb 24 23:02:40 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 3
Feb 24 23:15:37 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 2
Feb 24 23:15:37 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 1
Feb 24 23:15:37 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 0
Feb 25 08:48:40 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 1
Feb 25 08:48:40 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 2
Feb 25 08:48:46 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 3
Feb 25 08:56:35 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 2
Feb 25 08:56:35 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 1
Feb 25 08:56:35 Pulsar kernel: wlan0: moving STA xx:xx:xx:xx:xx:xx to state 0
Feb 25 19:52:50 Pulsar kernel: ath5k phy0: gain calibration timeout (2462MHz)
Feb 25 19:52:51 Pulsar kernel: ath5k phy0: calibration of channel 11 failed
Feb 25 19:52:52 Pulsar kernel: ath5k phy0: gain calibration timeout (2462MHz)

iw wlan0 survey dump
Survey data from wlan0
        frequency:                      2462 MHz
        noise:                          -96 dBm
        channel active time:            79250 ms
        channel busy time:              118644 ms
        channel receive time:           48278 ms
        channel transmit time:          5285 ms

ath5k problem with multiple NICs

Geovana Navarro — 2012-02-21T16:23:41


Hi all,

I have a problem with the athk5 driver and this scheme. Description of scheme and the problem is as follows:

Specifications

Linux Kernel: Linux voyage 3.0.0-voyage

Ath5k modules:
filename:       /lib/modules/3.0.0-voyage/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko
license:        Dual BSD/GPL
description:    Support for 5xxx series of Atheros 802.11 wireless LAN cards.

Modules ath5k
ath5k, ath, mac80211, cfg80211              

NIC models: CM9-GP
Chipset: Atheros AR5213A
Standard: 805.11a/b/g
bitrate: 6Mbps

Scheme:

I use 2 ALIX boards, each of them have two NICs installed. The scheme is as follows:

ALIX_0                         ALIX1             ESSID     CHANNEL
NIC_1: 192.168.0.1        NIC_1: 192.168.0.2      ESSID1      1
NIC_2: 192.168.10.1       NIC_2: 192.168.10.2     ESSID2      11

Two links linked up using infraestructure, mesh or ad-hoc mode.

I insert traffic between NIC_1(ALIX0) and NIC_1(ALIX1) in ESSID1, and I get a 5Mbps throughput, I did the same test with the link ESSID 2 and results were similar.

The problem is when I try to send data simultaneously using both two links I only get a 5Mbps throughput, this means I only get a single link throughput even when the traffic is sent using both channels.

I did a similar testing with madwifi driver, and I am able to send data simultanously, but I need to use ath5k driver, because bonding implementation is much better for wireless networks.

Could you please help me with this?

Many thanks in advance.

Kind regards,

Geovana






Geovana Navarro 
Dios te Bendiga
Solo Cristo Jesus puede darte Amor verdadero, entregale tu corazon.       _______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

CCA mode

Alexandros Chimarios — 2012-02-16T16:19:40

Hi,

Regarding the CCA, I have noticed that ath5k currently supports only the 
ANI
patent. Is there any feature in the ath5k driver to support the 802.11 
CCA mode 1(802.11 DSSS PHY conformant signal detection)  and 2(Energy 
detection combined with an 802.11 DSSS PHY conformant signal detection) 
in wifi chipsets that have this option?

Thanx in advance,
Alexandros

IEEE 802.11-2007 support

Meisam Navaki — 2012-02-06T12:09:58

Hi all,
Does ath5k driver support IEEE 802.11-2007 standard?
Thanks in advance.

Simple question about "fast channel switch"

Saulo Queiroz — 2012-02-01T21:22:34

Hi all,


May someone tell me how much time (approximately) the ath5k 'fast' channel
switch module takes to do the switching job? Is there any test reported in
this sense? I would like to know if it is as efficient as the  "fast"
switching of juggler [1], a channel switching module (for RTL drivers) that
claims achieving ~3ms switching time.

Sorry here is not the best place to ask such question,

thanks in advance.

[1] Nicholson, A. "Juggler: Virtual Networks for Fun and Profit"

setting txpower,rssi

nik tavoularis — 2012-01-31T21:52:53

Greetings,

I 'm trying to create a mechanism which adjusts the txpower according to
rssi ,for my thesis.
I 'm thinking of implementing this inside the driver.
I have hardware that uses the ath5k driver.
Is it possible to change the txpower for this driver or should i use
madwifi ?
Can i use the rssi beacon message from ani algorithm or it is a bad
approach ?

Thank you very much


Tavoularis Nikolas
Computer Engineering and Informatics Department
Greece
_______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

ARP Forwarding Problem in AP Mode with WPA

Ian Milligan — 2012-01-23T03:15:50

Hi,

I have an AP with an Atheros AR5001X+ bridged with an ethernet adapter.
The problem is that after a certain amount of time, ARP requests coming
from anything but the AP (meaning from the ethernet interface or other
stations) aren't reaching the stations. I have verified using tcpdump
that they reach the bridge and wireless interfaces on the AP, but aren't
seen by the station. This appears only to happen when WPA is enabled,
and forwarding in the opposite direction works fine. Let me know what
further information would help debug this problem.

Ian

Tool for detailed visualisation of RADAR PHY errors

Balint Seeber — 2012-01-23T00:56:35

Hi folks,

I've finally put up some results of my experimentation with the PHY's RADAR
pulse detection system:

 

http://wiki.spench.net/wiki/RADAR

 

I hope this will be useful to those investigating DFS, pattern matching,
etc.

 

Briefly, the system comprises of:

 

1.       some extra code in the driver that stores the errors and transfers
them to userspace

2.       a networked server collects the information and servers them to
clients, as well as controlling frequency sweeping on the card, and

3.       a client app graphs/plots just about everything I could think of
(time/RSSI/width/time-between-pulses by time and frequency, histograms of
RSSI/width/time-between-pulses, and time-series plots of pulses colour-coded
by RSSI/width to infer repeating groups, etc).

 

I have a weather RADAR nearby, which shows up clearly in the plots. There
are also some other things I haven't been able to identify (in case anyone
wishes to throw in their two cents worth).

 

If anyone would like to play with it, I can put up a copy of my version of
the driver, the server (Python) and the GUI too (.NET).

 

Any feedback/comments are most welcome!

 

Balint

_______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

help in implementating a method to reduce handoverlatency in WLAN

Paul Njesse — 2012-01-19T19:10:48

Hi, I am student in IT Tralee in Ireland, just want to know how to synchronise two atheros wireless cards, in the way that one will keep the communication while the other one will scan the network for new Access point to associate, this role will be interchangeable, Please I am not a C developer but C# and java developer can you :
first let me know where the drivers are saved
secondly which folder should be modified to cater the algorithm or the thread that I will create

I am doing this as part of my thesis

Thanks

Paul
Co. Kerry - European Entrepreneurial Region of the Year http://www.ittralee.ie/en/InformationAbout/NewsandEvents/News/FullText,29880,en.html --->
This e-mail is subject to the following disclaimer(s)
 - Ta an r-phost seo fe reir an tseanta/na seanta seo leanas ata le fail ag - 
available at http://www.ittralee.ie/EmailDisclaimer.html 
Please consider the environment before printing this e-mail
 - Smaoinigh ar an dtimpeallacht sula bpriontaileann tu an r-phost seo -

Disable MAC layer ack

David Murray — 2012-01-19T08:35:52

Hi,

I am interested in disabling the MAC layer ack. I have read 
http://www.mail-archive.com/ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org/msg04587.html

Is there any chance of a hook being put into ath5k so that it could be 
enabled or disabled with an iwpriv or something similar. It seems like 
it is part of the 802.11e framework 
http://en.wikipedia.org/wiki/IEEE_802.11e-2005#NoAck

It would also be useful for anyone doing long distance networking or 
experimenting with TDMA based MAC layers.

Thanks for your time,
Dave