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.
Signed-off-by: Jouni Malinen <[email protected]>
---
include/net/cfg80211.h | 7 +++++++
include/uapi/linux/nl80211.h | 11 +++++++++++
net/wireless/nl80211.c | 14 ++++++++++++++
3 files changed, 32 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8b5777a..3553c3a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1367,6 +1367,11 @@ struct cfg80211_ssid {
* @aborted: (internal) scan request was notified as aborted
* @notified: (internal) scan request was notified as done or aborted
* @no_cck: used to send probe requests at non CCK rate in 2GHz band
+ * @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
*/
struct cfg80211_scan_request {
struct cfg80211_ssid *ssids;
@@ -1376,6 +1381,8 @@ struct cfg80211_scan_request {
const u8 *ie;
size_t ie_len;
u32 flags;
+ unsigned int min_chan_time;
+ unsigned int max_chan_time;
u32 rates[IEEE80211_NUM_BANDS];
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index e57de33..86b8888 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1568,6 +1568,14 @@ enum nl80211_commands {
* @NL80211_ATTR_MAC_HINT: MAC address recommendation as initial BSS
* @NL80211_ATTR_WIPHY_FREQ_HINT: frequency of the recommended initial BSS
*
+ * @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.
+ * @NL80211_ATTR_MAX_CHANNEL_TIME: MaxChannelTime - Maximum time (in TU) to
+ * spend on each channel when scanning (used for both active and passive
+ * scans). If not included, the driver will use its default value. u32
+ * attribute.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1899,6 +1907,9 @@ enum nl80211_attrs {
NL80211_ATTR_MAC_HINT,
NL80211_ATTR_WIPHY_FREQ_HINT,
+ NL80211_ATTR_MIN_CHANNEL_TIME,
+ NL80211_ATTR_MAX_CHANNEL_TIME,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a3a6fb7..caf2829 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -386,6 +386,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
.len = IEEE80211_QOS_MAP_LEN_MAX },
[NL80211_ATTR_MAC_HINT] = { .len = ETH_ALEN },
[NL80211_ATTR_WIPHY_FREQ] = { .type = NLA_U32 },
+ [NL80211_ATTR_MIN_CHANNEL_TIME] = { .type = NLA_U32 },
+ [NL80211_ATTR_MAX_CHANNEL_TIME] = { .type = NLA_U32 },
};
/* policy for the key attributes */
@@ -5443,6 +5445,18 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
+ if (info->attrs[NL80211_ATTR_MIN_CHANNEL_TIME])
+ request->min_chan_time = nla_get_u32(
+ info->attrs[NL80211_ATTR_MIN_CHANNEL_TIME]);
+ if (info->attrs[NL80211_ATTR_MAX_CHANNEL_TIME])
+ request->max_chan_time = nla_get_u32(
+ info->attrs[NL80211_ATTR_MAX_CHANNEL_TIME]);
+ if (request->max_chan_time &&
+ request->max_chan_time < request->min_chan_time) {
+ err = -EINVAL;
+ goto out_free;
+ }
+
request->wdev = wdev;
request->wiphy = &rdev->wiphy;
request->scan_start = jiffies;
--
1.7.9.5
--
Jouni Malinen PGP id EFC895FA
On Tue, Jan 7, 2014 at 8:26 AM, Jouni Malinen <[email protected]> wrote:
>
> 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.
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.
- 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).
For my part, I don't care to define the exact parameters (dwell time, etc)
as much as I'd prefer that these concerns be conveyed in a way that the
driver can make effective decisions as to what type of scan should be
performed. Of course this leads to a set of complex decisions in userspace
as to how to interpret the scan results -- wpa_supplicant has logic for
removing a BSS if it was not present for some number of scans -- that
heuristic won't hold true if the scan was not necessarily complete.
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]>:
> 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
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
On Thu, 2014-01-09 at 17:23 +0100, Laudin Alessandro Molina T wrote:
> 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.
I'm not convinced that the completeness of the scan list would be the
main concern here. Additionally, it will be difficult for anyone to tell
whether the device is moving or not. I think for this particular use
case, trying to adjust dwell times is probably not a good idea. Having
some form of continuous background scan, so a roaming candidate is
always available, would probably be a better solution to the first
scenario.
As far as the second scenario goes, the user is probably not connected
anyway, and in that case most devices/drivers wouldn't really be
concerned with traffic (which usually drives optimisations.)
> > 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.
300ms is far too long for that AP to be useful at all, most likely :)
> 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?
We don't have proper CCA in software scans, so this is needed. It's
fairly implicit in the standard, but you can find it (somewhere)
johannes
On Tue, 2014-01-07 at 18:26 +0200, Jouni Malinen wrote:
> 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.
Right, I know they're included there, was mostly wondering about the
particular cases that would use it.
Are we OK with these things then completely killing any optimisation,
and in fact drivers being allowed to refuse the scan? Or should the
driver in that case ignore the parameters? Similarly, what should happen
if the driver doesn't (want to) support these parameters at all?
I think the answers to these questions should also be captured in the
nl80211 documentation (and possibly code, if there needs to be a feature
flag etc.)
> 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.
Right, those are useful, but that's pretty much orthogonal to this
issue. I'd welcome patches for all of these.
> > 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.
Ok.
> > > + * @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.
Ok.
> > 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 ;-).
Heh :)
> 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.
Hmm. That particular use case ("take less time") doesn't seem very well
defined. Do you mean while already associated? If so, then this could
also be interpreted to mean "I don't care about data traffic much, just
quickly scan everything". Or I guess you more meant it to mean "I care
only about APs that are fast enough", or something similar ...
I'm not totally against this idea, but I think blindly adding the values
isn't a good idea. Some drivers/devices may do some optimisations on
their own without losing much "accuracy" and specifying dwell times
might disable those. So I'd say that at least we should specify that
'normal' scans (for some value of normal) shouldn't be using these
parameters?
johannes
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?
Would you expect these to always be specified, to the point where our
driver no longer has any flexibility in adjusting things internally?
> + * @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
> + * @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?
> + if (info->attrs[NL80211_ATTR_MIN_CHANNEL_TIME])
> + request->min_chan_time = nla_get_u32(
> + info->attrs[NL80211_ATTR_MIN_CHANNEL_TIME]);
> + if (info->attrs[NL80211_ATTR_MAX_CHANNEL_TIME])
> + request->max_chan_time = nla_get_u32(
> + info->attrs[NL80211_ATTR_MAX_CHANNEL_TIME]);
> + if (request->max_chan_time &&
> + request->max_chan_time < request->min_chan_time) {
> + err = -EINVAL;
> + goto out_free;
> + }
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.
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.
johannes
On Fri, Jan 24, 2014 at 7:19 AM, Johannes Berg
<[email protected]> wrote:
>
> 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?
Off the top of my head, I suppose one could devise a heuristic based
on the ratio of beacons to probe-responses received on channel. Also,
some drivers support the "channel busy time" or some such measure in
the survey results.
>
>
> johannes
>
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