On 10/18/2017 02:02 PM, Johannes Berg wrote:
On Wed, 2017-10-18 at 13:51 -0700, Ben Greear wrote:
"
I guess you could implement this part? I.e. iterating the clients and
checking that they all support the rate that is set. However, then you
also need to implement that this gets reset when a new client that
doesn't support this rate connects.
"
The first part seems OK, but the second seems like a pain. Maybe just
keep a new client from being able to connect at all if it doesn't support
any available rates?
I suppose if you reject the NEW_STATION command, then hostapd will
reject the association though, so it's probably not hard to do.
However, I'm not really sure why you'd want that? If you do want that
then basically you're just implemented a very roundabout way of adding
this rate to the basic rates, so you might as well just add it and work
with the current basic rates check?
If a user specifies a specific rate or rate-set, then I do not think we
should quietly change it out from under them. So, we could check at the
time the rate-set is applied (all current peers). We can reject the change
at that point if one of the peers does not support any common rates.
And, whenever a peer tries to be associated, we can check that there is some common rateset
in place. If there is no common rateset, then reject the association
one way or another.
We'll need to be a little careful what happens with client-mode
interfaces, which is where we actually observed hitting the WARN_ON()
about not having any rates at all, but I think I already put a reset of
the rates there anyway if they're not compatible with the AP. At least
that's easier because there's only one client.
It would be easy to configure a station to do VHT MCS 8 only, and then
it would never be able to associate with an HT AP, for instance. I don't
think this should be a WARN_ON event, just a failure. It would be great
if we could get a useful error message back to the caller, but I am not
sure how feasible that is with the current netlink and mac80211 code.
If your main concern is hitting a WARN_ON, maybe just change it to a
quieter error message or remove it entirely and just return a failure
code?
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
