On Fri, 2010-01-22 at 11:20 -0800, Luis R. Rodriguez wrote:

> > Previously, we would switch the channel completely to the new operating
> > channel before even probing the AP. That way, we would virtually always
> > receive a beacon from the new AP between the time we started the
> > association process (probe,auth,assoc) and configuring the driver.
> >
> > Now with the new changes that use the off-channel work, we may return to
> > the old "operating" channel, which may be no particular channel, between
> > all these steps. Thus, if there's no beacon between any of probe
> > request/response, auth "request"/"response", assoc request/response, we
> > never get one, and this situation happens.
> >
> > I see two solutions, apart from this special-case patch fixing
> >
> > First, we could go back to the original behaviour if we have just one
> > virtual interface. But that still leaves us with the race, we might do
> > all three frame exchanges within a beacon interval and still miss the
> > beacon, we just tend to not do that and get a beacon.
> 
> Curious, what symptoms were seen when the dtim was not propagated
> prior to association, did the STA just not wake up for the right dtim
> interval when in PS mode? 

Yes, I don't really know exactly what happens, but if you look at
Wey-Yi's patch you'll see most of the problem was that we calculated the
maximum powersaving interval wrong.

> Wouldn't we get the dtim interval on
> eventual beacons later or do we disregard all that information after
> associated?

As you can see from the patch, we currently disregard any "update" in
that information -- this patch changes it.

> If so what if the AP changes the dtim interval?

I believe the AP is not allowed to do that without turning off and back
on completely.

> I take it this can easily be reproduced with a long beacon interval?

Easier, yes. The easiest way to reproduce it is to associate using just
"iw", no NM or wpa_supplicant -- make sure the scan list is empty before
you associate -- and with a long beacon interval. We then scan, but that
will only give us a probe response with high probability, and then we do
all the switching as I explained and we don't ever get a beacon. If you
use NM it may scan more often and increase the probability of us having
a beacon at some point in time.

> > The other solution I see is that we add a new step before or after the
> > direct probe step, which would just be "wait for a beacon". This would
> > ensure we have both probe and beacon information always ready. It would
> > also ensure we have both probe and beacon info for our new userspace
> > reporting of that.
> 
> This seems cleaner.

I agree. And since we already keep track of this since 34a6eddb, we
should be able to fairly easily determine whether we still need probe
response or beacon, and only do either the direct probe or wait for
beacon step.

johannes