Re: [ath9k-devel] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue

Re: [ath9k-devel] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue

[Oleksij Rempel]

Am 19.09.2013 17:01, schrieb 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.
>
> This is the scan output:
> wlan0 (phy #0): scan started
> wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5745
> 5765 5785 5805 5825, ""

At the scan time the card will switch channel and will stop to receive 
packets. Normally it will do lots of jumps. For example, if you 
connected on channel 2437, it will jump like: 2437->2412; 2412->2437; 
2437->2417; ... and so on. Jump back to primer channel is needed to 
check if there is some thing new to receive or send.
In case of dualband hardware, the scan will be extra long. Because there 
is more channels and some hardware need longer to switch between 2G and 5G.
Next problem is bus delay. In case if you use usb adapter a channel 
switch may take terribly long time. Mostly it depends on usb host 
controller on other usb related bugs. Currently I fight with one of this 
problems. In my case, with unoptimised driver, usb wifi adapter need 
1second!!!! to change a channel. It mean 26seconds for scan on one band 
adapter and almost 40 sends on dualband.

May be we should try to do less intensive scan with bigger delays 
between channel switches?

-- 
Regards,
Oleksij