headers
sdr | 15 May 01:06
Picon
Favicon
Gravatar

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

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% от Вашата поръчка
в подкрепа на фондация "За Нашите Деца"!

_______________________________________________
ath5k-devel mailing list
ath5k-devel@...
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Permalink | Reply | 1 comment |
headers
Beat Meier | 14 May 18:04
Picon

Re: How can I rename wlanX to athX ?

On 05/12/2012 07:13 PM, Albert Gall wrote:
> On Sat, May 12, 2012 at 12:18:30PM -0300, Beat Meier wrote:
>> 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
>> _______________________________________________
>> ath5k-devel mailing list
>> ath5k-devel@...
>> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
> Hi, you cant use # ip link set name  wlan0 dev ath0
>

Thanks with your info I have found that
   ip link set wlan0 name ath0

To auto generate ath0 you can do something like the following in 
/etc/network/interfaces

auto wlan0
iface wlan0 inet static
         address 10.99.99.1 ### not realy used but must be here for 
config reasons
         netmask 255.255.255.0
         pre-up ip link set wlan0 name ath0

auto ath0
iface ath0 inet static
         address 10.24.5.1
         netmask 255.255.255.0
         hostapd /etc/hostapd/hostapd.ath0.conf

Thanks and greetings

Beat
Permalink | Reply | 0 comments |
headers
Beat Meier | 14 May 18:02
Picon

Country settings no honored

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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[    7.453616] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.474621] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.498654] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.525638] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.554621] cfg80211:     (5735000 KHz - 5835000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[    8.372565] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(300 mBi, 2700 mBm)
[    8.377458] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(300 mBi, 1700 mBm)
[    8.379754] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.380534] cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.388459] cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.390220] cfg80211:     (5735000 KHz - 5835000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[   14.619584] cfg80211:     (2402000 KHz - 2494000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[    7.377540] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.422579] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.439165] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.448689] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.470357] cfg80211:     (5735000 KHz - 5835000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[    7.656166] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    7.660379] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), 
(N/A, 2000 mBm)
[    7.662099] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), 
(N/A, 2000 mBm)
[    7.662824] cfg80211:     (4910000 KHz - 4930000 KHz @ 10000 KHz), 
(N/A, 2300 mBm)
[    7.667378] cfg80211:     (4910000 KHz - 4990000 KHz @ 40000 KHz), 
(N/A, 2300 mBm)
[    7.671834] cfg80211:     (4930000 KHz - 4950000 KHz @ 10000 KHz), 
(N/A, 2300 mBm)
[    7.672560] cfg80211:     (5030000 KHz - 5045000 KHz @ 10000 KHz), 
(N/A, 2300 mBm)
[    7.674333] cfg80211:     (5030000 KHz - 5090000 KHz @ 40000 KHz), 
(N/A, 2300 mBm)
[    7.678376] cfg80211:     (5050000 KHz - 5060000 KHz @ 10000 KHz), 
(N/A, 2300 mBm)
[    7.680111] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    7.680835] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    7.685375] cfg80211:     (5490000 KHz - 5710000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[    8.350192] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    8.354274] cfg80211:     (2457000 KHz - 2472000 KHz @ 15000 KHz), 
(N/A, 2000 mBm)
[    8.355997] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(N/A, 1700 mBm)
[    8.356722] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    8.361272] cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    8.362996] cfg80211:     (5650000 KHz - 5710000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[    9.312393] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    9.322153] cfg80211:     (2457000 KHz - 2472000 KHz @ 15000 KHz), 
(N/A, 2000 mBm)
[    9.326159] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(N/A, 1700 mBm)
[    9.327883] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    9.334162] cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), 
(N/A, 2000 mBm)
[    9.335904] cfg80211:     (5650000 KHz - 5710000 KHz @ 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 @ bandwidth), 
(max_antenna_gain, max_eirp)
[   17.771517] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.774193] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), 
(300 mBi, 2000 mBm)
[   17.775206] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), 
(300 mBi, 2000 mBm)
[   17.775991] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.777904] cfg80211:     (5735000 KHz - 5835000 KHz @ 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
Permalink | Reply | 1 comment |
headers
Beat Meier | 12 May 17:18
Picon

How can I rename wlanX to athX ?

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
Permalink | Reply | 1 comment |
headers
Beat Meier | 11 May 21:05
Picon

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

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
Permalink | Reply | 0 comments |
headers
Paul Bolle | 19 Apr 23:06
Picon

ath5k phy0: failed to warm reset the MAC Chip

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
Permalink | Reply | 4 comments |
headers
Qasim Javed | 6 Apr 03:40
Picon

[PATCH] ath5k: Remove extraneous statements from ath5k_hw_proc_4word_tx_status and ath5k_hw_proc_2word_status.

Signed-off-by: Qasim Javed <qasimj@...>
---
 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
@@ -441,10 +441,8 @@ 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 */
@@ -495,11 +493,9 @@ 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);
--

-- 
1.7.8.2
Permalink | Reply | 0 comments |
headers
Virág László | 1 Apr 01:38
Picon

10 MHz bandwidth with incorrect bitrate

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
Permalink | Reply | 1 comment |
headers
Qasim Javed | 24 Mar 06:14
Picon

Problem with XR9

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
Permalink | Reply | 1 comment |
headers
jpo | 15 Mar 10:11
Picon
Favicon

Combined rate and antenna selection algorithm

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
Permalink | Reply | 1 comment |
headers
Alexander Watson | 14 Mar 21:57
Picon

Ath5k Hardware Timestamping of Transmitted Packets

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@...
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Permalink | Reply | 6 comments |

Gmane