From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless <linux-wireless@vger.kernel.org>
Cc: Ben Greear <greearb@candelatech.com>
Subject: rate mask resulting in no usable rates - WARN_ON
Date: Wed, 08 Mar 2017 01:43:31 +0100 [thread overview]
Message-ID: <1488933811.4723.1.camel@sipsolutions.net> (raw)
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
next reply other threads:[~2017-03-08 0:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 0:43 Johannes Berg [this message]
2017-03-08 1:13 ` rate mask resulting in no usable rates - WARN_ON Ben Greear
2017-03-08 6:37 ` Johannes Berg
2017-03-10 15:48 ` Ben Greear
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=1488933811.4723.1.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=greearb@candelatech.com \
--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).