aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBrendan Jackman <brendan.jackman@bluwireless.co.uk>2020-01-03 15:17:41 (GMT)
committerJouni Malinen <j@w1.fi>2020-01-05 18:34:15 (GMT)
commit144314eaa7e09374b7f9a3708263a298e05cbfd6 (patch)
treead0781835c683d4523f463aef03c251f18d681cd
parent8759e9116aa6c18d1f68caf1b5bc1cd338f6c142 (diff)
downloadhostap-144314eaa7e09374b7f9a3708263a298e05cbfd6.zip
hostap-144314eaa7e09374b7f9a3708263a298e05cbfd6.tar.gz
hostap-144314eaa7e09374b7f9a3708263a298e05cbfd6.tar.bz2
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>
-rw-r--r--wpa_supplicant/ibss_rsn.c3
-rw-r--r--wpa_supplicant/wpas_glue.c3
2 files changed, 6 insertions, 0 deletions
diff --git a/wpa_supplicant/ibss_rsn.c b/wpa_supplicant/ibss_rsn.c
index 48dd66b..0aba8cb 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 d80b8f2..b67a24e 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);
}