On Fri, Mar 08, 2019 at 02:07:07PM -0800, Abc Abc wrote: > It appears, action frame processing as 2 different flows for pmf and > non-pmf cases. There shouldn't be, i.e., this is likely caused by the driver doing something that hostapd does not expect.. In this particular case, my guess would be that the driver reports the FT Action frame RX event with the Protected bit in FC cleared to 0. hostapd expect that bit to indicate whether the frame was protected. While that kind of works with the changes described below, that is not really the expected behavior here and it won't work with the current hostap.git snapshot anymore unless the driver is fixed to report the unmodified Protected bit for PMF-encrypted frames or hostapd is built without NEED_AP_MLME (which assumes the driver takes care of all the needed validation for PMF). > for pmf case "hostapd_action_rx() " comes into active path and it as below bug > > ------------ bug ----- > hostapd_action_rx() > > plen = drv_mgmt->frame_len - 24 - 1; > const u8 *payload = drv_mgmt->frame + 24 + 1; ---- points to > "action_code + ..." > wpa_ft_action_rx() ----- it expects contents "categor+action_code+..." > > ------------- > --------- fix ------- > hostapd_action_rx() > plen = drv_mgmt->frame_len - IEEE80211_HDRLEN; > const u8 *payload = (u8 *)&mgmt->u.action; > wpa_ft_action_rx() > --------- fix ------- > > I think it is applicable to hostapd-2.7 as well. Yes, this was a quite old bug that was caused by one error masking another error.. This is now fixed: https://w1.fi/cgit/hostap/commit/?id=002edb6303c5a3f8a21cc2373d21a340c9c5328d -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
