Yes, the problem occurred using the wpa_supplicant.
I have just checked it, effectively that commit fixes the issue but it
requires the use of CONFIG_FILS which is experimental.
thanks, EG
El sáb., 1 dic. 2018 a las 22:19, Jouni Malinen (<j@xxxxx>) escribió:
>
> 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
