On Mon, 2010-01-25 at 12:11 -0800, Johannes Berg wrote: > On Mon, 2010-01-25 at 10:35 -0800, Jouni Malinen wrote: > > On Fri, Jan 22, 2010 at 08:03:01PM +0100, Johannes Berg wrote: > > > 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. > > > > I'm somewhat concerned about this as an unconditional change for our > > association process due to the extra latency it adds. At minimum, I > > would like to see a driver flag that can be used to indicate that such > > behavior is really required and skip the extra wait if the driver does > > not need the Beacon frame before association. > > > > For most cases, I would also assume it should be possible to update the > > PS settings after having received the first Beacon frame after > > association, but if that is not enough, allowing the driver to request > > mac80211 to wait with association sounds reasonable. I just don't want > > to see additional 50 msec or so (or much worse if the AP is configured > > with insanely long beacon interval) delay popping up with every > > association by default.. > > Yeah that's a good point, I wondered about that too. I'll look into this > in more detail and see if we can tell the driver about the DTIM period > only with CONF_PS and enable that only after a beacon. > I really like the idea of using CONF_PS which will not cause any delay for association, plus the only STA need to know DTIM is the station in power save mode. -- 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
