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.
Signed-off-by: Amitkumar Karwar <[email protected]>
Signed-off-by: Avinash Patil <[email protected]>
---
drivers/net/wireless/mwifiex/cfg80211.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index bf9020f..3783db5 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2269,6 +2269,12 @@ mwifiex_cfg80211_scan(struct wiphy *wiphy,
user_scan_cfg->num_ssids = request->n_ssids;
user_scan_cfg->ssid_list = request->ssids;
+ /* Increase number of probes for specific SSID scans for
+ * better results
+ */
+ if (request->n_ssids > 1)
+ user_scan_cfg->num_probes = 4;
+
if (request->ie && request->ie_len) {
offset = 0;
for (i = 0; i < MWIFIEX_MAX_VSIE_NUM; i++) {
--
1.8.1.4
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/
SGkgSm9oYW5uZXMsDQoNCj4gPiBPbiBUdWUsIDIwMTUtMDQtMTQgYXQgMDc6NDkgLTA3MDAsIEFt
aXRrdW1hciBLYXJ3YXIgd3JvdGU6DQo+ID4gSXQncyBiZWVuIG9ic2VydmVkIHRoYXQgZGV2aWNl
IHNvbWV0aW1lcyBmYWlscyB0byBmaW5kIEFQIGNvbmZpZ3VyZWQNCj4gPiBpbiBoaWRkZW4gU1NJ
RCBpbiBidXN5IGVudmlyb25tZW50LiBXZSB3aWxsIGluY3JlYXNlIG51bWJlciBvZiBwcm9iZXMN
Cj4gPiBmb3Igc3BlY2lmaWMgU1NJRCBzY2FucyBmb3IgZ2V0dGluZyBiZXR0ZXIgcmVzdWx0cy4N
Cj4gDQo+IEkgcXVlc3Rpb24gdGhlIHZhbHVlIG9mIG1ha2luZyB0aGUgImJ1c3kgZW52aXJvbm1l
bnQiIGV2ZW4gbW9yZSBidXN5IGJ5DQo+IHNlbmRpbmcgYSBsb3Qgb2YgcHJvYmUgcmVxdWVzdHMg
YXQgbG93IHJhdGVzIC4uLg0KPiANCj4gU2NhbnMgYXJlIG5ldmVyIHJlYWxseSBndWFyYW50ZWVk
IHRvIGJlIHBlcmZlY3QgYW5kIGNvbXBsZXRlIGFueXdheS4NCj4gDQo+IFRoaXMgaXMgY2xlYXJs
eSB5b3VyIGNob2ljZSwgYnV0IGdpdmVuLCBhbW9uZyBvdGhlciB0aGluZ3MsIHRoZSBicm9hZGVy
DQo+IGluZHVzdHJ5IGRpcmVjdGlvbiBvZiBtb3ZpbmcgYXdheSBmcm9tIGFjdGl2ZSBzY2Fubmlu
ZyB0aGlzIHNlZW1zIGxpa2UgYQ0KPiBiaXQgc2hvcnQtc2lnaHRlZCB0aGluZyB0byBkby4NCg0K
SSBhZ3JlZS4gTXVsdGlwbGUgcHJvYmVzIHdvdWxkIG1ha2UgYW4gZW52aXJvbm1lbnQgZXZlbiBt
b3JlIGJ1c3kuDQpXZSB3aWxsIGRyb3AgdGhpcyBwYXRjaC4NCg0KUmVnYXJkcywNCkFtaXRrdW1h
cg0K
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
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
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/