iwlist wlan0 scan disrupts communications

iwlist wlan0 scan disrupts communications

[Charles Gordon]

Hi,

I am using version 2.6.28 of the kernel and version 0.9.11-nogit of
iw.  Communications are disrupted and the device stops responding to
ping when I use the command "iwlist wlan0 scan".  Communications are
restored when the command completes.  Is this behavior expected?  Has
it been fixed in a later release?

Thanks for your help.

Re: iwlist wlan0 scan disrupts communications

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Tue, 2009-10-27 at 16:40 -0400, Charles Gordon wrote:
> Hi,
> 
> I am using version 2.6.28 of the kernel and version 0.9.11-nogit of
> iw.  Communications are disrupted and the device stops responding to
> ping when I use the command "iwlist wlan0 scan".  Communications are
> restored when the command completes.  Is this behavior expected?  Has
> it been fixed in a later release?

Yes and yes, but I don't remember whether it's better in 2.6.31 or only
will be in 32.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: iwlist wlan0 scan disrupts communications

[John W. Linville]

On Tue, Oct 27, 2009 at 04:40:46PM -0400, Charles Gordon wrote:

> I am using version 2.6.28 of the kernel and version 0.9.11-nogit of
> iw.  Communications are disrupted and the device stops responding to
> ping when I use the command "iwlist wlan0 scan".  Communications are
> restored when the command completes.  Is this behavior expected?  Has
> it been fixed in a later release?

The device has to change frequencies to conduct the scan.  Kinda like
missing part of a show while you are flipping channels... :-)

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: iwlist wlan0 scan disrupts communications

[Charles Gordon]

On Tue, Oct 27, 2009 at 4:43 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2009-10-27 at 16:40 -0400, Charles Gordon wrote:
>> Hi,
>>
>> I am using version 2.6.28 of the kernel and version 0.9.11-nogit of
>> iw.  Communications are disrupted and the device stops responding to
>> ping when I use the command "iwlist wlan0 scan".  Communications are
>> restored when the command completes.  Is this behavior expected?  Has
>> it been fixed in a later release?
>
> Yes and yes, but I don't remember whether it's better in 2.6.31 or only
> will be in 32.
>
> johannes
>
Thanks for the information.  After doing some more testing I found
that the association to the AP is sometimes lost and that mac80211
does not recover automatically.  You have to type the command "wpa_cli
reassociate" to trigger the stack to reassociate with the AP.  Is this
one of the things that is, or will be, fixed in later releases?

Re: iwlist wlan0 scan disrupts communications

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Wed, 2009-10-28 at 10:47 -0400, Charles Gordon wrote:

> Thanks for the information.  After doing some more testing I found
> that the association to the AP is sometimes lost and that mac80211
> does not recover automatically.  You have to type the command "wpa_cli
> reassociate" to trigger the stack to reassociate with the AP.  Is this
> one of the things that is, or will be, fixed in later releases?

I don't know. Normally, wpa_supplicant should notice this and re-connect
by itself.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: iwlist wlan0 scan disrupts communications

[Charles Gordon]

On Wed, Oct 28, 2009 at 10:54 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-10-28 at 10:47 -0400, Charles Gordon wrote:
>
>> Thanks for the information.  After doing some more testing I found
>> that the association to the AP is sometimes lost and that mac80211
>> does not recover automatically.  You have to type the command "wpa_cli
>> reassociate" to trigger the stack to reassociate with the AP.  Is this
>> one of the things that is, or will be, fixed in later releases?
>
> I don't know. Normally, wpa_supplicant should notice this and re-connect
> by itself.
>
> johannes
>
I think the way wpa_supplicant would notice this is that the AP would
send a deauthentication or dissassociation frame to the station, and
that would trigger wpa_supplicant to reassociate.  However, if we are
tuned to a different channel when the frame is sent, then we won't
receive it.  The AP won't send another notification unless we try to
send it another data frame, but if another station is trying to send
to us, we won't be notified.

I think that when the scan completes, mac80211 should either notify
wpa_supplicant that it should reassociate, or maybe send a null-data
frame to the AP which might cause it to send another
deauthentication/dissassociation frame (if we lost the connect).

Re: iwlist wlan0 scan disrupts communications

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Wed, 2009-10-28 at 11:02 -0400, Charles Gordon wrote:

> I think that when the scan completes, mac80211 should either notify
> wpa_supplicant that it should reassociate, or maybe send a null-data
> frame to the AP which might cause it to send another
> deauthentication/dissassociation frame (if we lost the connect).

it does send nullfunc frames, you're probably running into an old bug
that caused those to not be sent.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: iwlist wlan0 scan disrupts communications

[Dan Williams]

On Wed, 2009-10-28 at 16:23 +0100, Johannes Berg wrote:
> On Wed, 2009-10-28 at 11:02 -0400, Charles Gordon wrote:
> 
> > I think that when the scan completes, mac80211 should either notify
> > wpa_supplicant that it should reassociate, or maybe send a null-data
> > frame to the AP which might cause it to send another
> > deauthentication/dissassociation frame (if we lost the connect).
> 
> it does send nullfunc frames, you're probably running into an old bug
> that caused those to not be sent.

Correct, 2.6.28 did *not* have the nullfunc TX fix, so if the scan lasts
more than a few seconds, and the AP has traffic for the STA the TX will
time out, and the AP may drop the STA during the scan.  2.6.29 was the
first kernel that had the nullfunc TX fix.

But the supplicant should still reconnect...

Dan