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

Krishna Chaitanya chaitanya.mgit at gmail.com
Tue Sep 10 01:18:57 PDT 2019

On Tue, Sep 10, 2019 at 3:51 AM Jouni Malinen <j at w1.fi> wrote:
> 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.

I guess the main focus was on the 4-way handshake, but you are right,
it can introduce race
for 802.1x, it is better to use the same interface for both either

> > 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,
> > +                               NL80211_CMD_CONTROL_PORT_FRAME);
> > +     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.
>From an API perspective, this could take noencrypt as an argument, but it
would be better if we can make this change only for RSN and leave WPA unchanged.

More information about the Hostap mailing list