On Thu, 2015-11-05 at 08:01 -0800, Ben Greear wrote: > My issue is that APs can be set to beacon at longer beacon times, and > then passive scanning at ~110ms intervals is not going to find the APs > very often (and with bad luck, technically it could *never* find the AP > due to scanning at unlucky periodic intervals). Which is probably why hardly anyone ever uses longer beacon intervals (also the added latency with powersave, of course) > So, when I know that I am doing passive scan, I would like the option > to set the dwell time larger. > > And, for active scanning, maybe 33ms is a lot longer that is actually > needed? There are some (WFA?) requirements to answer within 30ms, but not faster, so I think that's the reason for this value. > I read through some of your comments from before. I think we could > treat this as a hint to the driver, and it could ignore it as needed. > > Firmware implementations I'm aware of are already limited in a million > different ways, and of course if someone cared, they could propagate > the dwell time into the firmware if they cared. > The thing though is that there are now use cases in the standard(s) that want/require doing this. So just adding it as a hint will run the risk of userspace (like wpa_s) using this "hint" for implementing newer spec functionality, testing on ath9k and hwsim and declaring that it works :-) And then we're stuck with this feature being used/advertised on older devices where it doesn't actually work. Now, having those standard use cases is actually a good argument *for* adding them in the standard API, but I think we need to be more careful around these issues - perhaps having drivers indicate that they support it, maybe even with valid ranges, etc. johannes -- 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
