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.. -- Jouni Malinen PGP id EFC895FA -- 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
