Ben, all,
There are scenarios where setting a rate mask from userspace will
result in no usable rates, e.g. when you set a rate mask of 6,9,12
MBps, and the AP reports it only supports 36,48,54 (which some APs do).
This results in a WARN_ONCE() hitting since we can't find a usable
rate, and then we fall back to 1 or 6 MBps, which is a mandatory rate
but the AP didn't report it as supported (is it thus misbehaving?
doesn't matter much though)
I'd go and reject a setting that results in no usable rates, but
because the setting is sticky this is very complicated (it's a good
thing I insisted we have very few of these, but some I couldn't get
around).
Would there be any objection to making this setting non-sticky, i.e.
always resetting it for a new association? It's kinda designed to be
sticky, with the per-band setting, but clearly this is causing big
problems.
Alternatively, the really proper behaviour would be for this setting to
actually influence whether or not we can connect to the AP, but that
will just lead to massive problems because wpa_s will be unaware and
will pick APs that we can't support with the setting etc. Therefore I'm
not going to do this.
I could also reset the setting only when it would result in no usable
rates, but that doesn't even give userspace any good way at all to
predict it.
Is anyone - other than ChromeOS, which sets it just after association -
actually using this?
johannes
On 03/07/2017 04:43 PM, Johannes Berg wrote:
> Ben, all,
>
> There are scenarios where setting a rate mask from userspace will
> result in no usable rates, e.g. when you set a rate mask of 6,9,12
> MBps, and the AP reports it only supports 36,48,54 (which some APs do).
> This results in a WARN_ONCE() hitting since we can't find a usable
> rate, and then we fall back to 1 or 6 MBps, which is a mandatory rate
> but the AP didn't report it as supported (is it thus misbehaving?
> doesn't matter much though)
>
> I'd go and reject a setting that results in no usable rates, but
> because the setting is sticky this is very complicated (it's a good
> thing I insisted we have very few of these, but some I couldn't get
> around).
>
> Would there be any objection to making this setting non-sticky, i.e.
> always resetting it for a new association? It's kinda designed to be
> sticky, with the per-band setting, but clearly this is causing big
> problems.
>
> Alternatively, the really proper behaviour would be for this setting to
> actually influence whether or not we can connect to the AP, but that
> will just lead to massive problems because wpa_s will be unaware and
> will pick APs that we can't support with the setting etc. Therefore I'm
> not going to do this.
>
> I could also reset the setting only when it would result in no usable
> rates, but that doesn't even give userspace any good way at all to
> predict it.
>
> Is anyone - other than ChromeOS, which sets it just after association -
> actually using this?
I know several people who use this and depend on it being sticky. For that
matter, I think LEDE and probably OpenWRT uses 'iw' quite a bit to affect rates. I wrote
up some patches to help make this less sticky by allowing supplicant to specify
the (V)HT rates at connect time, but I am pretty sure those were not wanted
upstream at the time.
Personally, I'd prefer to be able to specify the advertised and allowed-tx-rates
at assoc time and drive it from supplicant.
For my needs, you need both advertised (like how the station presents itself)
as well as the rateset that you want to transmit with. That allows you to
configure your station to act like a /b station (advertise 1,2,...11Mbps), but only transmit on
1Mbps, for instance.
Nice thing about doing it in supplicant is that it has fairly good access to
the rates the AP is advertising...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 03/07/2017 10:37 PM, Johannes Berg wrote:
>
>>> Is anyone - other than ChromeOS, which sets it just after
>>> association - actually using this?
>>
>> I know several people who use this and depend on it being sticky.
>
> Do you know how they use it in more detail?
The goal would be to make a more capable station on a radio act like
something less, typically for testing purposes. Maybe limit to /a rates, for instance:
They do this before association, though they seem to also do it
after association to work around some bug or another, and API is slightly
different on newer kernels.
802.11 ac station :
iw dev vif0 set bitrates legacy-2.4 legacy-5 6 9 12 18 24 36 48 54 ht-mcs-5 vht-mcs-5 3:9
802.11 n (2.4G):
iw dev vif1 set bitrates legacy-2.4 ht-mcs-2.4 23
802.11 b:
iw dev vif2 set bitrates legacy-2.4 11 legacy-5 ht-mcs-2.4 vht-mcs-5 ( setting 1 , 2 , 5.5 .. is not working)
802.11 g:
iw dev vif3 set bitrates legacy-2.4 54 legacy-5 ht-mcs-2.4 vht-mcs-5 (setting 1 2 6 ... is not working)
802.11 a:
iw dev vif0_7962 set bitrates legacy-2.4 legacy-5 6 9 12 18 24 36 48 54 ht-mcs-5 vht-mcs-5
>
>> For that matter, I think LEDE and probably OpenWRT uses 'iw' quite a
>> bit to affect rates.
>
> That seems odd, but ok.
>
> Either way, if people do rely on it being sticky then I'll do the next
> best thing and just clear the mask when detecting a situation where it
> would result in no usable rates, as well as rejecting it when it's
> already known that it would do so.
I just briefly looked at related code in LEDE while debugging something
else, so I might be confused about it. In particular, if you try to set
up a VHT40 IBSS network, then it ends up configuring an HT40 one since there
is no valid API (that I know of) to configure an IBSS station for VHT40 (VHT80 works fine).
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
> > Is anyone - other than ChromeOS, which sets it just after
> > association - actually using this?
>
> I know several people who use this and depend on it being sticky.
Do you know how they use it in more detail?
> For that matter, I think LEDE and probably OpenWRT uses 'iw' quite a
> bit to affect rates.
That seems odd, but ok.
Either way, if people do rely on it being sticky then I'll do the next
best thing and just clear the mask when detecting a situation where it
would result in no usable rates, as well as rejecting it when it's
already known that it would do so.
johannes