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 [off-list ref]:

On Tue, Jan 07, 2014 at 04:59:47PM +0100, Johannes Berg wrote:

quoted

On Mon, 2014-01-06 at 09:51 +0200, Jouni Malinen wrote:

quoted

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.

quoted

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.

[...]

quoted

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