On Fri, Jan 22, 2010 at 3:44 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> 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? > BTW I ask more details because I'm trying to determine if this would be a stable fix or not. 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
