On Tue, Jan 07, 2014 at 04:59:47PM +0100, Johannes Berg wrote: > On Mon, 2014-01-06 at 09:51 +0200, Jouni Malinen wrote: > > This adds new nl80211 attributes to allow MinChannelTime and > > MaxChannelTime to be specified for scan requests. The parameters can be > > used to control the amount of time spent on each channel during a scan > > as specified in the IEEE Std 802.11-2012 MLME-SCAN.request() primitive. > > What are the specific use cases for this? Our driver is likely to muck > around with these in the future, possibly depending on traffic levels > etc., so I wonder what this addresses and whether it can be unified in > some way? I don't have any specific use case in mind. These are parameters included in the standard and there are various new use cases coming up for IEEE 802.11 scanning and those could potentially be able to use this type of parameters. Similarly, I'd actually like to see quite a bit additional flexibility in scanning operations like partial scan reports (event notification of updated BSSes per channel etc.) and aborting scans, etc., that has also come up in the past. > Would you expect these to always be specified, to the point where our > driver no longer has any flexibility in adjusting things internally? Maybe for some use cases, but unlikely for the find an AP to connect to case. > > + * @min_chan_time: MinChannelTime in TUs; time to spend waiting for > > + * PHY-CCA.indication (channel busy) in Active scan; 0 to indicate that driver > > + * default value to be used > > + * @max_chan_time: MaxChannelTime in TUs; time to spend waiting for Beacon or > > + * Probe Response frames; 0 to indicate that driver default value to be used > > missing some indentation Different coding styles.. I can handle this whenever there is an example close-by, but this structure did not have one :). > > + * @NL80211_ATTR_MIN_CHANNEL_TIME: MinChannelTime - Minimum time (in TU) to > > + * spend on each channel when scanning (used for active scans). If not > > + * included, the driver will use its default value. u32 attribute. > > What about passive scans? As defined in IEEE Std 802.11-2012.. In other words, MinChannelTime is not used with passive scans. As you can see from the mac80211 implementation in the following patch, that does not use this MinChannelTime even for active scans. This could be used for the optimization where CCA detection could be used to stop an Active scan more quickly. I'm not sure whether we'd ever use this, but well, it was easy to include for completeness sake. > If you specify a very long min_chan_time, that's unlikely to please > drivers. Especially if multi-channel mode is implemented, maybe in > conjunction with operating as a GO or a client that wants to hear DTIM > beacons, this might become very complicated. Agreed. I was thinking of adding some limits on how large a value could be set, but could not come up with any specific, justifiable value. (And the standard was not very helpful either with the "N/A" as the valid range ;-). > I'd be really interested in seeing if we can address the use cases here > in a different way that keeps more flexibility in the > driver/firmware/... implementation of scan. That would require knowing the specific use cases first.. :) In general, I'd expect to see need for doing scans that take less time even if that results in smaller likelihood of seeing BSSes on the first attempt. I could come up with much more difficult designs for the driver/firmware to handle, but I'm not sure whether something more flexible would be available unless someone can first articulate specific use cases. -- Jouni Malinen PGP id EFC895FA -- 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
