First, let me know which logs and info you need and I'll attach them to the next message. I'm not a wlan expert at all. At first I'll attach kernel.log and lspci -v. The machine is a Dell Studio XPS 1340 with a AR928X PCI Express controller. I'm one meter far from the AP (Zyxel 600 P series) and between the notebook and the AP there are only air. With the pre-installed Windows Vista Home the connection to the network (WAP) is almost immediately established after giving the key and the signal power is at 100%. With the Ubuntu 8.04 kernel, 2.6.27-7 and 2.6.27-14, the signal power was about between 60 amd 80%, then after the upgrade to Ubuntu 9.04 and kernel 2.6.28-11 the wireless network doesn't worked any more. Then I compiled a shiny vanilla 2.6.30 and the situation is that I have the signal power at 80% and the access to the network is quite slow (about 20 seconds). I recompiled enabling the debug for ath9k. In the system log I don't see anomalies or errors.
Created attachment 21912 [details] kernel.log (dmesg)
Created attachment 21913 [details] # lspci -v
The signal power sometimes is lowering to 60% and twice in the last 2 hours I've got spontaneous disconnections and reconnections with the following messages in kernel.log: [ 7212.325924] wlan0: disassociating by local choice (reason=3) [ 7214.012032] wlan0: deauthenticating by local choice (reason=3) [ 7220.645862] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 7227.814301] wlan0: authenticate with AP 00:13:49:f0:ec:8f [ 7227.816345] wlan0: authenticated [ 7227.816349] wlan0: associate with AP 00:13:49:f0:ec:8f [ 7227.819019] wlan0: RX AssocResp from 00:13:49:f0:ec:8f (capab=0x471 status=0 aid=2) [ 7227.819023] wlan0: associated [ 7227.819681] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 7237.992022] wlan0: no IPv6 routers present
Created attachment 21932 [details] patch to solve ath9k signal issue
Please apply the above patch and see if it solves your signal issue. This patch can be applied on top of 2.6.30 itself. if you are using the latest wireless-testing, then you can pull my patches from the mailing list.
I applied the patch on top of 2.6.30. I can't see differencies. After applying the kernel log is like this, and the signal power doesn't change (about 80% or less). ath9k 0000:06:00.0: PCI INT A -> Link[Z016] -> GSI 21 (level, low) -> IRQ 21 [ 947.810872] ath9k 0000:06:00.0: setting latency timer to 64 [ 948.246669] phy1: Selected rate control algorithm 'ath9k_rate_control' [ 948.247269] Registered led device: ath9k-phy1::radio [ 948.247283] Registered led device: ath9k-phy1::assoc [ 948.247302] Registered led device: ath9k-phy1::tx [ 948.247314] Registered led device: ath9k-phy1::rx [ 948.247320] phy1: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8160000, irq=21 [ 952.814039] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 967.883471] wlan0: authenticate with AP 00:13:49:f0:ec:8f [ 967.885757] wlan0: authenticated [ 967.885761] wlan0: associate with AP 00:13:49:f0:ec:8f [ 967.888547] wlan0: RX AssocResp from 00:13:49:f0:ec:8f (capab=0x471 status=0 aid=1) [ 967.888551] wlan0: associated [ 967.888783] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 978.604045] wlan0: no IPv6 routers present If that could be useful the output of iwconfig on the device is wlan0 IEEE 802.11abgn ESSID:"ZyXEL" Mode:Managed Frequency:2.437 GHz Access Point: 00:13:49:F0:EC:8F Bit Rate=54 Mb/s Tx-Power=20 dBm Retry min limit:7 RTS thr:off Fragment thr:off Encryption key:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [2] Security mode:open Power Management:off Link Quality=57/70 Signal level=-53 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Please, let me know if I can give more info.
please run ath9k with 0xa404 debug mask and paste the dmesg log here. modprobe ath9k debug=0xa404
Here you are the log in attachment.
Created attachment 21956 [details] kern.log after modprobe ath9k debug=0xa404
Thanks for your log files. Can you please apply the patch and send us the pktlog dump. Please refer to the following steps to take the dump Enable Kconfig CONFIG_ATH9K_DEBUGFS_PKTLOG compile ath9k mount -t debugfs debugfs /tmp_mnt/ echo 1 > /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog_enable assoicate and send few ping packets. cp /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog ath9k_pktlog.log attach ath9k_pktlog.log
Created attachment 21958 [details] pktlog patch for ath9k run git am 0001-ath9k-Add-pktlog-support-for-ATH9K.patch to apply this patch.
(In reply to comment #10) > Thanks for your log files. Can you please apply the patch and send us the > pktlog dump. Please refer to the following steps to take the dump > > Enable Kconfig CONFIG_ATH9K_DEBUGFS_PKTLOG > compile ath9k > mount -t debugfs debugfs /tmp_mnt/ > echo 1 > /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog_enable > assoicate and send few ping packets. Sorry, but I don't know how associate what to what, could you, please, explain a bit more? > cp /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog ath9k_pktlog.log > > attach ath9k_pktlog.log
sorry! I meant to connect the Station to the AP. Connect to the AP is what i meant by saying "associate" Please connect to the AP after enabling the pktlog (echo 1 > ...pktlog_enable) and run few pings. and copy the pktlog from debugfs as mentioned before.
(In reply to comment #13) > sorry! I meant to connect the Station to the AP. Connect to the AP is what i > meant by saying "associate" > > Please connect to the AP after enabling the pktlog (echo 1 > > ...pktlog_enable) > and run few pings. and copy the pktlog from debugfs as mentioned before. Thank you. I already did all except the ping, but there was traffic because I was browsing and the file stayed at 0 bytes; maybe I made something wrong. Now I don't have the machine with me; I'll try again late, this night. At the end we'll find that the gnome applet that display the wifi signal power and network status is buggy :-) There are some more cli and reliable command to see such wifi network things?
Created attachment 21976 [details] Traffic log (some ping) from debugfs with CONFIG_ATH9K_DEBUGFS_PKTLOG enabled and the module loaded with debug=0xa404 Sorry. It was already working this morning but I'm ignorant about debugfs, so I didn't know that also if a file show 0 bytes listing with ls, it can be full of wonderful worlds. How you do to see what's in? Strings doesn't show marvelous things.
We use a proprietary debugging tools to parse the bytes in the ktlog. The RSSIs reported by the hardware seems to be fine with the pktlog. Can you please report the signal level in dBm with the same card and with the same AP on Windows XP You need to simply connect to the AP and use Atheros Wireless Configuration Uitilty to know the signal level in dBm. You can click on STATUS button once connected to know the signal strength in Vista. I have tested with the same card and Windows vista and Ubuntu and noticed that the Signal Levels are same in both cases. thanks for your prompt followup.
(In reply to comment #16) > The RSSIs reported by the hardware seems to be fine with the pktlog. Can you > please report the signal level in dBm with the same card and with the same AP > on Windows XP Sorry, I can't because I don't have Windows XP, only Vista Home installed. > You need to simply connect to the AP and use Atheros Wireless Configuration > Uitilty to know the signal level in dBm. You can click on STATUS button once > connected to know the signal strength in Vista. Where can I find the AWCU or a similar Vista utility? I don't have it. In my Vista the signal is "Excellent" and has five bars on five where on Linux I have 4 bars on five.
I think it is AWIC from what i heard from people though i haven't used Vista personally.The tool is delivered part of driver CD from your vendor. Otherwise, you can use netsh/wlan (show networks mode=bssid)commands in Vista to see the signal strength in %. But not sure if there is an option to see the Signal Level in dBm. Anyway, you can see whta % it shows instead of looking at the no.of bars...
AWIC not found. netsh and wlan and show all doesn't show Signal Level in dBm, but says loudly that the signal strength is 100%, QED. Now it's easy enough to understand why in Linux instead is about 80% or less; it is, it should be something wrong on the Linux side. Good luck!
I'm yet actively looking for a tool for getting the dBm under Vista and thinking about trying under Linux with the same kernel but a different distribution (this one is Ubuntu 9.04.
100% of what? No, I'm serious. If the Windows report is a meaningless number than what difference does it make? How do you know that the Windows number is correct? What defines "100%" signal strength, anyway?
To supplement John's comment about this, I can tell you exactly what we mean by the percentage of quality as per Wireless Extensions in Linux. /* at 45 you will be able to use MCS 15 reliably. A more elaborate * scheme can be used here but it requires tables of SNR/throughput for * each possible mode used. */ rx_status->qual = ds->ds_rxstat.rs_rssi * 100 / 45; So we know internally in our hardware that an rssi of of 45 means we should be able to use MCS rate 15 reliably. That's how we define and judge the the % you see. For 802.11abg networks this can probably be reduced, so for example for ath5k we have: /* An rssi of 35 indicates you should be able use * 54 Mbps reliably. A more elaborate scheme can be used * here but it requires a map of SNR/throughput for each * possible mode used */ rxs.qual = rs.rs_rssi * 100 / 35; So technically we can add a check here if conf_is_ht() for ath9k and when not using HT configurations you'll see a higher bar. So if connecting to an 802.11abg AP only you'll see a higher bar when using ath9k. Is your AP non-802.11n ?
Now I have 150% under Vista and -50% under Linux of stinking socks :-) Sorry, now I've found a shareware software (Wireless Mon) to make a conceptually sensible measurement under Vista and the dBm is about -40. My AP is not n. So as I was saying ;-) there was not a Linux driver problem, but only a different way to display signal strength in Vista and Linux. Am I right? Let me know.
Created attachment 22013 [details] ath9k: differentiate quality reporting between legacy and HT configurations Did you read anything from the last few comments? I am under the impression you are ignoring what we tell you. Anyway please try this patch and please report back.
I'll try with immense pleasure (I'm going to reboot). For the past you're kind, it is, I don't have problems to read what you wrote, but maybe I have problems to understand it because as I wrote at beginning I'm not at all a wireless network expert. But maybe you too could have some problem to understand what I was writing, it is, I was also joking.
Patch applied and tried. The PC doesn't feeze, neither reboot spontaneously and the displayed signal strength is the same as before (about 80% or less) while a iwconfig report: wlan0 IEEE 802.11abgn ESSID:"ZyXEL" Mode:Managed Frequency:2.437 GHz Access Point: 00:13:49:F0:EC:8F Bit Rate=54 Mb/s Tx-Power=20 dBm Retry min limit:7 RTS thr:off Fragment thr:off Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX [2] Security mode:open Power Management:off Link Quality=55/70 Signal level=-55 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 May I do yet something for you?
Provided that Vista is showing you 150% I take it we are doing better in giving you something rather useful and valid. You should see a difference with the patch you applied, can you provide the output of this command before the patch AND then after the patch: while true ; do iwconfig wlan0 | grep "Link Quality" ; sleep 1; done For example here is what I see with ath9k: mcgrof@tesla ~ $ while true ; do iwconfig wlan0 | grep "Link Quality" ; sleep 1; done Link Quality=50/70 Signal level=-60 dBm Link Quality=48/70 Signal level=-62 dBm Link Quality=49/70 Signal level=-61 dBm Link Quality=48/70 Signal level=-62 dBm Link Quality=47/70 Signal level=-63 dBm Link Quality=47/70 Signal level=-63 dBm Link Quality=42/70 Signal level=-68 dBm Link Quality=51/70 Signal level=-59 dBm Link Quality=47/70 Signal level=-63 dBm Link Quality=48/70 Signal level=-62 dBm Link Quality=50/70 Signal level=-60 dBm Link Quality=42/70 Signal level=-68 dBm Link Quality=52/70 Signal level=-58 dBm Link Quality=50/70 Signal level=-60 dBm Also please please try upgrading to something newer, 2.6.30 is actually old for ath9k's and "Link quality" reporting is something that will not get fixed in 2.6.30.x series. See: http://wireless.kernel.org/en/users/Download
Vista is showing 150% of stinking socks so it doesn't smell good at all. Warning that it was not so true, it is, Vista continues to show 5 bars and to say Excellent signal. I suspect that if it catches a whatever signal it say Excellent and display a small nice bmp with 5 bars. After patch: Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=59/70 Signal level=-51 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=58/70 Signal level=-52 dBm Link Quality=58/70 Signal level=-52 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=56/70 Signal level=-54 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=57/70 Signal level=-53 dBm Link Quality=56/70 Signal level=-54 dBm Link Quality=55/70 Signal level=-55 dBm Link Quality=56/70 Signal level=-54 dBm Link Quality=58/70 Signal level=-52 dBm Link Quality=58/70 Signal level=-52 dBm Link Quality=58/70 Signal level=-52 dBm Before patch: Link Quality=61/70 Signal level=-49 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=60/70 Signal level=-50 dBm Link Quality=60/70 Signal level=-50 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=62/70 Signal level=-48 dBm Link Quality=61/70 Signal level=-49 dBm Link Quality=60/70 Signal level=-50 dBm Link Quality=59/70 Signal level=-51 dBm So it seems that the patch does something. Then, thank you very much for your help and sorry for my silly report, because I think that the important thing is not the details showed, but the work of the system and of the driver. Now I'll do the last try, it is a pure ftp transfer of a big file on my LAN with Linux 2.6.30 and Vista. Under Linux: 22766189 bytes received in 10.96 secs (2028.5 kB/s) Under Vista: ftp: 22766189 bytes received in 11,45Seconds 1988,31Kbytes/sec. So it seems at least that Linux is good as Vista in respect to this hardware. I know I'd have to repeat the measurement some times and with bigger files and mybe with different ftp server, but the life is short and I can stop here. If you need more help, let me know.
Looks like you are getting good results with Senthil's patch and my small patch. I believe this bug can be closed now.
Can this bug be closed now?
Sorry I didn't understood that was up to me. For me yes, you can close the bug, also if yesterday evening I suffered some minutes (at least 5) of disconnection and I couldn't connected again also if I have unload and reload many times the module and the network was working because the the PC saw the signal and another device could connect and browse. But it's another story, different from this bug. If it will arrive again I'll open another and different bug.
*** Bug 12930 has been marked as a duplicate of this bug. ***