Re: [PATCH v3 1/1] mac80211: tell driver when dtim change detected

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

[adding Jouni]

On Thu, 2010-01-21 at 13:39 -0800, wey-yi.w.guy@intel.com wrote:
> From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> 
> In current implementation, mac80211 send dtim_period update to driver
> during association, but if no NetworkManager or similar application
> perform scan operation, plus tim_ie is not part of probe response; mac80211 will
> not get beacon with dtim information later, then  mac80211 will not pass the
> information to driver for update.
> 
> Call ieee80211_hw_config() with IEEE80211_CONF_CHANGE_PS flag set to
> allow driver make correct dtim adjustment if dtim_period change
> detected. Also perform recalc_ps operation if needed.

This seems fine.

However, I think it's indicative of a bigger problem. I gave it some
thought, and came to the conclusion that it previously didn't happen
because we always won the race. Let me explain.

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.

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.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]