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, > + 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. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
