Hi Denis,
On 1/22/21 8:50 PM, Denis Kenzior wrote:
Hi Alvin,
On 1/22/21 7:37 AM, Alvin Šipraga wrote:
> Following a successful roaming sequence, schedule another attempt unless
> the driver has sent a high RSSI notification. This makes the behaviour
> analogous to a failed roaming attempt where we remained connected to the
> same BSS.
>
> This makes iwd compatible with wireless drivers which do not necessarily
> send out a duplicate low RSSI notification upon reassociation. Without
> this change, iwd risks getting indefinitely stuck to a BSS with low
> signal strength, even though a better BSS might later become available.
>
> In the case of a high RSSI notification, the minimum roam time will also
> be reset to zero. This preserves the original behaviour in the case
> where a high RSSI notification is processed after station_roamed().
> Doing so also gives a chance for faster roaming action in the following
> example scenario:
>
> 1. RSSI LOW
> 2. schedule roam in 5 seconds
> (5 seconds pass)
> 3. try roaming
> 4. roaming fails, same BSS
> 5. schedule roam in 60 seconds
> (20 seconds pass)
> 6. RSSI HIGH
> 7. cancel scheduled roam
> (20 seconds pass)
> 8. RSSI LOW
> 9. schedule roam in 5 seconds or 20 seconds?
>
> By resetting the minimum roam time, we can avoid waiting 20 seconds when
> the station may have moved considerably. And since the high/low RSSI
> notifications are configured with a hysteresis, we should still be
> protected against too frequent spurious roaming attempts.
> ---
> src/station.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
All applied, thanks!
Any chance you would be willing (or at least attempt) to add an auto
test for some of the above scenarios?
Sure, I'd be happy to. I haven't tried running the autotest suite
before, so please have some patience with me as I try to figure things out.
Kind regards,
Alvin