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

<br>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.<br><br>The two items above are not necessarily bugs or mistakes. I believe they are there for good reasons. But I find strange that:<br>

<br>- 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.<br>
<br>- 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:<br>
-- either two consecutive scans are getting buffered<br>-- or one single scan command will generate the two probe requests.<br>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?<br>
<br>
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?<br><br>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.<br>
<br><br>-- <br>Ricardo Carrano<br><br><br><br><br>