[adding Jouni] On Thu, 2010-01-21 at 13:39 -0800, wey-yi.w.guy@xxxxxxxxx wrote: > From: Wey-Yi Guy <wey-yi.w.guy@xxxxxxxxx> > > 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:
signature.asc
Description: This is a digitally signed message part
