linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: rate mask resulting in no usable rates - WARN_ON
Date: Fri, 10 Mar 2017 07:48:10 -0800	[thread overview]
Message-ID: <58C2CABA.6070007@candelatech.com> (raw)
In-Reply-To: <1488955036.31187.1.camel@sipsolutions.net>

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

      reply	other threads:[~2017-03-10 15:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08  0:43 rate mask resulting in no usable rates - WARN_ON Johannes Berg
2017-03-08  1:13 ` Ben Greear
2017-03-08  6:37   ` Johannes Berg
2017-03-10 15:48     ` Ben Greear [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58C2CABA.6070007@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).