On Mon, 2009-05-18 at 15:43 +0200, Helmut Schaa wrote: > That's what I've tried with the patch at [1]. I used a fixed time schedule > for switching back to the operating channel after each scanned channel. > However, that could of course be done somewhat dynamic based on the current > traffic characteristics. Not sure there's a need -- we have plenty of time. > The basic problem I had was that I couldn't check if the nullfunc frame > indicating the new "powersave" state to the AP was already sent out (or > ACKed by the AP). This resulted in lost frames sometimes: if the device's > tx queue contained a lot of data frames the nullfunc frame was sent out > _after_ the channel switch occured. Indeed. > If anybody has a good idea on how to fix this issue I'm glad to provide an > updated version of the bg-scan patch. Hmmm. > One solution would be to force all drivers to report the tx status. Another > one would be to just wait until the device's queue is empty. At that point > we know that all pending data frames were sent out and additionally the > nullfunc frame was also sent out, so we can safely switch to the next > to-be-scanned channel. Some drivers now flush queues at channel switch time, but there's no way to guarantee that the software queues are actually empty and the nullfunc frame isn't queued up behind other traffic. Also, waiting for any driver to report a status will lead to problems because the driver might just have dropped the frame for various reasons like being out of memory. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
