| Message ID | 20140106075126.GA31046@w1.fi (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
On Tue, Jan 7, 2014 at 8:26 AM, Jouni Malinen <j@w1.fi> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org 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 <j@w1.fi>: > 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,
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 24, 2014 at 7:19 AM, Johannes Berg <johannes@sipsolutions.net> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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;
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 <j@w1.fi> --- include/net/cfg80211.h | 7 +++++++ include/uapi/linux/nl80211.h | 11 +++++++++++ net/wireless/nl80211.c | 14 ++++++++++++++ 3 files changed, 32 insertions(+)