RE: [PATCH] mwifiex: increase number of probes for specific SSID scans
Hi Johannes,
On Tue, 2015-04-14 at 07:49 -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 question the value of making the busy environment even more busy by
sending a lot of probe requests at low rates ...
Scans are never really guaranteed to be perfect and complete anyway.
This is clearly your choice, but given, among other things, the broader
industry direction of moving away from active scanning this seems like a
bit short-sighted thing to do.
I agree. Multiple probes would make an environment even more busy.
We will drop this patch.
Regards,
Amitkumar
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH] mwifiex: increase number of probes for specific SSID scans
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. 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? I think, we should stick to current implementation of sending 1 probe request. Regards, Amitkumar -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mwifiex: increase number of probes for specific SSID scans
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mwifiex: increase number of probes for specific SSID scans
On Tue, 2015-04-14 at 07:49 -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 question the value of making the busy environment even more busy by sending a lot of probe requests at low rates ... Scans are never really guaranteed to be perfect and complete anyway. This is clearly your choice, but given, among other things, the broader industry direction of moving away from active scanning this seems like a bit short-sighted thing to do. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mwifiex: increase number of probes for specific SSID scans
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? 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. Should the number of probes be a choice of user space? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
