Re: [ath9k-devel] Interpreting link quality of cards driven by ath9k to estimate usable bandwidth?
Hi, thanks a lot for your helpful mail. I made several tests and good progress, thanks to you :) * Holger Schurig [mailto:holgerschu...@gmail.com] wrote: Hi, I wouldn't use iwconfig and link quality. iwconfig is outdated and virtually unmaintained since years. Ohh, good to know... it is mentioned by a lot of howtos, so I completely missed that it could be deprecated. So this concept has been dropped, as far as I know. ok, I see. If you get a fail, then maybe your distribution-provided wpa_supplicant is outdated and/or using the old WEXT interface as well. Find a way to use wpa_supplicant with -Dnl80211, and retry. Indeed the WEXT interface was used (I guess it is default). I tested with -Dnl80211 and found it working, exactly as you told, thank you! However, if we start wpa_supplicant this way, we drop support for all chips not (yet) supported by nl80211 (which probably is the reason why it is not default), right? Are this only a few outdated devices? Documentation (of iw) just briefly tells It supports all new drivers that have been added to the kernel recently. but does not tell a date. Something that should work, even if you can't get wpa_supplicant with -dnl80211 to work, is to use iw wlan0 link: Yes, this works for me both with and without -Dnl80211, very well! I tested a bit monitoring this ten times per second while changing anntennas and so on and it looks very good and promising. It also shows the BSSID, so provides all information we need. So I think forgetting about wpa_cli but instead using iw actually is the right way to go here? Thanks so much for pointing me to the right direction, and have a nice weekend, Steffen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Interpreting link quality of cards driven by ath9k to estimate usable bandwidth?
Hi, man iwconfig tells, Link quality... depends totally on the driver and hardware. I would like to know how to interpret the value for WPEA-127N driven by ath9k - ideally to have a base value for estimation of useable bandwidth (i.e. how much data could be sent and received per time). Is this feasible? Is parsing the output of iwconfig in intervals a good approach? Which polling interval would be suited? What would be a better way / correct way? I tried wpa_cli -p $path signal_poll, but it returns only FAIL (however, commands work). Do I something wrong? It would be good to estimate the order of magnitude (if there are 2 or 20 MBits) and having a value to compare several links. Surely this is a very complex topic (Google found heaps of papers about), but I'm looking for a starting point for a rough guess, but hopefully still a bit reasonable. Any pointers appreciated! Regards Steffen Example iwconfig: Bit Rate=48 Mb/s Tx-Power=17 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=40/70 Signal level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:17 Missed beacon:0 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi all, thanks for all your replies. Let me tell my findings just in case it helps. * adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] wrote: The general consensus at work is - BIOSes are buggy and don't necessarily reset the PCI bus correctly. So either you can do your own PCI bus reset post-boot (and re-enumerate all the PCI devices, including initialising their BARs) or smack your vendor to fix their BIOSes. I can't really make any further suggestions besides that. I talked with an expert of my unit about resetting PCI express cards. The units have a special controller (I^2C) able to power off and power on the card slots. I was told that this does not handle the PCI reset line correctly (leaves it open), but makes a hard cut to the 3 volts (I hope I repeat it correctly). For my WPEA-121N cards, such a power cycle in my tests so far worked around the issue. I tested ~30 main unit power cycles where I had 4 occurrences of the issue. No extra steps were needed (Linux 3.2 automatically detected the correctly after each slot power on, hundreds of slot power cycles tested). So fine for me. root@nomad:~# lspci|grep -i ath 01:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01) root@nomad:~# i2cset -y 14 0x20 0x0 root@nomad:~# sleep 1 root@nomad:~# i2cset -y 14 0x20 0x1f root@nomad:~# lspci|grep -i ath 01:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01) I also tried : root@nomad:~# echo 0 /sys/bus/pci/slots/1/power root@nomad:~# echo 1 /sys/bus/pci/slots/1/power this makes the device disappearing temporarily but does not have the desired effect of fixing the vendor ID. Happy Easter! Regards Steffen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi,
some time ago there was a thread Sparklan WPEA-121N AR9382 168c:abcd about
the issue that the mentioned device was erroneously reported as device ID
0xabcd. There were EEPROM issues assumed and BIOS issues reported that could
cause this effect (by resetting the PCI bus at system power on) and a proposed
workaround to add the wrong ID to the driver to make it load - it had been
reported working.
I'm facing such a situation with embedded devices (I assume BIOS updates
probably are at least very difficult) and a WPEA-127N and would like to know
whether there were new findings and share mine in case they'd be of some
interest.
Are there any news on that?
Is the proposed workaround adding 0xabcd to the driver still best way of
handling this?
On my board it happens /from time to time/ that the device reports 0xabcd - but
not always.
I made 20 tests were I saw 4 such failures. All those failures appeared after
cold boot, but none after warm boot. After cold boot sometimes one of two
installed devices appeared with wrong device ID but other correctly, and at
other times both were working. Of course the number of tests is insufficient to
draw conclusions, I write it just in case it rings a bell.
It is some Intel atom board running Linux (for example, Debian 7). Can I
provide information that could help (and if so, how do I get those)?
Best regards,
Steffen
Some test results:
root@nomad:~# lspci|grep -i ath
01:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
07:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
root@nomad:~# grep ''
/sys/devices/pci:00/:00:1c.*/:0{1,7}:00.0/{vendor,device}
/sys/devices/pci:00/:00:1c.0/:01:00.0/vendor:0x168c
/sys/devices/pci:00/:00:1c.0/:01:00.0/device:0xabcd
/sys/devices/pci:00/:00:1c.2/:07:00.0/vendor:0x168c
/sys/devices/pci:00/:00:1c.2/:07:00.0/device:0xabcd
root@nomad:~# reboot
[ssh...]
root@nomad:~# lspci|grep -i ath
01:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN
adaptor (rev 01)
07:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN
adaptor (rev 01)
root@nomad:~# grep ''
/sys/devices/pci:00/:00:1c.*/:0{1,7}:00.0/{vendor,device}
/sys/devices/pci:00/:00:1c.0/:01:00.0/vendor:0x168c
/sys/devices/pci:00/:00:1c.0/:01:00.0/device:0x0030
/sys/devices/pci:00/:00:1c.2/:07:00.0/vendor:0x168c
/sys/devices/pci:00/:00:1c.2/:07:00.0/device:0x0030
root@nomad:/sys/devices/pci:00/:00:1c.0/:01:00.0# grep '' *
broken_parity_status:0
class:0x02
Binary file config matches
consistent_dma_mask_bits:32
device:0xabcd
dma_mask_bits:32
enable:0
grep: firmware_node: Is a directory
irq:10
local_cpulist:0-31
local_cpus:
modalias:pci:v168CdABCDsvsdbc02sc00i00
grep: power: Is a directory
grep: remove: Permission denied
grep: rescan: Permission denied
grep: reset: Permission denied
resource:0xfdfe 0xfdff 0x00140204
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
resource:0xfdfd 0xfdfd 0x0004e200
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
resource:0x 0x 0x
grep: resource0: Input/output error
grep: rom: Invalid argument
grep: subsystem: Is a directory
subsystem_device:0x
subsystem_vendor:0x
uevent:PCI_CLASS=2
uevent:PCI_ID=168C:ABCD
uevent:PCI_SUBSYS_ID=:
uevent:PCI_SLOT_NAME=:01:00.0
uevent:MODALIAS=pci:v168CdABCDsvsdbc02sc00i00
vendor:0x168c
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
