Dan Williams wrote:
On Thu, 2008-08-07 at 19:43 +0100, Dave wrote:
That said, what's wrong with the ap_scan=2 mode? You've stated it's not
great (and I'm prepared to believe it), but what is the actual problem?
But the problem with ap_scan=2 is really about the failure window.
ap_scan=2 basically dumps a load of options on the driver, and unless
the options _exactly_ match the configuration of the AP, you won't
connect. The supplicant isn't able to make intelligent choices about
which networks in its config file match the scan result, thus there's a
lot more potential for failure unless you know exactly what your network
is set up to do, and these capabilities aren't always exposed through
beacons. So ap_scan=2 just opens up a huge window of failure and stuff
can't ever Just Work because no intelligence can be applied.
Wouldn't a different mode of operation in wpa_supplicant solve this (see below)? Then get rid of the mode selection via wpa_supplicant.conf by selecting mode based on drivers error responses (and/or reported capabilities).
ap_scan=3:
* wpa_supplicant requests scan with SIOCSIWSCAN
* driver reports scan complete with wireless event SIOCGIWSCAN
* wpa_supplicant reads scan results with SIOCGIWSCAN (multiple call if a larget buffer is needed)
* wpa_supplicant decides which SSID to use based on scan results
* wpa_supplicant configures driver to associate with an SSID (SIOCSIWMODE, SIOCSIWGENIE, SIOCSIWAUTH, SIOCSIWESSID)
SIOCSIWSCAN not supported? => ap_scan=2
SIOCSIWFREQ or SIOCSIWAP not supported? => ap_scan=3
else ap_scan=1
Regards,
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
