On Fri, 2010-01-22 at 16:23 -0800, Luis R. Rodriguez wrote: > On Fri, Jan 22, 2010 at 4:11 PM, Guy, Wey-Yi <wey-yi.w.guy@xxxxxxxxx> wrote: > > On Fri, 2010-01-22 at 15:44 -0800, Luis R. Rodriguez wrote: > >> On Fri, Jan 22, 2010 at 11:46 AM, Johannes Berg > >> <johannes@xxxxxxxxxxxxxxxx> wrote: > >> > 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, > >> > >> OK -- Wey, can you elaborate a little as to how you found this and > >> what you were seeing? Does the device not go into PS mode at all? > > > > We are doing Power consumption test with different DTIM value, the test > > is based on test scripts, so we disable the NetworkManager to make sure > > we can control which AP we need to associated with. During the test, we > > notice when AP change it DTIM value, a lot time STA will used the old > > DTIM value in Power Save mode which cause problem. > > Ah I see. What if there was no old dtim value before? I am not sure, I believe the default is "1", but I might be wrong > > > We believe the correct fix is mac80211 should wait for both probe > > response and beacon arrived before start the association process. > > > > Hope this explain what we found. > > Indeed, thanks a lot. > > Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
