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

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

[James Hogan]

    Hello, I am having an issue connecting to my University's network.
It seems that I can connect to the network just fine, but upon trying to
surf the internet, I get about 20-30 seconds of service and then all of
a sudden, I can no longer reach the internet. I have been dealing with
this for a few weeks now and have contacted the gentoo community to try
and get some assistance from them, but it doesn't seem that they can
help me right now. I have tried this on my laptop which is also running
an ath9k NIC under fedora and I am having the same issue. I've also
contacted my I.T. department which expressed to me that they have been
having issues with Atheros cards as well. So, for the sake of classes, I
switched my laptop over to windows until I can find a way to get this
resolved, and I am getting great service running windows 8; before doing
that I have tried fresh installs and wiping all of my settings to make
sure that it is not on my end.

On my desktop I am using a TP-Link TL-WDN4800 and I am able to connect
to WPA2-PSK and other non-enterprise networks just fine. I've done a
"iwlist wlan0 scan" and the following is the output I received regarding
the network:

          Cell 04 - Address: 00:24:6C:5E:C4:03
                    Channel:1
                    Frequency:2.412 GHz (Channel 1)
                    Quality=53/70  Signal level=-57 dBm 
                    Encryption key:on
                    ESSID:"Liberty-Secure"
                    Bit Rates:2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s; 11 Mb/s
                              12 Mb/s; 18 Mb/s; 24 Mb/s
                    Bit Rates:36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=00000030023b991c
                    Extra: Last beacon: 20ms ago
                    IE: Unknown: 000E4C6962657274792D536563757265
                    IE: Unknown: 0108840B0C1216182430
                    IE: Unknown: 030101
                    IE: Unknown: 2A0100
                    IE: Unknown: 320348606C
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : 802.1x
                    IE: Unknown:
2D1A4C101BFFFF000000000000000000000000000000000000000000
                    IE: Unknown:
3D1601001B00000000000000000000000000000000000000
                    IE: Unknown:
DD180050F2020101800003A4000027A4000042435E0062322F00

          Cell 07 - Address: 00:1A:1E:26:29:72
                    Channel:48
                    Frequency:5.24 GHz (Channel 48)
                    Quality=61/70  Signal level=-49 dBm 
                    Encryption key:on
                    ESSID:"Liberty-Secure"
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
                              36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=00000015e96f0925
                    Extra: Last beacon: 20ms ago
                    IE: Unknown: 000E4C6962657274792D536563757265
                    IE: Unknown: 01088C129824B048606C
                    IE: Unknown: 030130
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : 802.1x
                    IE: Unknown:
2D1A4E001BFFFF000000000000000000000000000000000000000000
                    IE: Unknown:
3D1630071B00000000000000000000000000000000000000
                    IE: Unknown:
DD180050F2020101800003A4000027A4000042435E0062322F00

The network is setup with WPA2-PEAP MSCHAPV2 and all I need to log in is
a simple username and password. When connecting, dmesg reads:

[36675.408026] cfg80211: Calling CRDA to update world regulatory domain
[36675.410364] cfg80211: World regulatory domain updated:
[36675.410365] cfg80211:   (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[36675.410367] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[36675.410368] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[36675.410370] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[36675.410371] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[36675.410372] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[36676.219228] wlan0: authenticate with 00:1a:1e:26:29:71
[36676.229755] wlan0: send auth to 00:1a:1e:26:29:71 (try 1/3)
[36676.235179] wlan0: authenticated
[36676.238745] wlan0: associate with 00:1a:1e:26:29:71 (try 1/3)
[36676.247702] wlan0: RX AssocResp from 00:1a:1e:26:29:71 (capab=0x401
status=0 aid=1)
[36676.247738] wlan0: associated

and I am getting high "Tx excessive retries" and "Invalid misc"

wlan0     IEEE 802.11abgn  ESSID:"Liberty-Secure" 
          Mode:Managed  Frequency:2.412 GHz  Access Point:
00:24:6C:5E:C4:03  
          Bit Rate=65 Mb/s   Tx-Power=20 dBm  
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=52/70  Signal level=-58 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:XXX  Invalid misc:XXX   Missed beacon:0

I have also tried many of the "fixes" that I have found online such as
setting nohwcrypt=1, messing with the bit rate, power, txpower, RTS
threshold and Fragmentation Threshold. But none of these or combination
of these seems to help with the connection. Would anyone have an idea of
why I am having this connectivity issue and how it could be fixed?

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

[Sujith Manoharan]

James Hogan wrote:
> I have also tried many of the "fixes" that I have found online such as
> setting nohwcrypt=1, messing with the bit rate, power, txpower, RTS
> threshold and Fragmentation Threshold. But none of these or combination
> of these seems to help with the connection. Would anyone have an idea of
> why I am having this connectivity issue and how it could be fixed?

As a first step, can you run "iw event -r" and post the output when
the issue happens ?

Sujith

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

[James Hogan]

On 09/08/2013 12:27 AM, Sujith Manoharan wrote:
> James Hogan wrote:
I did what you asked several times and these are the outputs of the
connection and I stopped collecting information after the connection halted.

Event Collection 1:

0.005590: phy #0: regulatory domain change: set to world roaming by the
wireless core upon initialization request
0.076504: wlan0 (phy #0): scan started
1.763889: 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, ""
4.577283: wlan0 (phy #0): scan started
0.052601: wlan0 (phy #0): scan finished: 5805, "Liberty-Secure" ""
0.011238: wlan0: new station 00:1a:1e:26:29:72
0.031062: wlan0 (phy #0): auth 00:1a:1e:26:29:72 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.011068: wlan0 (phy #0): assoc 00:1a:1e:26:29:72 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.000051: wlan0 (phy #0): connected to 00:1a:1e:26:29:72
30.250601: wlan0: del station 00:1a:1e:26:29:72
0.002574: wlan0 (phy #0): deauth 90:f6:52:e5:70:ba -> 00:1a:1e:26:29:72
reason 3: Deauthenticated because sending station is leaving (or has
left) the IBSS or ESS
0.000034: wlan0 (phy #0): disconnected (local request)
0.009137: wlan0 (phy #0): scan started
0.000223: phy #0: regulatory domain change: set to world roaming by the
wireless core upon initialization request
1.764157: 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, ""
1.930870: wlan0 (phy #0): scan started
0.179075: wlan0 (phy #0): scan finished: 2437 5805 2412, "Liberty-Secure" ""
0.011008: wlan0: new station 00:1a:1e:26:29:63
0.002366: wlan0 (phy #0): auth 00:1a:1e:26:29:63 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.014596: wlan0 (phy #0): assoc 00:1a:1e:26:29:63 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.000037: wlan0 (phy #0): connected to 00:1a:1e:26:29:63
22.689046: wlan0 (phy #0): scan started
5.443075: 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, ""

Event Collection 2:

0.000000: wlan0 (phy #0): scan started
0.055583: wlan0 (phy #0): scan finished: 5805, "Liberty-Secure" ""
0.010907: wlan0: new station 00:1a:1e:26:29:72
0.026507: wlan0 (phy #0): auth 00:1a:1e:26:29:72 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.006747: wlan0 (phy #0): assoc 00:1a:1e:26:29:72 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.000042: wlan0 (phy #0): connected to 00:1a:1e:26:29:72
10.499642: wlan0 (phy #0): scan started
4.986236: 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, ""
38.015947: wlan0 (phy #0): scan started
4.754113: 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, ""

Event Collection 3:

0.000000: 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, ""
5.477191: wlan0 (phy #0): scan started
0.172822: wlan0 (phy #0): scan finished: 2412 2437 5805, "Liberty-Secure" ""
0.011097: wlan0: new station 00:24:6c:5e:c4:03
0.003659: wlan0 (phy #0): auth 00:24:6c:5e:c4:03 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.013466: wlan0 (phy #0): assoc 00:24:6c:5e:c4:03 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.000031: wlan0 (phy #0): connected to 00:24:6c:5e:c4:03
5.171650: wlan0: del station 00:24:6c:5e:c4:03
0.002947: wlan0 (phy #0): deauth 00:24:6c:5e:c4:03 -> 90:f6:52:e5:70:ba
reason 3: Deauthenticated because sending station is leaving (or has
left) the IBSS or ESS
0.000065: wlan0 (phy #0): disconnected (by AP) reason: 3:
Deauthenticated because sending station is leaving (or has left) the
IBSS or ESS
0.066127: phy #0: regulatory domain change: set to world roaming by the
wireless core upon initialization request
0.040392: wlan0 (phy #0): scan started
0.130527: wlan0 (phy #0): scan finished: 2437 5805, "Liberty-Secure" ""
0.011063: wlan0: new station 00:1a:1e:26:29:63
0.078828: wlan0: del station 00:1a:1e:26:29:63
0.002833: wlan0 (phy #0): auth 00:1a:1e:26:29:63 -> 90:f6:52:e5:70:ba
status: 17: Association denied because AP is unable to handle additional
associated STA
0.106661: wlan0 (phy #0): scan started
0.060565: wlan0 (phy #0): scan finished: 5805, "Liberty-Secure" ""
0.011142: wlan0: new station 00:24:6c:5e:c4:12
0.003231: wlan0 (phy #0): auth 00:24:6c:5e:c4:12 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.018798: wlan0 (phy #0): assoc 00:24:6c:5e:c4:12 -> 90:f6:52:e5:70:ba
status: 0: Successful
0.000090: wlan0 (phy #0): connected to 00:24:6c:5e:c4:12
9.836378: wlan0 (phy #0): scan started
5.240365: 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, ""

I hope this helps, thank you for your help.

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

[Sujith Manoharan]

James Hogan wrote:
> 0.000051: wlan0 (phy #0): connected to 00:1a:1e:26:29:72
> 30.250601: wlan0: del station 00:1a:1e:26:29:72
> 0.002574: wlan0 (phy #0): deauth 90:f6:52:e5:70:ba -> 00:1a:1e:26:29:72
> reason 3: Deauthenticated because sending station is leaving (or has
> left) the IBSS or ESS
> 0.000034: wlan0 (phy #0): disconnected (local request)

In all the cases, the link has been disconnected locally, probably by
NetworkManager (if you are using it).

Can you please open a bug in bugzilla.kernel.org to track this ?

Sujith

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

[Holger Schurig]

> Can you please open a bug in bugzilla.kernel.org to track this ?

Why?  We even don't know if it is a kernel problem or not.

It might as well be a problem with the AP, e.g.

> 0.002833: wlan0 (phy #0): auth 00:1a:1e:26:29:63 -> 90:f6:52:e5:70:ba
> status: 17: Association denied because AP is unable to handle additional
> associated STA

sounds like a tremendously overloaded AP. The " Deauthenticated
because sending station is leaving (or has left) the IBSS or ESS"
sounds like a signal strength issue. It might also be a antenna setup
issue, e.g. I once had an AP set to diversity, but with only one
antenna connected, and that produced similar weird results.

However, so far nothing indicates to me that this might be a kernel
(ath9k driver) problem.

So we're still at the stage to isolate the culprit.

What I'd do is to first stop the interface, i.e. bring it down. Then
make sure that no Network Manager, wicd or similar tool is running.
Now, from the command line start wpa_supplicant manually, i.e.
something like

wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -Dnl80211

if that doesn't tell you more, than try to add -d to get debug
information (Gentoo users must probably recompile wpa_supplicant with
USE=debug). If you see something fishy now, then it's probably a
problem with wpa_supplicant and/or the AP. If you don't see something
fishy there (i.e., everything works), then it might have been
NetworkManager/wicd.

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

[Sujith Manoharan]

Holger Schurig wrote:
> Why?  We even don't know if it is a kernel problem or not.

There are quite a few bug reports about connectivity problems
with ath9k and we need more information to see where the problem
lies (kernel log, lspci, wpa_s log, NM log etc.)

> It might as well be a problem with the AP, e.g.

Things are apparently fine with Windows (according to the original mail).

Sujith

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

[Holger Schurig]

Ah, okay.

> Things are apparently fine with Windows (according to the original mail).

Yep, and Windows doesn't have wicd or Network Manager ...  (well it
does have an equivalent, but AFAIK not externally to the supplicant)


Just as a note: where I am working, we have devices with ath9k running
fine in numbers of hundreds, but usually in simple WEP (cought,
customers...) and WPA2 setups. They are in environments there there
are between 10..50 APs and they roam all the time.

However, I disabled ANI, I can't see how this will possibly work when
you're roaming heavily.


I'm normally using the ath9k drivers from "vanilla" stable kernels,
e.g. currently 3.10.10, not vendor kernels.

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

[James Hogan]

On 09/10/2013 03:50 AM, Holger Schurig wrote:
>> Can you please open a bug in bugzilla.kernel.org to track this ?
> Why?  We even don't know if it is a kernel problem or not.
>
> It might as well be a problem with the AP, e.g.
>
>> 0.002833: wlan0 (phy #0): auth 00:1a:1e:26:29:63 -> 90:f6:52:e5:70:ba
>> status: 17: Association denied because AP is unable to handle additional
>> associated STA
> sounds like a tremendously overloaded AP. The " Deauthenticated
> because sending station is leaving (or has left) the IBSS or ESS"
> sounds like a signal strength issue. It might also be a antenna setup
> issue, e.g. I once had an AP set to diversity, but with only one
> antenna connected, and that produced similar weird results.
>
> However, so far nothing indicates to me that this might be a kernel
> (ath9k driver) problem.
>
> So we're still at the stage to isolate the culprit.
>
> What I'd do is to first stop the interface, i.e. bring it down. Then
> make sure that no Network Manager, wicd or similar tool is running.
> Now, from the command line start wpa_supplicant manually, i.e.
> something like
>
> wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -Dnl80211
>
> if that doesn't tell you more, than try to add -d to get debug
> information (Gentoo users must probably recompile wpa_supplicant with
> USE=debug). If you see something fishy now, then it's probably a
> problem with wpa_supplicant and/or the AP. If you don't see something
> fishy there (i.e., everything works), then it might have been
> NetworkManager/wicd.
I am happy to try to provide you all with as much information as you
guys need and I appreciate your help. I tool your suggestion and set up
wpa_supplicant with debugging and I posted the output online at
http://bpaste.net/show/131278/ . At line 1471 I ended the connection.
I'm not getting even the 20-30 seconds of connection with this setup
though... I don't know if there is a particular reason, but it is just
and observation.

Here is my wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
update_config=1
ap_scan=1
eapol_version=1
fast_reauth=1
network={
    ssid="Liberty-Secure"
    scan_ssid=1
    key_mgmt=WPA-EAP
    proto=WPA2
    pairwise=CCMP
    group=CCMP
   
ca_cert="/home/jhogan/Downloads/NetworkManager/system-connections/ebe5dd8f-0ab5-4437-a7d7-9e941c364657-ca-cert.pem"
    eap=PEAP
    identity="jhogan22"
    password="***********"
    phase1="peaplabel=1"
    phase2="auth=MSCHAPV2"
}

Also, this is the output of "iwconfig wlan0" after about 40 seconds, as
you can see the Invalid Misc is very high

wlan0     IEEE 802.11abgn  ESSID:"Liberty-Secure" 
          Mode:Managed  Frequency:2.437 GHz  Access Point:
00:1A:1E:26:29:63  
          Bit Rate=117 Mb/s   Tx-Power=20 dBm  
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=61/70  Signal level=-49 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:764   Missed beacon:0

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

[Sujith Manoharan]

James Hogan wrote:
> I am happy to try to provide you all with as much information as you
> guys need and I appreciate your help. I tool your suggestion and set up
> wpa_supplicant with debugging and I posted the output online at
> http://bpaste.net/show/131278/ . At line 1471 I ended the connection.
> I'm not getting even the 20-30 seconds of connection with this setup
> though... I don't know if there is a particular reason, but it is just
> and observation.

Please use -Dnl80211 with wpa_supplicant. WEXT has been deprecated for
a number of years.

Sujith

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

[James Hogan]

On 09/10/2013 09:53 PM, Sujith Manoharan wrote:
> James Hogan wrote:
>> I am happy to try to provide you all with as much information as you
>> guys need and I appreciate your help. I tool your suggestion and set up
>> wpa_supplicant with debugging and I posted the output online at
>> http://bpaste.net/show/131278/ . At line 1471 I ended the connection.
>> I'm not getting even the 20-30 seconds of connection with this setup
>> though... I don't know if there is a particular reason, but it is just
>> and observation.
> Please use -Dnl80211 with wpa_supplicant. WEXT has been deprecated for
> a number of years.
>
> Sujith
Here is the link to the wpa_supplicant debug with the nl80211 driver enabled
http://bpaste.net/show/131621/

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

[Holger Schurig]

> Please use -Dnl80211 with wpa_supplicant. WEXT has been deprecated for
> a number of years.

Probably wpa_supplicant should, in it's devel branch, make this to be
"-Ddeprecated_wext". That way Linux distributions that blindly
recompile things and don't think are forced to do something :-)  Or
scrap the WEXT support in the devel-branch totally ...

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

[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, ""

[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

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

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

[James Hogan]

I am up to try anything, but, at least in my case, this is not an error 
in the drive itself but is an error with the network. The schools' 
wireless network is rather old and needs to be updated, so I found a 
patch that was never implemented into ath9k and modified my own ath9k 
driver. I know that it is probably not the correct way to go about 
attacking the issue, but for school purposes, I need to at least have a 
working computer. My desktop has not been edited and I would like to 
continue using that to test and find a proper way of attacking the 
issue. As for now, here are my diffs

*** drivers/net/wireless/ath/ath9k/init.c.bak~    2013-09-20 
22:35:20.982551676 -0400
--- drivers/net/wireless/ath/ath9k/init.c    2013-09-20 
22:43:16.322997704 -0400
***************
*** 57,62 ****
--- 57,66 ----
   module_param_named(enable_diversity, ath9k_enable_diversity, int, 0444);
   MODULE_PARM_DESC(enable_diversity, "Enable Antenna diversity for 
AR9565");

+ int ath9k_modparam_disable_11n;
+ module_param_named(11n_disable, ath9k_modparam_disable_11n, int, 0444);
+ MODULE_PARM_DESC(11n_disable, "disable 11n functionality");
+
   bool is_ath9k_unloaded;
   /* We use the hw_value as an index into our private channel structure */

***************
*** 254,260 ****
       u8 tx_streams, rx_streams;
       int i, max_streams;

!     ht_info->ht_supported = true;
       ht_info->cap = IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
                  IEEE80211_HT_CAP_SM_PS |
                  IEEE80211_HT_CAP_SGI_40 |
--- 258,268 ----
       u8 tx_streams, rx_streams;
       int i, max_streams;

!     if (ath9k_modparam_disable_11n)
!         ht_info->ht_supported = false;
!     else
!         ht_info->ht_supported = true;
!
       ht_info->cap = IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
                  IEEE80211_HT_CAP_SM_PS |
                  IEEE80211_HT_CAP_SGI_40 |

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

[Ben Greear]

On 09/20/2013 08:30 PM, James Hogan wrote:
> I am up to try anything, but, at least in my case, this is not an error
> in the drive itself but is an error with the network. The schools'
> wireless network is rather old and needs to be updated, so I found a
> patch that was never implemented into ath9k and modified my own ath9k
> driver. I know that it is probably not the correct way to go about
> attacking the issue, but for school purposes, I need to at least have a
> working computer. My desktop has not been edited and I would like to
> continue using that to test and find a proper way of attacking the
> issue. As for now, here are my diffs
>
> *** drivers/net/wireless/ath/ath9k/init.c.bak~    2013-09-20
> 22:35:20.982551676 -0400
> --- drivers/net/wireless/ath/ath9k/init.c    2013-09-20
> 22:43:16.322997704 -0400
> ***************
> *** 57,62 ****
> --- 57,66 ----
>     module_param_named(enable_diversity, ath9k_enable_diversity, int, 0444);
>     MODULE_PARM_DESC(enable_diversity, "Enable Antenna diversity for
> AR9565");
>
> + int ath9k_modparam_disable_11n;
> + module_param_named(11n_disable, ath9k_modparam_disable_11n, int, 0444);
> + MODULE_PARM_DESC(11n_disable, "disable 11n functionality");


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
#
# disable_sgi: Whether SGI (short guard interval) should be disabled.
# 0 = SGI enabled (if AP supports it)
# 1 = SGI disabled
#
# ht_mcs:  Configure allowed MCS rates.
#  Parsed as an array of bytes, in base-16 (ascii-hex)
# ht_mcs=""                                   // Use all available (default)
# ht_mcs="0xff 00 00 00 00 00 00 00 00 00 "   // Use MCS 0-7 only
# ht_mcs="0xff ff 00 00 00 00 00 00 00 00 "   // Use MCS 0-15 only
#
# disable_max_amsdu:  Whether MAX_AMSDU should be disabled.
# -1 = Do not make any changes.
# 0  = Enable MAX-AMSDU if hardware supports it.
# 1  = Disable AMSDU
#
# ampdu_density:  Allow overriding AMPDU density configuration.
#  Treated as hint by the kernel.
# -1 = Do not make any changes.
# 0-3 = Set AMPDU density (aka factor) to specified value.

# disable_vht: Whether VHT should be disabled.
# 0 = VHT enabled (if AP supports it)
# 1 = VHT disabled
#
# vht_capa: VHT capabilities to set in the override
# vht_capa_mask: mask of VHT capabilities
#
# vht_rx_mcs_nss_1/2/3/4/5/6/7/8: override the MCS set for RX NSS 1-8
# vht_tx_mcs_nss_1/2/3/4/5/6/7/8: override the MCS set for TX NSS 1-8
#  0: MCS 0-7
#  1: MCS 0-8
#  2: MCS 0-9
#  3: not supported


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

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

[Джонатан Вашингтон]

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] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue

[Sujith Manoharan]

???????? ????????? wrote:
> 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.

3.2 is really old...

> 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.

Can you try the latest backports release, using just wpa_supplicant and
Network Manager disabled ?

https://lkml.org/lkml/2013/10/27/149

Sujith

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

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

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

[Джонатан Вашингтон]

On 28 October 2013 12:20, Ben Greear <greearb@candelatech.com> wrote:
>
> 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 <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>



On 28 October 2013 11:47, Sujith Manoharan <sujith@msujith.org> wrote:
> ???????? ????????? wrote:
>> 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.
>
> 3.2 is really old...
>
>> 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.
>
> Can you try the latest backports release, using just wpa_supplicant and
> Network Manager disabled ?
>
> https://lkml.org/lkml/2013/10/27/149
>
> Sujith


With the driver from backports-3.10.17-1 (using my current kernel,
which turns out to be from debian testing, not debian unstable), I'm
able to adjust the speed manually, and disable 11n speeds in
wpa_supplicant config files.

However, as I found from other users who've encountered the same
limitation at my university, I must actually entirely disable 11n
speeds at the driver level.  It has something to do with speeds
presented as available during authentication, I guess?  Anyway, the
driver I compiled from backports doesn't seem to support this.  Would
the patch presented by James in September be a viable solution, or is
there some reason for me to avoid it?

-- 
Jonathan