Timing question with 802.11r and OTA roaming.

[Ben Greear]

On 06/29/2014 01:49 AM, Jouni Malinen wrote:
> On Tue, Jun 24, 2014 at 11:52:41AM -0700, Ben Greear wrote:
>> We are seeing a case where it appears to take around 9ms from the supplicant
>> roam request Athenticate until the packet hits the air.  The station is ath9k, APs are cisco.
>>
>> After that first Authenticate packet, it seems things go a good bit quicker.
>
> How do you measure this, i.e., which steps are included in that 9 ms?

I'm just looking at supplicant logs and comparing against the packet capture:

1403633898.259590: sta1: SME: Trying to authenticate with dc:a5:f4:f3:ce:9d (SSID='aironet1-5' freq=5745 MHz)
1403633898.268524: FT: Failed to set PTK to the driver
1403633898.268570: sta1: Trying to associate with dc:a5:f4:f3:ce:9d (SSID='aironet1-5' freq=5745 MHz)

It takes 9ms between 'trying to authenticate' and the failure to set PTK.
Only at the end of this do we actually see a pkt on the air:

8647 1403633898.267378000 00:aa:aa:aa:aa:01 -> Cisco_f3:ce:9d 802.11 217 Authentication, SN=3381, FN=0, Flags=........C
8648 1403633898.267392000              -> 00:aa:aa:aa:aa:01 (RA) 802.11 62 Acknowledgement, Flags=........C

So, looks like it takes 8ms or so for the authenticate message to go onto the air.  The delay could
easily be in the kernel or driver, but I was curious if it was a known and expected-to-be so
issue before I spent time trying to figure out why it takes so long.

It will be a while before I can look into this in detail again.

Thanks,
Ben

>
>> Any idea if this is expected behaviour or not?  In particular, I wonder about
>> that PTK failure.  We are running software-crypt on the station, in case that
>> matters.
>
> PTK failure is cfg80211/mac80211 "feature" (no STA entry for the new AP
> yet) and while it takes some time to go through, I don't think it is
> significant and anyway, this is after the Authentication frame exchange,
> so I'd assume it is not included in that 9 ms.
>
> It should be possible to skip this set_key prior association that is
> currently failing with cfg80211/mac80211, but a more appropriate cleanup
> could be in adding the STA entry sooner to allow this early PTK
> configuration to succeed instead, so that the data connection would be
> functional immediately on reassociation.
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com