Scanning and probe requests

[Ricardo Carrano]

Two things about probe requests from XOs:

1 - Analysis of traffic traces shows that XOs typically send probe requests
in pairs  (separated by 120ms).
2 - Analysis of kernel traces shows that typically scan commands are sent to
the firmware in groups of four (separated by 750ms).

Probe requests are relevant to us because they generate Probe responses
which grow squarely in a mesh and this is known to be one of the limiting
factors in its scalability.

The two items above are not necessarily bugs or mistakes. I believe they are
there for good reasons. But I find strange that:

- Once the scan command is sent to the firmware it takes about 450ms for the
driver to get a response, but scan commands are being prepared and queued
even after a successful scan result is returned, 300ms later.

- The fact that the interval between the two probe requests is shorter than
the interval between consecutive scan commands from the driver seem to
indicate that:
-- either two consecutive scans are getting buffered
-- or one single scan command will generate the two probe requests.
It may be the case that active scanning is being used after a passive
scanning returns nothing. But it seems there is no specific command for
passive or active scan in the kernel level. Is there?

It may be possible that NetworkManager is triggering the scannings (any
other possibility?). Anyway, why 4 scan commands and how this becomes 2
probe requests? Any ideas?

There is, of course, the discussion on the merits of keeping probe requests.
In case we keep them, it seems that we should use less of them.


-- 
Ricardo Carrano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080305/ead482d2/attachment.html>