On Mon, 2012-07-09 at 15:18 +0200, Antonio Quartulli wrote: > > So this is kinda broken. In fact, the whole basic rate thing is broken > > it seems. > > > > The mcast rate is per band, as it should, since you could find the same > > BSSID on a 5 GHz channel and then jump to that channel if the TSF is > > higher... > > > > However, the basic rates aren't, which is wrong: the basic rates bitmap > > could be 1,2,6,9. If the driver is like most drivers, that translates to > > a bitmap of 0x33. But 0x33, for most drivers, if applied to the 5 GHz > > rates means 6,9,24,36. See why this is broken? A rate bitmap can't be > > siwtched around between bands and still make any sense. > > I see, I wrongly thought that nl80211_parse_mcast_rate() was checking if the > provided mcast_rate belongs to the basic_rate set of the band which we are now. Well, ok, don't get confused -- there's no basic rate set "of the band", it's a BSS property. > But that's wrong! nl80211_parse_mcast_rate() only checks if the provided > mcast_rate exists somewhere... It checks that each rate exists in the band that it's for. > > Oh, also, I'm not sure why you do BIT(... -1), but that's unrelated. > > What kind of value is the mcast rate? A rate index, or a number? > > > > it's an index and actually it's the index +1, as reported in mac80211.h: > > * @mcast_rate: per-band multicast rate index + 1 (0: disabled) also in the cfg80211 API? johannes -- 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
