Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Ben Greear <greearb@candelatech.com>]

On 01/26/2016 03:16 AM, Johannes Berg wrote:
> On Tue, 2015-10-20 at 10:24 -0700, greearb@candelatech.com wrote:
>
>> --- a/include/uapi/linux/nl80211.h
>> +++ b/include/uapi/linux/nl80211.h
>> @@ -2130,6 +2130,8 @@ enum nl80211_attrs {
>>
>>   	NL80211_ATTR_REG_INDOOR,
>>
>> +	NL80211_ATTR_TX_ADVERT_RATEMASK,
>
> First of all, this is missing documentation. It's a FLAG as far as I
> can tell, but if it's set should it affect only the advertised or both?
>
> I also think you added this because I had commented that we might not
> want to do it unconditionally, but is there really a good reason not to
> do it unconditionally? I was probably more thinking out loud what would
> happen with P2P, but there we already say "no cck" for scanning so it
> shouldn't really have any effect.

Turns out, I did want this flag.  The reason is that I might want to
advertise as a normal-ish /g station (ie, full /b/g rateset), but
actually fix the TX rate as 24Mbps (or whatever).

So, I do need a way to set an advertise ratemask vs a tx-rate-mask.

With my current patch, and my patches to supplicant, it seems to at least
mostly do what I want, but there is a user-space issue where if you set the ADVERT_RATEMASK
on kernels that do not support that flag, it will just set the tx rates instead.  Not
the end of the world, but possibly there needs to be a feature flag
that user-space could query for this feature.

> But given that we have NL80211_ATTR_SCAN_SUPP_RATES, where does your
> patch even have an effect, other than this not handling HT/VHT?
>
> I'm a bit wary that we're introducing two ways of achieving a very
> similar thing.
>
> Also, adding these overrides all over the code seems very complex.
> Perhaps we can achieve the goal of being able to pretend to have
> limited hardware capabilities by actually restricting hardware
> capabilities instead? That would also avoid having to play whack-a-mole
> with code paths using the device capabilities.
>
> I'd imagine an API along the lines of doing some kind of higher-layer
> re-register of the wiphy in mac80211 with limited capabilites. At that
> point you'd allocate a copy of the original capabilities (as far as the
> new restricted ones overwrite the data), and remove the device from the
> system as far as higher layers like cfg80211 are concerned.
>
> Would something like that work for you?

As far as I can tell, that will not work, because I want to have multiple station devices
per radio, and have each of them be able to use a different configuration.  So,
one station may be /g, and another /n and another /AC.  Same with APs.  In addition,
some stations may want to use all available rates for their mode,
and others may want to use a fixed rate or subset of available rates.

Thanks,
Ben

>
> johannes
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com