Search Linux Wireless

Re: [RFC 2/3] cfg80211: MinChannelTime and MaxChannelTime for scan requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux