On Tue, 2014-01-07 at 09:04 -0800, Paul Stewart wrote: > I've seen situations where it'd be useful to distinguish in user-space > between scan types. Here are a few scenarios: > > - Scanning for geo-location while associated (low-priority scan, tolerant > to delayed/incomplete results, definitely not intended to interrupt or > delay any inbound data traffic) > - Background scan. If there is traffic during the scan, we should abort > (NL80211_SCAN_FLAG_LOW_PRIORITY should help with this). If there is > a history of traffic (e.g, an active data transfer) we might want to flag > further that this scan should have shorter-than-usual dwell times as above. This makes sense, I'm not sure the first is all that much different from the second, though the precise meaning of "low priority" isn't all that well defined. > - User-initiated scanning while idle in extremely congested networks > (may need to actually wait a full beacon interval on each channel since > the APs contend with each other to respond to probe requests -- user > initiated, so it behooves us to get a complete list). That's an interesting situation, but I'm not sure how you'd ever detect which channels are extremely congested? johannes -- 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
