On 2018/04/29 10:17, Stefan Sperling wrote: > On Sun, Apr 29, 2018 at 03:39:07AM +0200, Jesper Wallin wrote: > > Hi all, > > > > I recently learned that my AP behaves badly and I have packet loss when > > the background scan is running. I had a small chat with stsp@ about it, > > asking if there is a way to disable it. He kindly explained that if I'm > > connected to an AP with a weak signal, it will try to find another AP > > with better signal and use that one instead. > > > > Sadly, I only have a single AP at home and this doesn't really solve my > > problem. Though, you can also set a desired bssid to use, to force it > > to connect to a single AP. However, the background scan will still run > > even if this is set. > > > > Maybe the background scan has other use-cases that I'm not aware of, if > > so, I apologize in advance. The patch below simply check if a bssid is > > specified and if so, skip the background scan. > > I agree, even though it would be nice to understand the underlying > packet loss issue. But I cannot reproduce the problem unforunately :( > Have you verified that the problem only happens on this particular AP?
It's very common for wifi clients to do background scans so I'd be interested to know whether non-OpenBSD clients also see packet loss, or whether OpenBSD with a different client device is any better. What are the AP and client devices? Are other firmware versions available? I guess bg scan must use power-saving to queue frames while the client is off channel so maybe the issue relates to this. I'm wondering if changing this may introduce problems when an AP moves to a different channel? Either by manual configuration, mechanisms like Ruckus' channelfly (still possible on single-AP even without a controller), radar detect on 5GHz, or even something as simple as rebooting an AP set to "auto" channel.
