On Wed, Apr 15, 2015 at 02:01:44AM -0700, Amitkumar Karwar wrote: > Hi James, > > > > > On Tue, Apr 14, 2015 at 07:49:16AM -0700, Amitkumar Karwar wrote: > > > It's been observed that device sometimes fails to find AP configured > > > in hidden SSID in busy environment. We will increase number of probes > > > for specific SSID scans for getting better results. > > > > I don't like this. It worries me. What is the underlying cause? If it > > is something other than collision, why? > > > > Idea was to have better chance of finding an AP configured with > hidden SSID when environment is busy by sending multiple probe > requests. Yes, I understand the intention, but I don't understand why busy environment should cause missed probe response from hidden SSID AP. Speculating ... Have you tested this? Are you sure the probe request is being sent when the channel is clear? Are collisions detected? Is recovery from collision correct? Are you sure it isn't caused by scan results being too large in busy environment? Is scan for specific SSID given priority in scan results, by firmware? I ask because I'm curious; perhaps there is something else happening to cause scan failure. I have reports of scan failure with mwifiex, with 8686 and 8787, but I've not been able to prove the cause of the problem, because of high complexity of testing. Customer usually unwilling to go into depth. > > In scenario of tens to a hundred laptops scanning for specific SSID for > > ad-hoc in the Sugar desktop environment, this patch may decrease free > > air time considerably. > > You are right. Free air time will be decreased. We have discarded > this approach considering its consequences. > > > > > Should the number of probes be a choice of user space? > > > > Do you see any potential use case for multiple probe requests? No use case that doesn't risk interference. I've used it in diagnosis, and in Open Firmware driver. > I think, we should stick to current implementation of sending 1 > probe request. That's fine. > Regards, > Amitkumar -- James Cameron http://quozl.linux.org.au/ -- 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
