On Tue, Sep 10, 2019 at 3:51 AM Jouni Malinen <j@xxxxx> 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 socket/nl_socket. > > 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. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
