I'm opening this new bug on behalf of an Ubuntu user, Christiansen. Will attach their relevant debug files and comments they had posted to a bug in Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/463625 Christiansen wrote: "The information collected was using the Karmic RC Live CD (2.6.31 based kernel) and default ath5k module from the linux-image. Connectionspeed was checked several times using the ISPs reliable internet speed test, and the result was less than 256Kbit/ps downspeed and very unstable - link was checked to more than 2 Mbit/ps with an other Kubuntu 8.04 with the default ath_pci module loaded, this was done in between the Karmic RC tests - The boxes was connected to the AP one at a time, and no other access for other client boxes was allowed. The LBM (linux-backports-modules package containing the latest compat-wireless stable release) was tested on an newly installed Karmic RC from the same live CD and on the same box, and was updated with all updates including the the LBM. The test results was even worse than with the default ath5k module. A test on an enterprise Cisco WiFi network was done too with the same box, and the connection speed was even less than with the default module and wireless stack. Compiling an ath-pci module from source (Ver. 10.0.5.6), and loading the module on the other hand showed the expected connection speed on the enterprise network, which is approximately 18.000 Kbit/ps (18 Mbps effective on a 54G network). I then successfully compiled the the wireless-compat stack dated 2009-10-27, and loaded the ath5k module without any errors seen in dmesg. Ran a connection speed test and got same result as with the LBM module, rebooted and reran the test with same bad result. So unfortunately it seems like the bug is still present in the latest modules too. Modules loaded after "sudo make install" was: ath5k 122372 0 mac80211 210508 1 ath5k ath 8828 1 ath5k cfg80211 131048 3 ath5k,mac80211,ath led_class 4096 2 ath5k,thinkpad_acpi "
Created attachment 23582 [details] BootDmesg.txt
Created attachment 23583 [details] CurrentDmesg.txt
Created attachment 23584 [details] Lspci.txt
Created attachment 23585 [details] WifiSyslog.txt
Is this a rate scaling issue? Or some other problem?
Madwifi vs ath5k. Can you give a pointer to the source for madwifi you are using? The last time I tried madwifi-ng the results were worse than ath5k.
Certainly, the madwifi source used is taken from here: http://snapshots.madwifi-project.org/madwifi-hal-0.10.5.6/ Please note that there is at typo in version number in the initial bug description. This madwifi snapshot was only used to to clarify that the bug was relater to the ath5k module and not other things, but even being a development snapshot it performs fine. The throughput is nearly what you should expect from a 54g wifi transfer between a single client and the access point (18-22 Mbps oneway). Stability isn't perfect on this development snapshot and sometimes resets the connection though, but unfortunately the 0.9.4 didn't compile under the Ubuntu kernel 2.6.31). The ath5k modules from both the ubuntu kernel image and from the backports modules isn't usable at all, as throughput isn't exceeding 250 kbps at all and with the latest wireless-compat stack even less. Further more this bug seems to hit only a subset of the Atheros chipset, of which I've access to and tested some used in Lenove/IBM ThinkPads and a Cisco PCMCIA. PCI-ID for NOT usable adapters: ThinkPads [168c:1014] sub-id [1014:058a] Cisco [168c:0013] sub-id [14b9:cb21] Disabling the internal adapter in the ThinkPad BIOS and using a Netgear WG-500T Atheros based PCMCIA adapter and the ath5k module is working fully reliable on the same box and OS. The adapter used in Lenovo and the last IBM ThinkPads is described here: http://www.thinkwiki.org/wiki/ThinkPad_11a/b/g_Wireless_LAN_Mini_Express_Adapter I've tested both Kununtu 9.04 (2.6.28), 9.10 (2.6.31) and openSUSE 11.1 with the ThinkPads, and the ath5k module shows this extreme low throughput. Opposite the madwifi 0.9.4 witch is fully reliable for both 9.04 and 11.1.
Thanks, that is good information. I'll do some comparison testing with the dev snapshot of madwifi. One other thing that would be nice to have is the MAC and Phy revision that ath5k prints at load time for both working and non-working adapters. I think the non-working ones are 5212s but not 100% sure. There may be some bug in the reset procedure that puts it in a bad state on some chipsets. Oh one other thing, are any antenna settings used with madwifi or just default?
I've been pooking around in the dmesg log from booting with the internal adapter and the two PCMCIA cards, as it seems that the the ThinkPad adapter reports only one line and the Netgear adapter reports two "phy0" lines. Don't know if this is caused by the ThinkPad has one combined chip and the Netgear two chips (can't disassemble it). But here is what I hope you are asking for: *NOT* working ThinkPad [168c:1014] sub-id [1014:058a]: ath5k phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61) Working - Netgear [168c:1013] sub-id [1385:4b00]: ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43) ath5k phy0: RF2112B 2GHz radio found (0x46) I've used no module parameters using the madwifi dev snapshot and no changes to the sourcecode, so antenna settings should be the defaults. BTW Please don't concentrate on the Cisco adapter, as this right now seems noticeable better than in my last tests - maybe I did only it with one of the last development release of Kubuntu Karmic, concentrating on the ThinkPad one - sorry for the misinformation. Now working - Cisco [168c:0013] sub-id [14b9:cb21]: ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43) ath5k phy0: RF5112B multiband radio found (0x36)
Just did a little following up on my previous comment (#9) and your comment (#8) about the chipset probably being 5212. I tried loading an older Kubuntu 9.04 with kernel 2.8.28 and madwifi 0.9.4. The default loaded ath5k module stated, as with Kubuntu 9.10 and kernel2.8.31, that the the chipset was 5214. Opposite when loading the madwifi ath_pci the chipset is detected as 5212 as you expected, is this a correct behavior ? Attaching dmesg from loading the two modules (madwifi-ath5-loading-kubuntu904-k2-6-28.txt)
Created attachment 23635 [details] Loading ath_pci and ath5k under Kubuntu 9.04
Comment on attachment 23635 [details] Loading ath_pci and ath5k under Kubuntu 9.04 This test was done on the same box used for earlier tests and of course with the internal ThinkPad adapter.
Tried out the compat-wireless 2009-11-19 bundle on kernel 2.6.31 today, and it seem still to contain this bug, even though I think there is slightly increase in throughput (from the 2-300 Kbps to around 1000 kbps). Installed the new Kubuntu Lucid (10.4) pre-alpha with the 2.6.32 kernel on another partition, and had same bad experience with the modules from this one. I've been going through the bug rapports on the Ubuntu bugzilla (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/461419?comments=all), and it seems that there are two types ThinkPad adapters suffering from this bug: PCI-id [168c:1014] sub-id [1014:058a] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61) PCI-id [168c:0012] sub-id [17ab:8310] ath5k phy0: Atheros AR5211 chip found (MAC: 0x42, PHY: 0x30) Hope there's at chance that this could be solved in the 2.6.32 kernel ?
There was this patch posted recently to fix a bug in ofdm calibration - I don't think it was in 11-19 yet. Does it help? http://patchwork.kernel.org/patch/61472/
Applied patch 61472 to compat-wireless 2009-11-19, as it wasn't present in that version. A couple of tests unfortunately didn't show any noticeable change in performance. From the comments inside the patch, it states that the change is aimed at the 5 Ghz A band, where all the comments above concentrate on the 2.4 Ghz B band. I'll look into testing the ath5k module against 5 Ghz APs, as soon as I'm able to setup an environment.
Well, it affects any OFDM - which also includes 802.11g in the 2.4 ghz band, but yes the 11b modes should be unchanged (also it shouldn't be specific to any particular radio, so probably not what we're looking for). FWIW I peeked into madwifi and its probe message doesn't seem to have much to do with the actual chip its detecting. I still haven't had the time to do a full on analysis though.
Hi Folks, I have a very similar problem (poor connection speed) and I have noticed something that might help. I have a dual boot Asus-P2 system with a NetGear WG311T Wireless PCI Adapter configured to boot into either Hardy or Karmic. When I boot into Hardy my wifi chip seems to be AR5212/AR5213, but when I boot into Karmic it seems to be AR5001X+. Perhaps this is quite normal or maybe something is wrong and it confuses the driver? Comments please and/or suggest alternative bug number if you think I'm in the wrong bug. Many thanks. Regards, Peter. THE FOLLOWING IS WHEN BOOTED INTO HARDY (8.04) peter@asus-p2:~$ sudo lshw -C network [sudo] password for peter: *-network description: Ethernet interface product: RTL8111/8168B PCI Express Gigabit Ethernet controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:02:00.0 logical name: eth0 version: 02 serial: 00:22:15:68:34:71 capacity: 1GB/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.2LK duplex=half latency=0 link=no module=r8169 multicast=yes port=twisted pair *-network description: Wireless interface product: AR5212/AR5213 Multiprotocol MAC/baseband processor vendor: Atheros Communications Inc. physical id: e bus info: pci@0000:01:0e.0 logical name: wifi0 version: 01 serial: 00:1b:2f:cb:90:05 width: 32 bits clock: 33MHz capabilities: pm bus_master cap_list logical ethernet physical wireless configuration: broadcast=yes driver=ath_pci ip=192.168.1.100 latency=168 maxlatency=28 mingnt=10 module=ath_pci multicast=yes wireless=IEEE 802.11g peter@asus-p2:~$ peter@asus-p2:~$ lspci ... 01:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01) ... THE FOLLOWING IS WHEN BOOTED INTO KARMIC (9.10) - The AR5212/AR5213 now appears to be AR5001X+ !!!! peter@asus-p2:~$ sudo lshw -C network [sudo] password for peter: *-network description: Ethernet interface product: RTL8111/8168B PCI Express Gigabit Ethernet controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:02:00.0 logical name: eth0 version: 02 serial: 00:22:15:68:34:71 size: 10MB/s capacity: 1GB/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=half latency=0 link=no multicast=yes port=MII speed=10MB/s resources: irq:25 ioport:e800(size=256) memory:dffff000-dfffffff memory:daff0000-daffffff(prefetchable) memory:dffc0000-dffdffff(prefetchable) *-network description: Wireless interface product: Atheros AR5001X+ Wireless Network Adapter vendor: Atheros Communications Inc. physical id: e bus info: pci@0000:01:0e.0 logical name: wmaster0 version: 01 serial: 00:1b:2f:cb:90:05 width: 32 bits clock: 33MHz capabilities: pm bus_master cap_list logical ethernet physical wireless configuration: broadcast=yes driver=ath5k ip=192.168.1.100 latency=168 maxlatency=28 mingnt=10 multicast=yes wireless=IEEE 802.11bg resources: irq:17 memory:dfef0000-dfefffff peter@asus-p2:~$ peter@asus-p2:~$ lspci ... 01:0e.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01) ...
As mentioned in previous comment, I'm getting similar problem, I have a dual boot Asus-P2 system with a NetGear WG311T Wireless PCI Adapter configured to boot Kubuntu into either Hardy or Karmic. I have more evidence of chip identity contradictions which might prove useful. I understand now that AR5001+ is a family name, however, when booting into Hardy dmesg finds Atheros 5212, while booting into Karmic dmesg finds Atheros AR2414 (see below) as well as AR5001+ (as in previous posting). When booted into Kubuntu Hardy: peter@asus-p2:~$ cat /proc/version_signature Ubuntu 2.6.24-25.63-generic peter@asus-p2:~$ uname -a Linux asus-p2 2.6.24-25-generic #1 SMP Tue Oct 20 06:49:12 UTC 2009 x86_64 GNU/Linux peter@asus-p2:~$ dmesg | grep Atheros [ 43.933322] wifi0: Atheros 5212: mem=0xdfef0000, irq=17 When booted into Kubuntu Karmic peter@asus-p2:~$ cat /proc/version_signature Ubuntu 2.6.31-15.50-generic peter@asus-p2:~$ uname -a Linux asus-p2 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux peter@asus-p2:~$ dmesg | grep Atheros [ 6.890502] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45) peter@asus-p2:~$ Hope this is useful, or maybe it is to be expected for some strange reason?
ThinkPad adapter Update: Did a test on the compat-wireless dated 2009-12-11 yesterday, and unfortunately didn't find any improvements yet - in fact I think there is slightly at decrease in bandwidth compared with the ath5k module in the Karmic default kernel package (right now on 2.6.31-16). In the meantime I've found that madwifi-project.org provides an updated 0.9.4, (http://snapshots.madwifi-project.org/madwifi-0.9.4-current.tar.gz) that compiles correct on newer kernels, and works fine on these boxes. This modules is as stable as the ath_pci module provided in earlier Kubuntu releases, BUT of course has the "defaulting to txpower 8dBm" bug present, which the earlier mentioned dev snapshot 0.10.5.6 hasn't. So still wishing ath5k would work with these adaptors.... @Peter I have been testing a pci WG311T with these data: #lspci -vvnn Ethernet controller [0200]: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter [168c:0013] (rev 01) Subsystem: Netgear Device [1385:4d00] #dmesg | grep -i phy ath5k phy0: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41) ath5k phy0: RF5111 5GHz radio found (0x17) ath5k phy0: RF2111 2GHz radio found (0x23) on karmic box for a couple of days now, and fund the ath5k module provided with the standard Kubuntu 2.6.31-16 kernel working_amazing_stable_and_fast (17.6 Mbps download) with this adapter (just like the PCMCIA WG511T mentioned earlier too). The test was done using WPA2/AES encryption on a Cisco AP with hidden SSID, and no changes to the default OS install in any way. So I belive that either you are using an adapter with slightly other data or you could experience another bug.
Tried compat-wireless drivers 2010-02-10 on kernel 2.6.31 (Ubuntu 9.10 kernel 2.6.31-19) again a cuple of dayes ago, and unfortunately still unable to connect to any AP. Just to rule out any distro specific bugs, I've installed both OpenSUSE 11.2 and Mandriva 2010.0 (both kernel 2.6.31) on one of the ThinkPads used for testing, and found exact same troubles with the ath5k module. Meanwhile bugs on this exact adapter ([168c:1014] sub-id [1014:058a] / MAC: 0xa3, PHY: 0x61) keeps ticking in on the bugtracker at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/461419 (even though headline only states AR5211). Latest released Kernel 2.6.33 tested too. Just to figure out if this is related to the older kernels, I upgraded the Ubuntu 9.10 kernel yesterday to a precompiled 2.6.33 kernel from PPA on launchpad.net. Tests on different AP types unfortunately still shows exact same problem as for earlier kernels - only establish connection to the AP in very rear cases.
Adding a few eyes, just in case. Perhaps Nick has some insight?
So to summarize by mac/phy revisions (the only thing that really matters): 0xa3/0x61: not good (but I use one of these every day without issue, not IBM version though) 0x56/0x41: good 0x79/0x45: not good 0x42/0x30: not good 0x59/0x43: good I don't see any real pattern here. Dumb question, the rfkill is disengaged on all of these right? `rfkill list` should show. The rfkill utility is available at http://linuxwireless.org/en/users/Documentation/rfkill.
Can you please try the latest patches from Bruno on I/Q calibration posted on linux-wireless ?
@Bob Copeland Neither soft- or hardblocked according to "rfkill list" on any of the testboxes. All testboxes use a factory mounted and original IBM/Lenovo adapter, but I was wondering if the regdomain could cause different experience or are you using WPA/WPA2 Enterprise ? Attaching a logfile from manually loading the ath5k module, running rfkill, waiting for connection fail, manually unloading ath5k module, loading a selfcompiled ath_pci and waiting for successfully connection to AP. @Nick Kossifidis Should I use the latest compat-wireless drivers, or is it necessary to I patch - and where do I find this patch if so.
Created attachment 25368 [details] Loading ath5k on ThinkPad in the EU Loading ath5k module,no connection established, unloading it, loading ath_pci and connection established.
@Nick Found and applied the 3 of 3 I/Q calibration patches from Bruno. I didn't notice any changes in behavior though, and successful connection rate still was about 1 out of 10 - and in the rear cases when it did connected, the bandwidth still was below 1 Mbps.
I wouldn't expect IQ calibration to affect the ability to associate, since the association typically happens at 1 mbit anyway - though it should have a large impact on performance once established. Christiansen, can you get a packet capture of failed (in ath5k) and successful (in madwifi) authentication attempts? Best way is to use a second card tuned to the same channel in monitor mode, if you have access to another device.
(In reply to comment #24) > @Bob Copeland > Neither soft- or hardblocked according to "rfkill list" on any of the > testboxes. All testboxes use a factory mounted and original IBM/Lenovo > adapter, > but I was wondering if the regdomain could cause different experience or are > you using WPA/WPA2 Enterprise ? Yes, regdomain can have an impact, particularly if your AP is configured to beacon with the wrong country, or if the eeprom in your card is programmed to a conservative setting. 'iw phy phy0 info' can show you which channels you're allowed to connect to. I have used both WPA and WPA enterprise here without problems. I typically use WPA2 personal, the EAP was with hostapd and its internal radius server.
Finally by coincidence, while trying to create the requested wireless traces, I found why this bug is so mysterious. While trying to make some useful traces, I changed from channel 10 (2.457 Mhz) to channel 3 (2.422 Mhz) on the AP used for test. Suddenly I was able to connect fast and with high signalstrength (according to nm-tool), and a speedtest showed a bandwidth above 15 Mbps. Changed back to channel 10, and after several attempts finally got connected to the AP, this time with the same poor experience of speed and signalstrength. Checked all channels from 1-13 with a PC reboot between channel changes on the AP. Found perfect performance on ch. 1-6, more doubtful performance on ch. 7-8 and bad performance or no connection on channel 9-13 (12 and 13 witch are allowed in EU). Changed environment to another address and AP where this thinkpad adapter (MAC: 0xa3, PHY: 0x61) wasn't usable neither, and found the AP running ch. 11. Changed it to ch 1, and the test-box connected fine and now showed great performed with the ath5k module too. While conducting the channel test, I did test the already good known Cisco adapter (MAC: 0x59, PHY: 0x43). And not surprisingly this performed fine on all channels (1-13) in the exact same environment.
Created attachment 25439 [details] tracing AP connection with ath5k - no encryption used
Created attachment 25440 [details] tracing AP connection with ath_pci - no encryption used
Created attachment 25441 [details] messagelog from the thinkpad connecting to the AP While the messageslog is from the laptop connecting to the AP, another PC was use for tracing wireless communication using on the excact channel by executing: sudo airodump-ng -d 00:1E:10:10:1B:D3 -c 10 wlan0 -w testX-athXXXX The AP was configured to use the least interrupted channel, channel 10 witch is one of the trouble-channels according to the comment posted earlier. No encryption was used hopefully to allow useful data already from the linklayer negotiation portion, as this issn't possible according aircrack docs when using WPA encryption - and the problem was equal without. Timing was syncroniced using NTP on all boxes. This messagelog contains all the test conducted, but only captures from test 5 and 6 is chosen as the most precise - on from ath5k and one from ath_pci as requested.
Did the attached traces and the fact that the ath5k module doesn't allow using channel 9-13 give any clue on how to solve this bug ?.
Ok, a couple of things -- First, you typically shouldn't use channel 10 in 2.4 ghz spectrum because it overlaps other channels. You'll get a lot of interference that way from APs on channel 9 or 11. In US, 1,6,11 are generally used; in EU, Wikipedia tells me 1,5,9,13. I think your issue is noise, but it's hard to tell from the packet traces. It's better to get a capture with a monitor mode interface, then we can get radiotap headers as well: $ sudo iw dev wlan0 interface add wlan0.mon type monitor $ sudo ifconfig wlan0.mon up $ sudo tshark -i wlan0.mon -w wlan0.pcap Looking at your traces, I see in both cases successful authentication. In the ath5k case, it has a harder time acking packets. In particular, 5 seconds elapse before an ARP reply is successfully sent from the station to the AP in the ath5k case. One thing that would be interesting to try is to debug which antennas are being used. If you get the latest w-t kernel, you can mount debugfs and look at the antenna file in /sys/kernel/debug/ath5k/phy0/antenna. The commit that adds this is 604eeadd188 in wireless-testing, in case you just want to get that patch.
Created attachment 25661 [details] ath5k module and AP channel 11
Created attachment 25662 [details] ath_pci module and AP channel 11
Created attachment 25663 [details] ath5k module and AP channel 6
Created attachment 25664 [details] logs Oh yes, I do know the rules for designing an enterprise WiFi network with roaming capabilities and, you are right, in Europe we some time design using channel 1,5,9,13. But due to some cheep WiFi adapter manufactures, who doesn't make either chipset or driver capable of using channel 12 and 13, we often uses a 1,6,11 design to support those too. But no matter what rules applies to real network design, a lot of personal routers/APs doesn't apply to those. And I often find that they are configured and running with firmeware-defaults for channel selection. This is often something like "auto", allowing scanning and selection of the least congested channel between 1 and 11 (13). The choice to run previous traces on channel 10, was only to ensure a minimum of noise in the trace from an other AP running channel 11 at that time - I was convinced that the interesting part was to find differences in why madwifi connects and works flawlessly while ath5k doesn't on all channels above 8. Regarding monitor mode, the interface on the box tracing transmission certainly was brought in this mode using: $ sudo airmon-ng start wlan0 before dumping traces (on channel 10 only) to the file: $ sudo airodump-ng -d 00:1E:10:10:1B:D3 -c 10 wlan0 -w testX-athXXXX No matter what, I've attached 3 new traces and the logs, using your preferred tool and exact commands: 1 Tracing while loading ath5k and connecting to the AP running channel 11 - not connected 2 Tracing while loading ath_pci and connecting to the AP running channel 11 - connected 3 Tracing while loading ath5k and connecting to the AP running channel 6 - connected 4 messages and deamon logs from the above plus a scan of any other Wifi networks in the test-area From what I read in any of thees traces, you do not see much traffic transferred between the test-client and the test-AP this way. But hopefully you find what the previous traces didn't show you... Regarding noise I've tried changing to channel (below 7) on a couple of other personal WiFi networks in the meantime, just to find that it was now possible use those with this adapter and using ath5k. So I can't help asking, does ath5k handle noise different on higher channels than the lower ones ?. And does the antenna question still matter, when things are okay on the lower channels ? If that still the case, and I or Google had any clue of what a w-t kernel or wireless-testing is and how to make it run on any known distro, I probably would spend some time on your last request too.
Heh, ok thanks for your patience -- I know it's a pain to collect this stuff and frustrating that it takes so long to get it fixed. So the good news is we have radiotap headers now, so I can see e.g. relative signal strength and noise from some AP called kenneth-net. Bad news is I left out the step where we set the channel :( $ iw dev wlan0 set channel 11 Anyway don't worry about it or the wireless-testing patch. I'll put together a patchset for you to try on Thursday that has the requisite changes, as well as some debugging of calibration setup. That is done in different stages for different frequency ranges so it's possible there's some issue in what we're doing there.
Created attachment 25705 [details] ath5k module and AP channel 11 ver. 2
Created attachment 25706 [details] ath_pci module and AP channel 11 ver. 2
Created attachment 25707 [details] ath5k module and AP channel 6 ver. 2
Created attachment 25708 [details] logs ver. 2 Didn't want to sound disapointed, and I know how much work it often demands to find similar (especial WiFi related) bugs and correct them without spoiling other things. I've attached new traces versions, with the capturing box bound to the right channel: $ sudo iw dev wlan0 interface add wlan0.mon type monitor $ sudo iw dev wlan0 set channel 11 $ sudo ifconfig wlan0.mon up $ sudo tshark -i wlan0.mon -w wlan0.pcap Hope they provide more accurate information on radiotap and other things regarding the connection betwen test-client and test-AP. The noising private SSID you mentions form previous traces, is pretty far away (note at least -80 dB PWR) and parted from the test-area by at least 2 dubble brick walls and more than 20 meters in free air. I'm looking forward to the patchset, hoping they will bring more light on the issue.
Created attachment 25719 [details] various patches on vanilla 2.6.33 Ok this patch includes various things (if you want to split-up patches, see http://bobcopeland.com/kernel/wl/20100325/). It applies on vanilla 2.6.33. First, we should look at /debug/ath5k/phyX/frameerrors to see how many TX retransmissions there are, and antenna in the same directory to see which antennae are being used for TX. You can change the antenna selection by echoing 'fixed-a', 'fixed-b' or 'diversity' into the antenna file; echoing 'clear' resets the stats for either file. Next, there are some calibration fixes and calibration debug. When loading the module use modparam "debug=0x20" -- or echo calib into the 'debug' file to turn it on or off. You'll get a lot of output during a scan, that's ok - just want to see the different values for different channels, so the values right after switching channels will be useful. We'll start with that and see how it goes...
Created attachment 25743 [details] Debugging output running channel 6 on AP
Created attachment 25744 [details] Debugging output running channel 11 on AP
Applied the patch to a 2.6.33 kernel, enabled debugging for the ath5k module and compiled. I was now able to get debugging info from the antenna and frameerrors files, and was able to change the antenna used. I attached output from antenna, frameerrors, messages and daemon.log right after a connection was made - and without changing any configuration settings of the module. The client box was rebooted after the channel was chanced on the AP, and the module was loaded with debug=0x20 in both cases. Don't know if the debugging files show anything useful, but TX retransmissions seem low to me - and I'm was not sure exactly how the test case was meant to be performed either... On the other hand manually changing antenna when the AP ran on channel 11, did make a huge difference in performance. I fact I think that performance was pretty much the same (perfect), as seen on channels below 6, when echoing fixed-b to the antenna file. Using fixed-a or diversity showed same bad performance as seen on all other previous tests.
Bob, have you had a chance to look at this?
John, it's solved sometime between compact-wireless-2010-03-28 and compact-wireless-2010-04-19 - I can't narrow it down further right now, as there is a compile failure on ath5k base.c for the all releases in between. Right now I've been using compact-wireless-2010-05-22 for some days, and running the APs on channel 11 now, with perfect performance.
In that case, it sounds like you merely need to wait for 2.6.35. :-)
2.6.35 is now available, closing based on report from comment 49.
And a final reply to #51 an #52 I can confirm that running the 2.6.35 kernel since it was released, has solved this bug. Also applying compat-wireless 2.6.35 stable modules on boxes running kernels between 2.6.32 and 2.6.34 also works fine. Thanks for the great effort to whoever solved this pretty strange problem, and to all other involved.
Yeah I think it was Bruno's fixes to antenna diversity settings. At any rate, thanks for testing and reporting back!