From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Mon, 28 Oct 2013 09:20:48 -0700 Subject: [ath9k-devel] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue In-Reply-To: References: Message-ID: <526E8EE0.2010308@candelatech.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 10/28/2013 07:34 AM, ???????? ????????? wrote: > 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. I think your kernel is too old to support that feature, it is relatively recent. And, while I know it works with ath9k, I'm not sure it works with other drivers. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com