Question on wpa_supplicant and FT over DS.
greearb at candelatech.com
Fri Feb 14 15:17:30 EST 2014
On 02/14/2014 01:30 AM, Jouni Malinen wrote:
> On Thu, Feb 13, 2014 at 04:22:48PM -0800, Ben Greear wrote:
>> Does wpa_supplicant properly support FT over DS? It seems that when
>> we tell it to roam to a new AP using wpa_cli, it always does over-the-air
>> even when AP is beaconing as being FT over DS.
>> Is this a feature that needs special configuration, or maybe some
>> special hint when initiating a roam through the CLI?
> FT_DS command needs to be used if you want to force FT-over-DS to be
> used (and no, it would never be used automatically in the current
> implementation if I remember correctly).
Ok, using ft_ds wpa_cli command seems to do the trick. I might have found
a bug though...after a large number of ft_ds roams, it started to fail to
roam and I saw large amounts of spam in the supplicant logs:
1392407947.289795: sta1: CTRL-EVENT-EAP-FAILURE EAP authentication failed
1392407947.289799: EAPOL: SUPP_PAE entering state AUTHENTICATING
1392407947.289803: EAPOL: SUPP_BE entering state FAIL
1392407947.289806: EAPOL: SUPP_PAE entering state HELD
1392407947.289810: EAPOL: Supplicant port status: Unauthorized
1392407947.289813: nl80211: Set supplicant port unauthorized for dc:a5:f4:ff:4f:ae
1392407947.289831: EAPOL: SUPP_BE entering state IDLE
1392407947.289836: EAPOL: SUPP_PAE entering state RESTART
1392407947.289840: EAP: EAP entering state INITIALIZE
1392407947.289844: EAP: EAP entering state IDLE
1392407947.289847: EAP: EAP entering state FAILURE
1392407947.289851: sta1: CTRL-EVENT-EAP-FAILURE EAP authentication failed
1392407947.289855: EAPOL: SUPP_PAE entering state AUTHENTICATING
1392407947.289859: EAPOL: SUPP_BE entering state FAIL
1392407947.289862: EAPOL: SUPP_PAE entering state HELD
1392407947.289865: EAPOL: Supplicant port status: Unauthorized
1392407947.289869: nl80211: Set supplicant port unauthorized for dc:a5:f4:ff:4f:ae
I have logging set on verbose, and since no other logging messages
are shown during this spammage, it seems to me that this might be some
state machine malfunction?
It eventually recovered and started roaming properly again. The logs wrapped
and went away before I could capture the transition back to normal
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the HostAP