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

[Denis Kenzior <denkenz@gmail.com>]

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.

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?

> 
> 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.

> 
> 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.

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

Yep.

Regards,
-Denis