SIOCGIWSCAN wireless event behaviour

SIOCGIWSCAN wireless event behaviour

[Daniel Drake]

Hi Jean,

A query regarding wireless events: under which circumstances should a 
driver/stack send a SIOCGIWSCAN event to userspace?

Should it be sent whenever a driver has new scan results available, or 
only when the user requested a scan a short time beforehand (via 
SIOCSIWSCAN)?

I ask this because softmac is sending the SIOCGIWSCAN event even when 
the user did not explicitly ask for it.

For example, the user sets an essid. softmac starts a scan in order to 
find the requested network. The network is found, the scan completes, 
and softmac sends SIOCGIWSCAN. softmac then authenticates to that 
network, associates, and then sends SIOCGIWAP.

I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant 
(but have not confirmed that yet).

Thanks,
Daniel

Re: SIOCGIWSCAN wireless event behaviour

[Dan Williams]

On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote:
> Hi Jean,
> 
> A query regarding wireless events: under which circumstances should a 
> driver/stack send a SIOCGIWSCAN event to userspace?
> 
> Should it be sent whenever a driver has new scan results available, or 
> only when the user requested a scan a short time beforehand (via 
> SIOCSIWSCAN)?

Similar situation:  when wpa_supplicant requests a scan, the driver
scans and pushes the GIWSCAN at completion.  _Every_ process (like
NetworkManager) listening for netlink WE messages gets the GIWSCAN event
even though only wpa_supplicant requested the original scan.

So what I'm saying is that applications that process GIWSCAN netlink
messages today should _already_ be able to handle random GIWSCAN events
at any time even when they have not explicitly requested a scan with
SIWSCAN.  The events are broadcast and the driver shouldn't really care
which user app initiated any particular request.  Multiple apps can
theoretically request scans at any time, though this isn't so good in
practice.

> I ask this because softmac is sending the SIOCGIWSCAN event even when 
> the user did not explicitly ask for it.

Given the above, I think this behavior is fine and even desirable.

> I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant 
> (but have not confirmed that yet).

If this is the case, wpa_supplicant should not be getting confused by
GIWSCAN events happening at random times, and should be fixed.  However,
in my experience with 0.4.8, this isn't a problem and wpa_supplicant
handles random scan events correctly.  Not sure about the 0.5.x branch
though.

Dan

Re: SIOCGIWSCAN wireless event behaviour

[Jouni Malinen]

On Thu, Apr 20, 2006 at 03:15:59PM +0100, Daniel Drake wrote:

> I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant 
> (but have not confirmed that yet).

No, they don't. madwifi-ng is already doing this with background
scanning and as was pointed out, there can be multiple programs asking
for scans, so user space must be prepared for multiple events anyway.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: SIOCGIWSCAN wireless event behaviour

[Jean Tourrilhes]

On Thu, Apr 20, 2006 at 10:37:32AM -0400, Dan Williams wrote:
> On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote:
> > Hi Jean,
> > 
> > A query regarding wireless events: under which circumstances should a 
> > driver/stack send a SIOCGIWSCAN event to userspace?
> > 
> > Should it be sent whenever a driver has new scan results available, or 
> > only when the user requested a scan a short time beforehand (via 
> > SIOCSIWSCAN)?

	The original behaviour was that the event was sent only when a
user did request a scan. At that time, cards did not do background
scanning, so new scan results would be produced only as a result of a
user scan.
	After a short discussion we Dan, we agree that to change that,
the driver should send a scan whenever a new scan result is available,
regardless of how it happens (background scan or user scan). This
allow smart application to synchronise on background scans and avoid
them generating useless user scans. Minimising the number of user scan
is actually good.

> Similar situation:  when wpa_supplicant requests a scan, the driver
> scans and pushes the GIWSCAN at completion.  _Every_ process (like
> NetworkManager) listening for netlink WE messages gets the GIWSCAN event
> even though only wpa_supplicant requested the original scan.
> 
> So what I'm saying is that applications that process GIWSCAN netlink
> messages today should _already_ be able to handle random GIWSCAN events
> at any time even when they have not explicitly requested a scan with
> SIWSCAN.  The events are broadcast and the driver shouldn't really care
> which user app initiated any particular request.  Multiple apps can
> theoretically request scans at any time, though this isn't so good in
> practice.

	100% correct.

> > I ask this because softmac is sending the SIOCGIWSCAN event even when 
> > the user did not explicitly ask for it.
> 
> Given the above, I think this behavior is fine and even desirable.

	Yes.

> > I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant 
> > (but have not confirmed that yet).
> 
> If this is the case, wpa_supplicant should not be getting confused by
> GIWSCAN events happening at random times, and should be fixed.  However,
> in my experience with 0.4.8, this isn't a problem and wpa_supplicant
> handles random scan events correctly.  Not sure about the 0.5.x branch
> though.

	After we changed to behaviour of ipw, various users reported
that wpa_supplicant was confused. I particularly trust the report of
Bill Moss, who has been hacking ipw for a long time :

http://sourceforge.net/mailarchive/forum.php?thread_id=10091113&forum_id=38938

	Jouni was notified, but did not really answer to that bug report.
	Then, the ipw maintainers commited the following patch to ipw
that fix or workaround that issue :

http://marc.theaimsgroup.com/?l=linux-netdev&m=114492056522667&w=2

	I would still like Jouni to have a look at the issue to tell
us where the problem is. Two driver having issue is not coincidence. I
would hate driver starting to implement various workaround if the
problem is really in wpa_supplicant.

	Have fun...

	Jean

Re: SIOCGIWSCAN wireless event behaviour

[Jouni Malinen]

On Thu, Apr 20, 2006 at 09:43:54AM -0700, Jean Tourrilhes wrote:
> 	After we changed to behaviour of ipw, various users reported
> that wpa_supplicant was confused. I particularly trust the report of
> Bill Moss, who has been hacking ipw for a long time :
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=10091113&forum_id=38938

Hmm.. Can someone please describe what was changed? Just sending
SIOCGIWSCAN events more frequently? I have not seen any problems with
this in my tests (though, mainly with madwifi-ng). Is the broken case
available in one of the kernel trees? 2.6.16? wireless-2.6? (i.e., where
can I get the exact version of ipw2200 driver that is expected to show
incorrect behavior)?

> 	Jouni was notified, but did not really answer to that bug report.
> 	Then, the ipw maintainers commited the following patch to ipw
> that fix or workaround that issue :
> 
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114492056522667&w=2

Hmm.. I don't remember having seen that report from Bill Moss.. How was
I notified? ;-) The patch here seems to be moving ipw_disassociate()
call, so it is not obviously clear from that what the impact on behavior
is. I can try to reproduce this, but I would like to know what version
to test with in order to avoid any possible workarounds from hiding the
issue.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: SIOCGIWSCAN wireless event behaviour

[Daniel Drake]

Jean Tourrilhes wrote:
> 	The original behaviour was that the event was sent only when a
> user did request a scan. At that time, cards did not do background
> scanning, so new scan results would be produced only as a result of a
> user scan.
> 	After a short discussion we Dan, we agree that to change that,
> the driver should send a scan whenever a new scan result is available,
> regardless of how it happens (background scan or user scan). This
> allow smart application to synchronise on background scans and avoid
> them generating useless user scans. Minimising the number of user scan
> is actually good.

Thanks for all the responses.

I am not sure if the 'extra' SIOCGIWSCAN event is what is causing 
wpa_supplicant's confusion, but the kind of behaviour I am seeing is 
wpa_supplicant associating to the network, immediately disassociating, 
and then associating again before the connection stabilises. This is 
with wpa_supplicant 0.5.2 connecting to an unencrypted network.

I am also seeing that softmac reassociates with a network after 
wpa_supplicant exits.

Johannes posted a softmac patch earlier which may help (related to 
softmac's handling of SIOCGIWAP). I will do some further investigation 
and provide a more complete report if that doesn't fix it.

Thanks,
Daniel