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 <brendan.jackman@bluwireless.co.uk>

diff --git a/wpa_supplicant/ibss_rsn.c b/wpa_supplicant/ibss_rsn.c
index 48dd66b126a844a6ceac48ebdc56e266d23db05d..0aba8cb04369c5a2a6a3e9290b7af3be995709e4 100644 (file)
--- 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 d80b8f28dda4e0b9fb0f6e17bdf137dae75f0abb..b67a24e537d0963e411d3d62ad5c8d9c43fefe3d 100644 (file)
--- 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);
        }