On 2013-09-19 17:01, James Hogan: > I think I have stumbled on to the real issue. I'm sorry if I have been > wasting your time at all. Apparently, the network is having problems > with all wireless-n mode cards. > The network doesn't like how wireless-n is roaming to the different AP's > and is registering as me disconnecting when the wireless card tries to > connect to roam to the other AP. > It's not just ath9k though, Ra-Link and other cards are having these > issues as well. Is there a way to disable or to make it possible to > disable the wireless-n mode of the card and just > use wireless abg? On a note, I noticed when I passed to the command line > "iw event -r" that at about the time my card would scan, that is when I > would stop receiving service even though > my cards never registered as being disconnected. After the scan, the > card just continues to reissue scans. Sometimes however, it will try to > reconnect me to the network. I was talking to one of the IT employees > in my class today and he said that they have been having this issue with > all of the newer higher-end cards.
I've been having a similar problem, potentially the same. My university updated the firmware in their access points in August, and while I can still associate with the APs with no trouble, I can only get traffic through for short periods of time. As in James's case, I seem to lose service around when my card scans. I have been told by my university's wireless team that they are aware that this issue affects most linux users on campus, but don't currently have any solution. Their suggested work-around is to disable 11n speeds, which apparently "solves" the problem for most users. However, while iwconfig can be used to set various rates when connected to my 11g router at home, the speed seems to be locked at 65Mbps when I'm associated with the router on campus. That is, "sudo iwconfig wlan0 rate 54M" and similar directives seem to have no effect. For reference, I have an AR9285 card and so far have been using the ath9k driver that comes with my 3.2.0 debian stock kernel (which might technically be 3.2.41?). I have noticed nothing unusual about using any other networks, including 11n ones elsewhere. On 2013-09-21 05:40, Ben Greear wrote: > If you are using ath9k rate control, please try disabling that and use the minstrel-ht rate control instead. > > With a modern wpa_supplicant and kernel you can just disable HT in the supplicant config, by the way. > > > # disable_ht: Whether HT (802.11n) should be disabled. > # 0 = HT enabled (if AP supports it) > # 1 = HT disabled > # > # disable_ht40: Whether HT-40 (802.11n) should be disabled. > # 0 = HT-40 enabled (if AP supports it) > # 1 = HT-40 disabled I found I had an older version of wpa_supplicant (v1.0, which is what appears to be current in debian unstable) that did not support disable_ht and disable_ht40, so I downloaded a newer version (v2.0) and compiled it with CONFIG_HT_OVERRIDES enabled. Using that, I was able to add disable_ht=1 and disable_ht40=1 to the network block of my wpa_supplicant configuration file. When I run wpa_supplicant now in debug mode, it seems to parse these directives, and even outputs lines like "wlan0: set_disable_ht40: 1" where it seems to be telling the driver to disable the mode. However, iwconfig still indicates that the speed is 65Mbps, and no number of times manually telling it otherwise seems to have any impact on it. I don't know whether this limitation is due to an issue with the ath9k driver, with wpa_supplicant, or with something else, or is simply my misperception of how things should work. Either way, I'm tempted to apply the patch to my ath9k source that James posted so that I can disable 11n modes altogether, but I'm more than willing to try other suggestions. -- Jonathan _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
