Re: [PATCH 0/4] Packet/beacon loss roaming improvements

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 11/1/23 6:39 PM, Denis Kenzior wrote:
> Hi James,
> 
>>>
>>>> If the kernel has a hard limit after which it expects the connection 
>>>> to be disconnected, we can start a timer for 2-4x that limit?  Looks 
>>>> like kernel uses probe_wait_ms parameter for this with a default of 
>>>> 500ms. Is your setup using the default values for beacon_loss_count 
>>>> and probe_wait_ms?
>>>
>>> Yep, everything is default as far as nl80211/driver options.
>>
>> I found an old thread I asked on linux-wireless back when I removed 
>> the beacon loss handling [1]. Johannes explained that behavior did 
>> apparently change in order to support power save (your memory was 
>> correct).
>>
> 
> Hah, funny.
> 
>> I identified the behavior change with hwsim, and apparently took his 
>> word when he said:
>>
>> "I'm pretty sure real hardware will behave just like hwsim here, 
>> albeit perhaps a bit slower"
>>
>> And I never added "proper" testing of beacon loss, i.e. block several 
>> beacons as opposed to just tearing down the AP. And this appears 
>> closer to the behavior I'm seeing in reality (AP not going down, just 
>> dropping beacons).
> 
> Right.
> 
>>
>> So this is my bad, I didn't take into account the situation of beacons 
>> being dropped but then being picked up again, or the nullfuncs/probes 
>> coming back successfully.
> 
> So the question is still how we handle this properly.  When the kernel 
> sends the nullfunc / probe request, are we going to be interfering with 
> that logic by initiating a scan right away?  A scan would force the 
> device to go offchannel, preventing it from receiving the AP's 
> response.  Given that nullfunc should be extremely fast, maybe we should 
> delay any roam action we take by a second or two?  If the AP is truly 
> lost, then we'll get disconnected soon after the LOST_BEACON event.  If 
> it isn't, then an extra second/two is not going to make much difference 
> since the scan should be limited and quite fast most of the time.

Yes scanning likely kills all chances of recovery. And this may very 
well be why I was seeing a 100% rate of disconnections. Granted, our 
devices are always moving so its very likely that once beacon/packet 
loss starts its only going to get worse, but that's not the case for 
everyone. Scanning just makes things worse.

I'm fine adding similar handling that I added for packet loss, except 
always delay rather than only on additional events. But I would like to 
explore other options in the future.

I'm not sure how, but being able to detect if the AP responded to 
nullfunc/probes prior to the kernel blowing away the connection would be 
great. (like send our own nullfunc frames or something, not really sure...)

Its taking IWD about 4-5 seconds to reconnect, 3 seconds are the quick 
scan and ~1-2 seconds for DHCP. (I need to look at why the quick scan is 
taking that long, that seems like something isn't right). So if its at 
all possible to roam that is best, obviously.

Thanks,
James


> 
> Regards,
> -Denis