Roaming is important for mobile WLAN clients (wlanmode sta). If you have more than one AP connected via a DS (Distribution System) and get out of the range of one AP and enter the range of another AP your station should switch between those APs. That means in detail the client should disassociate from the first AP and associate to the better (higher rate, higher RSSI) AP.
Roaming can be controlled by the driver itself or by using a user mode tool. If a user mode application wants to control roaming it has to handle the states correctly. So far no application is known to handle roaming very fast except the sync_scan that seems to be very promising (Thanks Tom for pointing me there).
The madwifi driver (>= 0.9) will only roam if the current associations can not be used anymore (see ticket #697). This means, even though you moved directly next to another AP the driver might still use the old & weak, but useable AP. For mobile machine automation this is important because the assoc has to break first, before it can then be established to the strongest AP close by. But even this selection of the "strongest AP" is not guaranteed to work quick in case madwifi takes an old (and outdated) result for a roaming candidate out of it's scan cache (cache miss). Then the driver will wait a few seconds for the associaction to get established to another AP (~15s).
However, take into account that seamless roaming of a mobile machine will not work without connection loss for several SECONDS (~ 0-15s).
Developers Point Of View
- IEEE80211_PARAM_ROAMING = 2 --> set manual roaming mode (application controls roaming behaviour).
- set ESSID using wireless extensions
- send struct ieee80211req_mlme via private ioctl to madwifi driver
The MadWifi specific tasks can be done using these functions (currently there are errors in these functions, somehow they do not work):
Compiling: Please see attched ath_roam.c file. To compile the code execute following instruction gcc -c -o ath_roam.o ath_roam.c && gcc -liw -o ath_roam ath_roam.o