Search Linux Wireless

Re: [PATCHv2] nl/cfg/mac80211: add set_mcast_rate API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 09, 2012 at 03:12:31PM +0200, Johannes Berg wrote:
> On Mon, 2012-07-09 at 15:05 +0200, Johannes Berg wrote:
> > On Mon, 2012-07-09 at 01:51 +0200, Antonio Quartulli wrote:
> > 
> > > +static int ieee80211_set_mcast_rate(struct wiphy *wiphy, struct net_device *dev,
> > > +				    int mcast_rate[IEEE80211_NUM_BANDS])
> > > +{
> > > +	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> > > +	u32 basic_rates = sdata->vif.bss_conf.basic_rates;
> > > +	int i;
> > > +
> > > +	/* check if the mcast_rates are also in basic_rates */
> > > +	for (i = 0; i < IEEE80211_NUM_BANDS; i++)
> > > +		if (!(basic_rates & BIT(mcast_rate[i] - 1)))
> > > +			return -EINVAL;
> > 
> > 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.
> 
> Ok actually maybe it's not broken. We adopt the basic rates from the
> network we join, I guess, and the original basic rates specified from
> userspace are only used when we actually *create* the network?

mhmm.. I have to check

> 
> Still though, comparing the bits for all bands against the same bitmap
> like you did in the above code is just wrong :-)
> 

right, I should select the BAND which we are using and check that index only.

> Maybe we shouldn't bother at all. If we'd join another network, we might
> have to downgrade the mcast rate, but then if some peer leaves or we
> join another one ... it gets messy quickly.
> 

it's adhoc! :-)


> Since all of this is probably for special cases anyway, maybe we should
> just not check the mcast rate and if you set a stupid one you don't get
> packets through to all peers? Could be hard to debug though ...

definitely hard.
we should keep the intersection of all the rates we have seen and chose the one
set by the user if possible or the highest mandatory we have in our set. Sounds
too easy :-)




-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

Attachment: pgpLByQYtEYfb.pgp
Description: PGP signature


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux