what is reassociation_deadline/r0_key_lifetime?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I'm trying to debug an issue related to FT-over-DS authentications
expiring (unknown if the AP is even running hostapd) and I came across
these options:

# Default lifetime of the PMK-RO in minutes; range 1..65535
# (dot11FTR0KeyLifetime)
#r0_key_lifetime=10000

# Reassociation deadline in time units (TUs / 1.024 ms; range
1000..65535)
# (dot11FTReassociationDeadline)
#reassociation_deadline=1000

So my first question is more pointing out the fact that these values
are used to populate the TIE element, but don't see any timeouts to
enforce these. Is this intended? Or maybe these options were merely for
testing the presence of TIE but not actually used?

My second question is how this relates to FT/reassociation. The spec
isn't clear what these timeouts are for. Maybe someone knows? Is it for
rekeys? or for future FT attempts? or?

The reason I'd like to know this is because IWD does FT-over-DS quite
early, and this user is seeing their AP 'expire' his station. He then
cannot reassociate when its time to roam. This is the first time I'd
ever seen this and we are trying to figure out if maybe these timeouts
point to some ultimate expiration for FT keys. Again, the spec is
totally unclear about this AFAICT.

Thanks,
James



_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux