On 11/02/2011 01:13 AM, Johannes Berg wrote:
On Fri, 2011-10-28 at 09:33 -0700, Ben Greear wrote:
* Allow configuring the mcs (/n) rates available.
* Allow configuration of MAX-A-MSDU
* Allow configuration of A-MPDU factor& density.
Users can only remove existing rates. The MSDU and MPDU
values can be set to any value allowed by the 802.11n
specification.
That can't work -- the device might not support it.
The device would always support removing rates, right?
No. As I pointed out in another email, you need to think beyond
mac80211.
As for the MSDU and MPDU stuff, I would need to add capabilities
flags and then enable each driver as they are tested?
No. Neither of these can ever be increased so it's not that simple. And
making it smaller is always possible since it's just advertising.
Presumably you do understand the reasons for this advertising/these
restrictions?
It seems that a driver might default to a mid-range value for the MPDU values
because it is somehow 'better' for whatever reason, and yet it might still
support larger values if the user desires, perhaps because in specific
scenarios larger values are better. Ath9k does set to the max value,
so if we do a per-driver capabilities flag as I did in v2 then we
are safe.
I also don't really like the way you pass in some binary "mask" when
it's not really a binary masking operation.
I found the mask to work very well. It's easy enough to
deal with in user-space, and easily allows us to add override features
(the additional bits to support the MPDU stuff once the
HT rates logic was in is a very small bit of code).
Otherwise, I'll need to add new netlink commands for each new
feature. That is going to bloat hostapd as well as the
kernel.
I'm not sure it'll bloat it, but I can live with the binary struct. It
seems a bit ugly to me but I think it's acceptable. However, you should
document more clearly what struct it is and how it is defined to work.
You're also relying on userspace to not do stupid things (otherwise your
code reads memory out of bounds), this would help:
/* add attributes here, update the policy in nl80211.c */
I copied some of that code from nl80211_set_station, which appears to
also forget to check the length for the NL80211_ATTR_HT_CAPABILITY
object. Is there some reason why it doesn't need to check, or does
that code need fixing as well?
Anyway, I'm out of breath. I think this is simply bad implementation&
execution of your ideas. These are somewhat interesting features and I'm
willing to accommodate even some of the more esoteric features that most
people will never use, but I'm quite annoyed by how much of your patches
I end up doing myself through review.
Please focus more on the quality of your patches in "details" like
security, API issues, non-mac80211 drivers and even simply logic like
the A-MSDU thing I just pointed out. I'm spending a disproportionate
amount of time reviewing your patches over and over again with every
patchset and am no longer willing to do that.
I listed several thinks that could be changed in the patch description,
and your comment was:
That can't work -- the device might not support it.
Now, how am I supposed to know what you are talking about?
Obviously we'll still have to discuss things like whether it should be a
connection or interface parameter -- but I shouldn't have to point out
trivial security issues -- you should be focusing more on these things
while writing the code, not after the fact where it's much harder. E.g.
never ever use nla_data() without validating nla_len() in some way, it
seems to me that should be completely obvious.
Well, it's more obvious now. Do you also need to check the length when
doing code like this code from nl80211_set_station:
if (info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL])
params.listen_interval =
nla_get_u16(info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL]);
In other words, is it safe to assume you have 16 bits, or could a broken
user-space pass in a single byte and screw this up?
+ memcpy(&ht_cap,&sband->ht_cap, sizeof(ht_cap));
+ /*
+ * This is for an association attempt, and we must
+ * advert at least the first 8 rates, even if we
+ * will later force the rate control to a lower rate.
+ */
+ ieee80211_apply_htcap_overrides(sdata,&ht_cap, 8);
Yuck, why, why hard-code 8, etc.
I can make a define that involves MCS7.
I don't think I understand then why MCSs 0-7 must be supported?
From 20.1.1 of the 802.11n spec:
"An HT non-AP STA shall support all equal modulation (EQM) rates for one spatial stream (MCSs 0 through
7) using 20 MHz channel width. An HT AP shall support all EQM rates for one and two spatial streams
(MCSs 0 through 15) using 20 MHz channel width."
That is why I wrote that code as I did, but perhaps I misunderstand that section of
the docs.
Thanks,
Ben
--
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
