WPA-PSK with prism2_param host_roaming 0 / handover performance

[Duncan Grove]

Hi,

I am using wpa_supplicant-0.4.0 with hostap-driver-0.4.0 and JT's 
Wireless Tools 28-pre7 to connect to a number Cisco 1231 APs using 
WPA-PSK; full WPA2 isn't an option for me at this stage. All APs are 
configured with the same SSID and PSK. In its current incarnation, 
wpa_supplicant sets prism2_param host_roaming to 2, i.e. manual scanning 
and roaming. Unfortunately this mode isn't very useful for mobile 
applications. I believe that the eventual plan is to use host_roaming 
mode 1, where the driver would take care of scanning and roaming 
decisions, but this doesn't seem to work yet.

As a stopgap solution, automatic WPA-PSK roaming can be achieved by 
setting prism2_param host_roaming to 0. In this case, 
hostap/wpa_supplicant relies on the firmware to change channels when 
required, and wpa_supplicant simply takes care of the authentication 
process. Unfortunately, however, it takes wpa_supplicant 2-3 seconds to 
decide to rekey. During this period both outgoing and incoming packets 
get dropped with log messages like "dropped unencrypted TX data frame 
(drop unencrypted = 1)" and "TKIP: replay detected: STA=AP_MAC_ADDRESS) 
res=-4" (I can provide dumps of this process if they would help). This 
isn't so great for eg VOIP applications and I would like to reduce the 
duration of this network outage.

Interestingly, a manual channel change by iwconfig wlan0 channel X 
doesn't suffer from this problem. It appears that a manual channel 
change leads to a wpa_supplicant DISCONNECT event, which removes the 
encryption keys, followed by a CONNECT event, which rekeys the channel 
in a timely manner. Conversely, however, an firmware initiated roam just 
causes a CONNECT event without the DISCONNECT first i.e. the keys 
weren't removed and subsequently don't get reestablished quickly.

What is the best way to get wpa_supplicant to rekey in a timely manner 
after a firmware initiated roam? Would it be possible to get 
wpa_supplicant to detect the AP change wireless extension event and 
rekey? Alternatively, would it be possible to add a manual wpa_cli 
reauth command, which simply rekeys the channel without having to go 
through the whole scanning/association process? (I have a modded iwevent 
which will detect the AP change event and run a script, eg containing 
the wpa_cli reauth command). At first glance wpa_cli reassoc may seem to 
be good enough for this purpose, since it appears to do a 0 second scan 
followed by the reauth, but unfortunately the 0 second scan still causes 
more WEXT disconnect / reconnect / AP change events, which are necessary 
to trigger the reassoc/rekey, hence reassocs will be triggered ad infinitum.

Thanks,
Duncan