From 144314eaa7e09374b7f9a3708263a298e05cbfd6 Mon Sep 17 00:00:00 2001 From: Brendan Jackman Date: Fri, 3 Jan 2020 16:17:41 +0100 Subject: [PATCH] wpa_supplicant: Send EAPOL frames over nl80211 where available Linux kernel v4.17 added the ability to request sending control port frames via nl80211 instead of a normal network socket. Doing this provides the device driver with ordering information between the control port frames and the installation of keys. This empowers it to avoid race conditions between, for example, PTK replacement and the sending of frame 4 of the 4-way rekeying handshake in an RSNA. The key difference between a TX_CONTROL_PORT and normal socket send is that the device driver will certainly get any EAPOL frames comprising a 4-way handshake before it gets the key installation call for the derived key. By flushing its TX buffers it can then ensure that no pending EAPOL frames are inadvertently encrypted with a key that the peer will not yet have installed. Update the RSN supplicant system to use this new operation for sending EAPOL-Key frames when the driver reports that this capability is available; otherwise, fall back to a normal Ethernet TX. I have tested this on DMG (11ad/ay) devices with an out-of-tree Linux driver that does not use mac80211. Without this patch I consistently see PTK rekeying fail if message 4/4 shares a stream with other in-flight traffic. With this patch, and the driver updated to flush the relevant TX queue before overwriting a PTK (knowing, now, that if there was a message 4/4 related to the key installation, it has already entered the driver queue), rekeying is reliable. There is still data loss surrounding key installation - this problem is alluded to in IEEE Std 802.11-2016, 12.6.21, where extended Key ID support is described as the eventual solution. This patch aims to at least prevent rekeying from totally breaking the association, in a way that works on kernels as far back as 4.17 (as per Alexander Wetzel extended Key ID support should be possible on 5.2). See http://lists.infradead.org/pipermail/hostap/2019-May/040089.html for a little more context. Signed-off-by: Brendan Jackman --- wpa_supplicant/ibss_rsn.c | 3 +++ wpa_supplicant/wpas_glue.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/wpa_supplicant/ibss_rsn.c b/wpa_supplicant/ibss_rsn.c index 48dd66b12..0aba8cb04 100644 --- a/wpa_supplicant/ibss_rsn.c +++ b/wpa_supplicant/ibss_rsn.c @@ -69,6 +69,9 @@ static int supp_ether_send(void *ctx, const u8 *dest, u16 proto, const u8 *buf, "len=%lu)", __func__, MAC2STR(dest), proto, (unsigned long) len); + if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_CONTROL_PORT) + return wpa_drv_tx_control_port(wpa_s, dest, proto, buf, len); + if (wpa_s->l2) return l2_packet_send(wpa_s->l2, dest, proto, buf, len); diff --git a/wpa_supplicant/wpas_glue.c b/wpa_supplicant/wpas_glue.c index d80b8f28d..b67a24e53 100644 --- a/wpa_supplicant/wpas_glue.c +++ b/wpa_supplicant/wpas_glue.c @@ -112,6 +112,9 @@ static int wpa_ether_send(struct wpa_supplicant *wpa_s, const u8 *dest, } #endif /* CONFIG_TESTING_OPTIONS */ + if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_CONTROL_PORT) + return wpa_drv_tx_control_port(wpa_s, dest, proto, buf, len); + if (wpa_s->l2) { return l2_packet_send(wpa_s->l2, dest, proto, buf, len); }