Re: [PATCH v2 2/3] mac80211: wait until completely disassociated before new association

[Johannes Berg <johannes@sipsolutions.net>]

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.

> 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?

> > > 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, 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.

johannes