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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
