All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <linux@rempel-privat.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue
Date: Thu, 19 Sep 2013 17:48:33 +0200	[thread overview]
Message-ID: <523B1CD1.1050207@rempel-privat.de> (raw)
In-Reply-To: <523B11E0.4070504@gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Oleksij Rempel <linux@rempel-privat.de>
To: James Hogan <jhogan22.liberty@gmail.com>
Cc: Sujith Manoharan <sujith@msujith.org>,
	"ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [ath9k-devel] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue
Date: Thu, 19 Sep 2013 17:48:33 +0200	[thread overview]
Message-ID: <523B1CD1.1050207@rempel-privat.de> (raw)
In-Reply-To: <523B11E0.4070504@gmail.com>

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

  reply	other threads:[~2013-09-19 15:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-07 19:25 [ath9k-devel] ath9k WPA2-PEAP MSCHAPV2 Connectivity issue James Hogan
2013-09-08  4:27 ` Sujith Manoharan
2013-09-08 17:10   ` James Hogan
2013-09-09 12:28     ` Sujith Manoharan
2013-09-10  7:50       ` Holger Schurig
2013-09-10  8:05         ` Sujith Manoharan
2013-09-10  8:20           ` Holger Schurig
2013-09-11  1:03         ` James Hogan
2013-09-11  1:53           ` Sujith Manoharan
2013-09-11 22:04             ` James Hogan
2013-09-15 14:30             ` Holger Schurig
2013-09-19 15:01             ` James Hogan
2013-09-19 15:48               ` Oleksij Rempel [this message]
2013-09-19 15:48                 ` Oleksij Rempel
2013-09-21  3:30                 ` James Hogan
2013-09-21  3:40                   ` Ben Greear
  -- strict thread matches above, loose matches on Subject: below --
2013-10-28 14:34 Джонатан Вашингтон
2013-10-28 15:47 ` Sujith Manoharan
2013-10-28 16:20 ` Ben Greear
2013-11-01 20:53   ` Джонатан Вашингтон

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523B1CD1.1050207@rempel-privat.de \
    --to=linux@rempel-privat.de \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.