linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* (no subject)
@ 2008-02-25 21:22 Dan Williams
  2008-02-25 21:30 ` multiple scan request handling (was: <empty>) Johannes Berg
  0 siblings, 1 reply; 2+ messages in thread
From: Dan Williams @ 2008-02-25 21:22 UTC (permalink / raw)
  To: linux-wireless

While debugging why ipw2200 and wpa_supplicant would not connect to a
hidden access point today even with scan_ssid=1, I ran into an
interesting scan behavior question.

The root of the problem was that since the ipw2200 driver aggressively
rescans when it doesn't find the requested AP in it's list, and since it
only allows one scan at a time, wpa_supplicant's specific SSID scans
just happened to get rejected every time, which means the card never
sent out probe requests for the hidden SSID I wanted to associate with.

There are more general issues here than just ipw2200 though.  Most of
the fullmac drivers (counting ipw2x00 here) don't handle multiple scan
requests very well.  I'm not entirely sure what mac80211 does here but
it probably doesn't have extremely sophisticated scan result handling
either.  At startup

In the ideal case, the driver would add each separate scan request to a
queue, execute each request in turn (respecting each requests options
like active/passive, dwell time, SSID/BSSID, channel list, etc).  Each
request would trigger a corresponding scan completion event.  Perhaps
multiple identical scan requests (ie, a few 'iwlist <iface> scan') could
be batched together for efficiency.  With nl80211/cfg80211, perhaps each
individual scan request would have a UID to match it up with a specific
scan response (but the response would still be broadcast too).

Less invasive fixes could be made to ipw2200, like caching the last
SSID-specific request and instead of triggering a general scan the next
time, trigger a direct scan.  A workaround but not a real fix.

Thoughts?  How should a second, different scan request be handled while
another is already in flight?

Dan


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: multiple scan request handling (was: <empty>)
  2008-02-25 21:22 Dan Williams
@ 2008-02-25 21:30 ` Johannes Berg
  0 siblings, 0 replies; 2+ messages in thread
From: Johannes Berg @ 2008-02-25 21:30 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-wireless

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


> In the ideal case, the driver would add each separate scan request to a
> queue, execute each request in turn (respecting each requests options
> like active/passive, dwell time, SSID/BSSID, channel list, etc).  Each
> request would trigger a corresponding scan completion event.  

I'm not sure that each separate scan request should be added, if they
just differ a bit wrt. dwell time, especially if the second requested
dwell time is larger, I think they shouldn't necessarily be batched.

> Perhaps
> multiple identical scan requests (ie, a few 'iwlist <iface> scan') could
> be batched together for efficiency.  

Yeah at least when they're identical.

> With nl80211/cfg80211, perhaps each
> individual scan request would have a UID to match it up with a specific
> scan response (but the response would still be broadcast too).

That would certainly be doable although it seems that including the scan
config in the response might be better?

It seems reasonable to require some sort of queuing especially when it
is possible that, like you experienced, automatically triggered scans
don't allow manual ones to go through.

Maybe that should ultimately be done at the cfg80211 level already?

johannes

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-02-25 21:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-25 21:22 Dan Williams
2008-02-25 21:30 ` multiple scan request handling (was: <empty>) Johannes Berg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).