On Tue, Sep 10, 2019 at 1:48 PM Krishna Chaitanya
<chaitanya.mgit@xxxxxxxxx> wrote:
>
> 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.
Looking a bit at the code, currently, in AP mode both EAP or EAPOL send ends up
in hostapd_drv_hapd_send_eapol() which uses below logic
if device_ap_sme or !use_monitor: sendto on eapol_tx_sock
else if use_monitor: sendmsg on monitor_sock
else NL80211_CMD_FRAME
We can use NL80211_CMD_CONTROL_PORT_FRAME for the first case if it is supported,
but should we also use NL80211_CMD_CONTROL_PORT_FRAME for the last
case if it is supported
as NL80211_CMD_FRAME is an overkill (as we don't use most of the options).
New logic would be
if use_monitor: sendmsg on monitor_sock
if WPA_DRIVER_FLAGS_TX_CONTROL_PORT && (if device_ap_sme or !use_monitor):
send using NL80211_CMD_CONTROL_PORT_FRAME
else if device_ap_sme or !use_monitor: sendto on eapol_tx_sock
else NL80211_CMD_FRAME //For older kernels
We are not merging the hapd and wpa_s EAP paths to keep things simple
(As Alexander mentioned on the other thread).
>
> > > 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
