On Thu, 2010-10-07 at 10:21 -0700, Luis R. Rodriguez wrote: > > But then again, come to think of it, why are you doing this anyway? > > The goal is to clean up a lot of stuff we forgot to cleanup for > offchannel operation and in the end to help with multicast/broadcast > data. This patch just addresses one of the cleanups. The timers kicked > off when going off channel will not make sense, so best to just deny > ADDBA when going offchannel. But this won't actually help in that case -- this problem happens if try to make a BA just before we go offchannel, and then the timer fires while we're offchannel. It'll just *very* slightly alter the timing required to hit it. > > I'm not convinced of the whole idea, it's all racy. I'm starting to think > > that this patch won't help anything since we'll still be racy and start > > BA agreements just before we block, > > Establishing the BA agreement is fine, we don't want to cancel > existing BA agreements when going offchannel, we just want to prevent > making the timers for new ADDBA requests from going stale > unnecessarily. See above though. > > _and_ if we're a station and going off-channel we'll be going into powersave > > which means we won't actually get the addBA frame until we return. > > There's a race between trying to go offchannel, sending the nullfunc > and switching channels. When the race hits the ADDBA timer will just > go stale. If our goal is to go offchannel we should avoid the race by > simply denying new ADDBA requests. I just noticed that we can't > possible receive ADDBA requests when we are scanning though, since > ieee80211_iface_work() already has a check and bail out for > local->scanning, but note that local->scanning will not be checked > when doing other offchannel work. > > So perhaps there is another way we can deal with this for the > non-scanning offchannel work case that might also take care of not > handling other queued up management frames when offchannel. I think we need to treat TX and RX BA differently. For TX BA, the best idea would probably be to actually make it _use_ the work infrastructure -- after we change that to not actually stop all the things it's doing when the channel is the operating channel, or so. 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
