On Tue, Jan 27, 2009 at 2:12 PM, Dan Williams <[email protected]> wrote:
> I guess there's no particular reason 9 seconds can't be used instead of > 10 in the non-supplicant scan case. We "fixed" this in 0.7 by always > using the supplicant to scan, since it's pointless to have scanning code > in two different places. Is there a technical reason why you'd even want to wait that long? What about using 5 or 6 seconds initially rather than mucking with the timeout from within wireless_event_helper() ? Since the code as it is now waits the full timeout interval anyway (receipt of the wireless events is effectively a no-op since self->priv->scan_timeout is set), setting the timeout interval to 9 seconds or less at the time the iw_set_ext() scan is initiated should do the trick. No changes to wireless_event_helper() required. > > However, you could try to modify wireless_event_handler() to, instead of > only scheduling the scan result timeout when there isn't one already > scheduled, cancel the outstanding scan results timeout *if* it will > trigger later than now + 5 seconds. > > Dan > If there's a technical reason why we should wait up to 9 seconds in the first place, then I could go ahead and create a patch like that, but this might be more work than is needed. I'll experiment tonight with changing the 10 to a 5 in the initial call to schedule_scan_results_timeout() at the time the iw_set_ext() scan is initiated from within the nm_device_802_11_wireless_scan() function. cheers, Dan
_______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
