On Tue, Nov 27, 2018 at 03:29:22PM +0100, Enrique Giraldo wrote:
> There is a problem detecting RRM capabilities after reassociations
> using 802.11R.
> The WLAN_CAPABILITY_RADIO_MEASUREMENT is maintained, but the rrm
> capabilities are not.
>
> Calling handle_assoc with reassoc = 1 hostapd is not detecting rrm capabilities.
>
> After parsing ies in check_assoc_ies()
>
> if (ieee802_11_parse_elems(ies, ies_len, &elems, 1) == ParseFailed) {
> hostapd_logger(hapd, sta->addr, HOSTAPD_MODULE_IEEE80211,
> HOSTAPD_LEVEL_INFO, "Station sent an invalid "
> "association request");
> return WLAN_STATUS_UNSPECIFIED_FAILURE;
> }
>
> the value of elems.rrm_enabled_len is 0.
> The main difference is that it takes pos =
> mgmt->u.reassoc_req.variable instead of pois =
> mgmt->u.assoc_req.variable.
>
> The consequence of this is that the new hostapd thinks that the
> station does not support rrm but it does.
That hostapd behavior looks correct to me, i.e., this sounds like a
station side issue.
> The scenario has been tested with 2 hostapds with RRM and 11R and 1
> supplicant with RRM and 11R. The initial association works fine.
Did your test station use wpa_supplicant and a driver that uses the SME
within wpa_supplicant? If so, I did manage to reproduce this and the
following commit fixes wpa_supplicant to include the RM Enabled
Capabilities element in the FT Reassociation Request frame:
https://w1.fi/cgit/hostap/commit/?id=8c41734e5de118a6a20589bde306a11bef922e1d
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
