On 01/26/2016 03:16 AM, Johannes Berg wrote:
On Tue, 2015-10-20 at 10:24 -0700, greearb@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
