State of roaming support in wpa_supplicant 0.5.7

[Jouni Malinen]

On Wed, Feb 14, 2007 at 01:08:55PM +0100, LTI. - Ticmanis, Linards wrote:

> I would like to know, what is the state of seamless roaming support in wpa_supplicant 0.5.7 if the driver does not do its own roaming.

Non-existent with ap_scan=1..

> Specifically, I would like the following to happen in WPA-PSK mode:
> 
> 1.) Scan regularly even while associated.
> 2.) If another AP has decidedly better signal level than the one we're on, reassociate with that other AP. Don't wait until the first AP is totally out of range.
> 3.) Do a decent handoff that minimizes the amount of lost pings (or other lost data).

> Is it possible to do what I want to do with wpa_supplicant? Or do I need to implement roaming in the driver in this case?

Yes, this has been done in some customer projects, i.e., wpa_supplicant
has been modified to do background scanning (with the help of the
driver) and allow it to roam even if not strictly necessary (i.e.,
before running out of range). For a simple test on Linux, it could be
enough to just run 'iwlist <iface> scan' from an external script every N
seconds and see what happens.. wpa_supplicant should notice the new scan
results and select an AP based on them.

> On first glance, the function wpa_supplicant_select_bss() in events.c doesn't seem to contain any prioritizing by signal quality. Am I correct that no such prioritizing takes place in the supplicant at this time?

The driver interface is expected to provide results in priority order.
In case of any Linux driver that uses wireless extensions for scan
results this sorting is done in driver_wext.c.
 
-- 
Jouni Malinen                                            PGP id EFC895FA