On 2/23/20 11:43 PM, Jouni Malinen wrote: > On Mon, Jan 13, 2020 at 03:58:31PM +0100, Markus Theil wrote: >> This patch series adds rx control port support over nl80211. Control port >> over nl80211 delivers all EAPOL and PREAUTH frames to userspace. This conflicts >> with the current hostapd handling of pre-auth frames. Therefore, this feature >> gets disabled for hostapd. Furthermore a pending kernel patch is necessary to >> forward pre-auth frames from userspace (otherwise handled by Linux bridge code). > Could you please rebase this to be for EAPOL frames only, i.e., without > any dependencies on the previous series that added RSN preauthentication > frames? That should remove this constraint on hostapd or that kernel > patch. This kernel patch is only needed for hostap to work with Pre-Auth frames. It is not needed for wpa_supplicant. Thats why I disabled control port over nl80211 for hostapd. With the current kernel implementation, using nl80211 control port also means, that the kernel will forward all pre-auth frames to userspace. It's currently unconditionally done (that's how I found it there). Therefore, if this gets rebased to only handle EAPOL frames, Pre-Auth will stop to work. >> The corresponding Linux patches for pre-auth support for hostapd are: >> - nl80211: add src and dst mac attributes >> - nl80211: use src and dst addr attribute for control port tx/rx > I'm assuming neither of those would be needed for EAPOL frames. Correct. >> Furthermore another kernel patch is needed, in order to avoid a deadlock: >> - cfg80211: fix deadlocks in autodisconnect work > Could you please clarify how this deadlock get triggered? Would that > happen if hostapd or wpa_supplicant were now updated to use nl80211 > control port for EAPOL RX? If so, this sounds problematic and > potentially needing a workaround of some sort to avoid critical issues > with kernel versions that do not have this fix. I found this kernel bug, while running the hostap test suite (ap_bss_add_reuse_existing). It is triggered, when the nl socket, which registered handling control port frames is closed, while there still is some interface connection state remaining. This patch has no consequences, when used in STA mode. Affected operation modes are: ad-hoc, AP, P2P-GO and Mesh-Point. If any of this mode is used with an older kernel, deadlocks may happen. >> This patch enables wpa_supplicant to use control port rx over nl80211 for both >> EAPOL and PREAUTH frames. wpa_supplicant connects noticeably faster in my tests >> with this patch series applied. > That difference in connection speed is surely not related to RSN > preauthentication frame handling, so if that kernel deadlock is not a > significant problem, it would be good to get the EAPOL frame part > included. I don't really know, how to mitigate this deadlock issue. I think the best solution would be, to check against a feature flag, which was added after fixing this deadlock issue and conditionally enable control port rx over nl80211. Furthermore, I have seen, that there is currently no tx status message for transmitting over nl80211 control port. If I understand it correctly, hostapd uses such kind of status message (received over socket control messages) in order to retransmit faster. I'm currently working on a kernel patch to provide that functionality with a message similar to NL80211_CMD_FRAME_TX_STATUS, but only for the frames send over the control port. As this only is my (surely incomplete) way of looking at things, I'm eager to hear your thoughts about that particular issue. >> nl80211: use and/or set socker owner where necessary > That's missing Signed-off-by: line in the commit message. Thanks for the hint, I'll add that. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
