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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
