Hi everybody,
[Please CC me in replies, I am currently not subscribed to this list.]
For quite a few weeks, I have now been trying to get an AR9280 mini-PCI card
to run as an access point, both in 802.11g and 802.11n mode.
In 802.11g mode, it seems to work for some time with multiple clients, but
then generally drops most packets (estimated >90%) after a period of a few
hours of usage. Restarting the device makes it work again.
In 802.11n mode, one client (Asus eeePC 1000 with Atheros 802.11agn chipset)
initially gets a fairly stable connection (with massive packet loss after some
period of usage), while another client (Dell Latitude XT with Broadcom
802.11ag chipset) only manages to connect with an absymal transfer rate (<2
MBit/s).
This behaviour seems to be mostly independent from WPA and encryption settings
(with the unencrypted connection being sometimes slower than the WPA2/AES
secured one), and does not change much with driver versions. My default driver
is the one included in the upstream 2.6.30.5/.7 kernel, but I have also tried
compat-wireless-2.6 in multiple versions, including 2009-09-25.
The hardware is detected as:
[ 25.714849] cfg80211: Calling CRDA for country: US
[ 27.233246] geode-aes: GEODE AES engine enabled.
[ 27.510611] AMD Geode RNG detected
[ 29.955007] phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 29.957464] cfg80211: Calling CRDA for country: US
[ 29.965266] Registered led device: ath9k-phy0::radio
[ 29.965407] Registered led device: ath9k-phy0::assoc
[ 29.965540] Registered led device: ath9k-phy0::tx
[ 29.965693] Registered led device: ath9k-phy0::rx
[ 29.965744] phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:
mem=0xd0b60000, irq=9
and sits in a mini-PCI slow on an Alix2d13 boards.
hostapd is version v0.6.9 from Debian testing and configured with these
relevant options:
interface=wlan0
country_code=AT
hw_mode=g
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-40]
channel=6
wpa=3
wpa_passphrase=<long string>
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
driver=nl80211
wme_enabled=1
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
The WME settings were taken from the OpenWRT forum and indeed improved
stability and throughput, although I can not currently quantify the
improvement.
Unfortunately, I seem to have more questions than answers:
1. Could this be an instance of the issue with massive packet loss that has
been documented previously with ath9k? Is this a known problem with AR9280?
Are there any patches floating around that are not yet in compat-wireless and
that I could try?
2. Is there anything to be done about the Broadcom client, and why is it much
more unstable than the Atheros one?
3. Why does the ath9k driver in AP mode fail to work after a few hours and
needs a restart?
4. How do I tell CRDA to load frequency definitions for my location (AT)
instead of the default (US)? I might be blind, stupid, or both, but using the
slightly conflicting documentation available on various Wikis, I was unable to
change this. I have read that some chipsets are hard-wired for one location
and can't be changed, but couldn't find out if mine is (it was bought in
Europe, so shouldn't be locked to US in any case). An RTFM (with an up-to-date
pointer, preferrably for Debian/Ubuntu) in this matter would be highly
appreciated.
5. After having set the correct location, is hw_mode=a and channel=40 actually
supposed to work? I have not, so far, managed to get this device into 802.11an
mode (which might be down to locked frequencies).
Any hints, pointers, or - even better - patches are very welcome ;-)
best regards,
Rene
Am Montag, 28. September 2009 09:56:23 schrieb Holger Schurig:
> Oh, and what I'm not yet getting: how can a wrong country setting
> lead to so much packet-loss?
I don't think these two are connected - the erroneous country setting is
probably just the reason why I can't try the 5GHz band and thus can't verify
if the packet loss occurs there as well.
Thanks for your explanations - I will try to get CRDA and regdb running and
will try again with the 5GHz band.
One other thing comes to mind: this 802.11n card has two antenna connectors,
and both are actually connected to pigtails (which are probably not mounted in
correct distance according to wavelenght, but that shouldn't cause packet
loss). However, it might be possible that one of the antennas has a poor
connection, is misaligned with the clients, or whatever. What I couldn't find
in ath9k is an option for user-controlled antenna diversity (comparable to
madwifi). How can I selectively disable antenna usage and/or set them for RX or
TX mode only?
best regards,
Rene
On Fri, Sep 25, 2009 at 2:54 PM, Rene Mayrhofer
<[email protected]> wrote:
I'll take a stab at this one, someone else can try the other ath9k-related
questions.
> 4. How do I tell CRDA to load frequency definitions for my location (AT)
> instead of the default (US)? I might be blind, stupid, or both, but using the
> slightly conflicting documentation available on various Wikis, I was unable to
> change this. I have read that some chipsets are hard-wired for one location
> and can't be changed, but couldn't find out if mine is (it was bought in
> Europe, so shouldn't be locked to US in any case). An RTFM (with an up-to-date
> pointer, preferrably for Debian/Ubuntu) in this matter would be highly
> appreciated.
"iw reg set XX", but read this first:
http://wireless.kernel.org/en/users/Drivers/ath
http://wireless.kernel.org/en/developers/Regulatory
In short, it depends on what's in your EEPROM.
--
Bob Copeland %% http://www.bobcopeland.com
> [ 1698.498801] ath: EEPROM regdomain: 0x0
>
> Does this indicate that the EEPROM is locked to country code
> 0x0 (whatever that is, probably US)? "iw reg" doesn't seem to
> change anything:
Yep, that's the case.
However, "iw XXX reg set XX" should *STILL* change some things,
so I guess that crda/regdb isn't still correctly installed. And
you should still see something in your "dmesg" output. Hey,
even "COUNTRY=AT crda" should change/produce something, e.g.
check "dmesg" and "iw list".
However, I've now switched my kernel to no longer include
> [ 1686.542910] cfg80211: Using static regulatory domain info
You probably should either use CRDA ("the new way") or some
static reg info in your kernel. I personally opted for CRDA, as
this gives me more correct channel settings.
Regarding the wrong info in your EEPROM: check the README file
from ath_info (svn co
http://madwifi-project.org/svn/ath_info/trunk).
I currently have the feeling, that about 50% of all WLAN cards
bought in Germany have a "wrong" EEPROM country. Maybe importers
simply don't care about this.
Oh, and what I'm not yet getting: how can a wrong country setting
lead to so much packet-loss?
Am Freitag, 25. September 2009 22:52:58 schrieb Bob Copeland:
> > 4. How do I tell CRDA to load frequency definitions for my location (AT)
> > instead of the default (US)? I might be blind, stupid, or both, but using
> > the slightly conflicting documentation available on various Wikis, I was
> > unable to change this. I have read that some chipsets are hard-wired for
> > one location and can't be changed, but couldn't find out if mine is (it
> > was bought in Europe, so shouldn't be locked to US in any case). An RTFM
> > (with an up-to-date pointer, preferrably for Debian/Ubuntu) in this
> > matter would be highly appreciated.
>
> "iw reg set XX", but read this first:
>
> http://wireless.kernel.org/en/users/Drivers/ath
> http://wireless.kernel.org/en/developers/Regulatory
>
> In short, it depends on what's in your EEPROM.
Thanks for the pointers. Using compat-wireless-2.6 as of today, I get
[ 1686.542910] cfg80211: Using static regulatory domain info
[ 1686.542931] cfg80211: Regulatory domain: US
[ 1686.542947] (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
[ 1686.542976] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 1686.543004] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 1686.543031] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 1686.543058] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 1686.543085] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 1686.543113] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 1686.543158] cfg80211: Calling CRDA for country: US
[ 1698.498801] ath: EEPROM regdomain: 0x0
[ 1698.498820] ath: EEPROM indicates default country code should be used
[ 1698.498838] ath: doing EEPROM country->regdmn map search
[ 1698.498862] ath: country maps to regdmn code: 0x3a
[ 1698.498880] ath: Country alpha2 being used: US
[ 1698.498896] ath: Regpair used: 0x3a
[ 1698.513630] phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 1698.533093] cfg80211: Calling CRDA for country: US
[ 1698.555221] Registered led device: ath9k-phy0::radio
[ 1698.555359] Registered led device: ath9k-phy0::assoc
[ 1698.555490] Registered led device: ath9k-phy0::tx
[ 1698.555624] Registered led device: ath9k-phy0::rx
[ 1698.555680] phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:
mem=0xd2780000, irq=9
Does this indicate that the EEPROM is locked to country code 0x0 (whatever
that is, probably US)? "iw reg" doesn't seem to change anything:
[root@gibraltar-500 tmp]# iw reg get
country US:
(2402 - 2472 @ 40), (6, 27)
(5170 - 5190 @ 40), (6, 23)
(5190 - 5210 @ 40), (6, 23)
(5210 - 5230 @ 40), (6, 23)
(5230 - 5330 @ 40), (6, 23)
(5735 - 5835 @ 40), (6, 30)
[root@gibraltar-500 tmp]# iw reg set 0x68
not a valid ISO/IEC 3166-1 alpha2
Special non-alpha2 usable entries:
00 World Regulatory domain
[root@gibraltar-500 tmp]# iw reg set 00
command failed: Invalid argument (-22)
[root@gibraltar-500 tmp]# iw reg set AT
[root@gibraltar-500 tmp]# iw reg get
country US:
(2402 - 2472 @ 40), (6, 27)
(5170 - 5190 @ 40), (6, 23)
(5190 - 5210 @ 40), (6, 23)
(5210 - 5230 @ 40), (6, 23)
(5230 - 5330 @ 40), (6, 23)
(5735 - 5835 @ 40), (6, 30)
[root@gibraltar-500 tmp]# iw reg set EU
[root@gibraltar-500 tmp]# iw reg get
country US:
(2402 - 2472 @ 40), (6, 27)
(5170 - 5190 @ 40), (6, 23)
(5190 - 5210 @ 40), (6, 23)
(5210 - 5230 @ 40), (6, 23)
(5230 - 5330 @ 40), (6, 23)
(5735 - 5835 @ 40), (6, 30)
What I am still unsure about (having read the regulatory Wiki page before):
are CRDA+regdb required to be able to change the regulatory domain or are they
only responsible for updating the regulatory database for which a default
already exists in the kernel?
If the EEPROM states that the device belongs to a specific domain, can this be
overridden without patching the source?
best regards,
Rene
On Mon, Sep 28, 2009 at 12:56 AM, Holger Schurig
<[email protected]> wrote:
>> [ 1698.498801] ath: EEPROM regdomain: 0x0
>>
>> Does this indicate that the EEPROM is locked to country code
>> 0x0 (whatever that is, probably US)? "iw reg" doesn't seem to
>> change anything:
>
> Yep, that's the case.
>
> However, "iw XXX reg set XX" should *STILL* change some things,
For atheros cards 'iw reg set XX' will help compliance further, it
will never enable new channels.
> Regarding the wrong info in your EEPROM: check the README file
> from ath_info (svn co
> http://madwifi-project.org/svn/ath_info/trunk).
>
> I currently have the feeling, that about 50% of all WLAN cards
> bought in Germany have a "wrong" EEPROM country. Maybe importers
> simply don't care about this.
The regulatory domain on most cards actually ship with a world
regulatory domain, if they ship with a different country regulatory
domain that is up to the manufacturer not Atheros, but most likely
they are actually not incorrect. When you do have more channels than
you are supposed you can restrict this further with 'iw reg set' but
enabling new channels is not something that is that easy from a
regulatory perspective which is why this is not something that is
done. A manufacturer typically tests only the channels enabled on
their regulatory domain and programs the EEPROM with CTL information
for those settings, not for other regulatory domains. Modifying the
EEPROM is something up to manufacturers to do under current testing
scenarios and due to current legislation, this is not supported nor it
is intended to be.
If world roaming we provide world roaming enhancements to help with
the default passive scan an no beaconing on some channels. This
currently consists of lifting passive scan flags and no-beaconing
flags from channels you see APs on. This should increase the time it
takes to scan for your AP after the first time or for other APs on
that channel. It also means you can start hostapd or adhoc on these
channels.
Luis
Hi everybody,
>> [ 1698.498801] ath: EEPROM regdomain: 0x0
>>
>> Does this indicate that the EEPROM is locked to country code
>> 0x0 (whatever that is, probably US)? "iw reg" doesn't seem to
>> change anything:
>
> Yep, that's the case.
>
> However, "iw XXX reg set XX" should *STILL* change some things,
> so I guess that crda/regdb isn't still correctly installed. And
> you should still see something in your "dmesg" output. Hey,
> even "COUNTRY=AT crda" should change/produce something, e.g.
> check "dmesg" and "iw list".
After installing Ubuntu's wireless-crda package (which includes crda, the
regulatory.bin, and the udev rule), things started to work. One kernel
module update later, I was able to issue "iw reg set AT" manually and via
hostapd and it seems to do something - "iw reg get" now returns "country
98". This should now let me use channel 40 (5GHz band), which I will try
later on this week.
> Oh, and what I'm not yet getting: how can a wrong country setting
> lead to so much packet-loss?
I can now confirm that the country setting was only a side issue that
prevented me from switching to the 5GHz band, but had nothing to do with the
massive packet loss issue. With or without the correct country setting, the
packet loss happened.
However, a (very) recent update seems to have solved this problem. While (if
I remember correctly) compat-wireless-2009-09-25 still caused the packet
loss, compat-wireless-2009-10-09 seems to be stable. With kernel 2.6.30.9
and compat-wireless-2009-10-09, scripts/driver-select set to "ath" and
loading the updated modules, I have now had a stable (nearly
packet-loss-free) connection for nearly 2h. This is a new record ;-)
Unfortunately, the connection to a Linksys WUSB600N v2 in client mode at
about 1m distance from the miniPCI Atheros AR9280 with two antennas in
access point mode is still limited to a maximum of roughly 30MBit/s of
actual transfer rate as measured with iperf (the Windows client with Linksys
rt2870 drivers reports a connection speed of 270 to 300MBit/s). hostapd is
set to
channel=6
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-40]
wpa=3
wpa_passphrase=long...
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wme_enabled=1
#
# Low priority / AC_BK = background
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
# Note: for IEEE 802.11b mode: cWmin=5 cWmax=10
#
# Normal priority / AC_BE = best effort
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
# Note: for IEEE 802.11b mode: cWmin=5 cWmax=7
#
# High priority / AC_VI = video
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
# Note: for IEEE 802.11b mode: cWmin=4 cWmax=5 txop_limit=188
#
# Highest priority / AC_VO = voice
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
# Note: for IEEE 802.11b mode: cWmin=3 cWmax=4 burst=102
Should the current ath9k code in access point be able to provide higher
throughput? The Linksys WUSB600N v2 is, according to multiple reviews,
capable of much more (which is the reason why I bought it as a test client).
On a side note, "rmmod cfg80211" causes a kernel BUG with subsequent network
subsystem instability independently of the module version (upstream
2.6.30.9, compat-wireless-2009-09-25 and 2009-10-09).
best regards,
Rene