[PATCH v2] wpa_supplicant: Send EAPoL-Key frames over NL80211 where available

Jouni Malinen j at w1.fi
Mon Sep 9 15:21:30 PDT 2019

On Mon, Sep 02, 2019 at 05:52:16AM +0000, Brendan Jackman wrote:
> 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.

Could you please clarify why this uses the nl80211-path for EAPOL-Key
frames, but not for other EAPOL frames? Could this result in race
conditions in some new cases? The main one that comes to mind is only on
AP/Authenticator side (EAP-Success send through Linux packet socket
followed immediately by EAPOL-Key msg 1/4 transmission). I guess that
would not apply with station/Supplicant side changes, but still, this
inconsistent behavior with different EAPOL frames feels undesired.

> diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c

> +static int driver_nl80211_tx_control_port(void *priv, const u8 *dest,

> +	msg = nl80211_ifindex_msg(bss->drv, ifindex, 0,

> +	if (nla_put_u16(msg, NL80211_ATTR_CONTROL_PORT_ETHERTYPE, proto))
> +		goto fail;
> +	if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, dest))
> +		goto fail;
> +	if (nla_put(msg, NL80211_ATTR_FRAME, len, buf))
> +		goto fail;
> +
> +	ret = send_and_recv_msgs(bss->drv, msg, NULL, NULL);

Should this include possibility to use
NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT? While this function is not
currently used with IEEE 802.1X/WEP case, my comment above asked about
consistent EAPOL frame TX behavior.. Many WPA(v1) implementation were
also using unencrypted EAPOL frames regardless of whether TK was
configured. I'm not sure how much we really want to go into WEP or
WPA(v1) nowadays, but it would be good to be clear on what this function
is trying to do and document the encryption behavior for cases where TK
is set.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list