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

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

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