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

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

On Mon, Oct 04, 2010 at 09:39:52AM -0700, Johannes Berg wrote:
> On Mon, 2010-10-04 at 09:36 -0700, Luis R. Rodriguez wrote:
> 
> > > > +wait:
> > > >  	wk->timeout = jiffies + IEEE80211_ASSOC_TIMEOUT;
> > > >  	run_again(local, wk->timeout);
> > > 
> > > But you'll be staying off-channel for the wait period, so what does this
> > > really help?
> > 
> > I totally missed this what locks us offchannel here, I though we just re-arm
> > the timer, and come back offchannel at a later time. What is it that locks
> > us offchannel until the timer runs again?
> 
> I believe we stay off-channel as long as the work item is active, after
> it has been activated, no?

Well I don't see that, the problem here was the assumption that within a work
item we can try to transmit a frame for our home channel without changing it.
If that is desired we must move back to the home channel as I did, but I can
see how we'd need more work than what I did, we'd need to start the queues,
get out of PS state with the AP and then TX... unless TX already handles
that for us.

ieee80211_work_work() just iterates over all work items, and then bails out.
The work loop is protected against local->mtx, and if we call work_work
when we either add new work, purge work, or hit a timer. We *try* to prevent
frames from being sent on the home channel by calling
ieee80211_offchannel_stop_station() but notice how we only stop the queues
for NL80211_IFTYPE_STATION interfaces.

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.

  Luis