Hi, I'm an student and I'm interested in the 802.11 scanning. I've investigating over this subject over the last months. I'll take the opportunity to share some points. 2014/1/7 Jouni Malinen <j@xxxxx>: > 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. As M. Stewart said in a previous mail, there are some scenarios where the scanning algorithms depends on the application priorities, to add another examples: - A mobile station is moving (for example someone is walking on the street with some available community networks) so, to take advantage of an eventual connection the scanning needs to be very fast, then it might need a list of candidate APs ASAP, no matter if the list in incomplete. In this scenario the values for Min/MaxChannelTime should be short enough to accomplish time restrictions. - On the other side, the same station could arrive to one specific place (for example an office or home) so the user might prefer the full AP list, so it could choose to connect to the best one. > >> Would you expect these to always be specified, to the point where our >> driver no longer has any flexibility in adjusting things internally? > According to our studies there are not one pair of values that will be optimum in all the scenarios, these values depends on the network deployment and on the user (and the applications it is using). To get things more complicated, the optimum values might change from channel to channel. In summary, I would say that flexibility on the user-side it's really important. [...] >> 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 ;-). We have seen Probe Responses arriving after 300ms, although in a city center spontaneous deployment ~90% of the Probe Responses arrive before 50ms. Anyway, I would only suggest to check for positive values. Also, the values for max_chan_time does not have to be greater than min_chan_time (notice that in the standard max_chan_time starts after min_chan_time expires). It could be possible to have something like min_chan_time=8TU and min_chan_time=2TU. [...] Another questions: - What about IEEE80211_PROBE_DELAY (Probe Delay)? Why won't allow to adjust this value? I'm not sure about the definition/use of this delay. Could any of you help me with an explanation of this? - What would be a reasonable value? In an IEEE discussion I found a reference to 0.1ms but in the kernel it takes HZ/33 (~30ms), that is a lot bigger. Best regards, -- Laudin Alessandro Molina GPG fingerprint = DAE4 8A7F D5EE 48EE 60C7 F7BC 628F 18CA E307 2B89 -- 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
