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

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 11/2/23 7:10 AM, Denis Kenzior wrote:
> Hi James,
> 
>>
>> 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 guess the question is, does adding LOST BEACON handling actually help 
> or you're speculating that it does?  I don't mind if we add this back in 
> with a delay, but I'm worried it doesn't actually do anything.  7 
> beacons lost in a row is likely not recoverable territory.

In the behavior I witnessed which was actually quite reproducible at the 
time, and yes roaming on beacon loss definitely helped. It avoided an 
inevitable disconnect.

> 
> I'm actually surprised the driver doesn't give you any other indications 
> prior to the lost beacon event.  I would have expected RSSI or packet 
> loss to manifest itself prior?

There were packet loss events in some cases, and I'd say 75% of the time 
IWD did end up roaming anyways (with a patch that roamed on beacon loss, 
identical to packet loss). It was only the cases when we got a beacon 
loss and IWD did not roam that the disconnect was always inevitable. 
This was the motivation to force the roam for beacon loss.

RSSI wasn't always bad, but it was a very high load environment so I 
assume that wasn't helping.

> 
>>
>> 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...)
> 
> Yes, the current implementation of this event in the kernel is pretty 
> useless. What we really need is an additional threshold that generates 
> an event out to userspace _before_ the kernel starts taking potentially 
> irreversible actions. Something like a pre-beacon-loss event that gets 
> generated when 2-3 beacons are lost in a row.

Best would be an event like "Disconnection Imminent" (after the 2 
nullfuncs failed) so userspace could start a roam. Like you mentioned 
even if we knew a few beacons were lost, scanning is probably going to 
ruin any chance of recovery.

On the bright side a disconnect isn't that terrible since IWD is super 
fast at reconnecting, I was just looking for any optimization I could to 
maintain the connection.

> 
>>
>> 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 
> 
> That's awful.  How many frequencies are you generating?  Even a full 
> scan should be ~1-2 seconds at most.  And 1-2 seconds for DHCP also 
> seems fishy.  I've tested our implementation to be sub-300ms or so.

In theory only 5:
known_freq_set = known_networks_get_recent_frequencies(5);

But I'm also seeing a random New Scan Results event prior to the quick 
scan. Anyways, its something I gotta look into.

> 
>> long, that seems like something isn't right). So if its at all 
>> possible to roam that is best, obviously.
>>
> 
> Yep.
> 
> Regards,
> -Denis