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

[Denis Kenzior <denkenz@gmail.com>]

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.

Regards,
-Denis