On Tue, Oct 05, 2010 at 12:59:42AM -0700, Johannes Berg wrote: > On Mon, 2010-10-04 at 13:55 -0700, Luis R. Rodriguez wrote: > > > > We don't need to go out of PS state to just TX, but we'd need to be > > > careful to TX with asleep bit. > > > > I got what you meant here. > > > > > That said, we don't TX data frames then. > > > > But not here. Right now I am going to assume that we actually are > > transmitting some frames for the delba when we try to tear down > > the BA agreements with the old AP and the new AP are on the > > same band, we just likely transmit it on the wrong channel. > > Yes, but delBA aren't data frames. The queue stop etc. doesn't pertain > to them. Got it. > > Ah and also we did call ieee80211_offchannel_stop_beaconing() prior > > to processing work_work stuff so that should take care of stopping > > beaconing but that also turns off all TX queues... so yeah you're > > right. The race here was just within work items assuming they can > > transmit on other channels than the wk->chan. > > Did any work item actually assume that? Except maybe for your patch 1 in > this set? So far I just see the assoc request doing that. > > > > Also this seems buggy, we do not take into consideration how much offchannel > > > > work we are doing in consideration against the current AP's DTIM interval as > > > > we do when going offchannel for scan work. We should merge that code for > > > > this offchannel work_work loop. > > > > > > True, we don't do _any_ timing here. > > > > We can resolve that later, I'll add that to the TODO list. > > Come to think of it -- some p2p stuff in the supplicant might time out > if we do this, Its no different than the case of a DTIM 1 case when we do bgscan and need to scan through some passive scan channels. > I think we need to cut the drivers/mac80211 some more > slack in the supplicant and not assume the remain-on-channel will start > quickly. Not sure I follow, do you mean that as per API we want to document offchannel operation may loose broadcast/multicast data frames? Luis -- 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
