Should the return value be non zero in this case On Mon, Dec 30, 2019 at 9:34 AM <hostap-request@xxxxxxxxxxxxxxxxxxx> wrote: > > Send Hostap mailing list submissions to > hostap@xxxxxxxxxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.infradead.org/mailman/listinfo/hostap > or, via email, send a message with subject or body 'help' to > hostap-request@xxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > hostap-owner@xxxxxxxxxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Hostap digest..." > > > Today's Topics: > > 1. [PATCH] wpa_cli to display WPS-PIN-ACTIVE and WPS-CANCEL > events (bilalhp@xxxxxxxxx) > 2. Re: [PATCH v2] wpa_supplicant: Send EAPoL-Key frames over > NL80211 where available (Krishna Chaitanya) > 3. Re: [PATCH v2] Add application extension data to WPS IE > (Jouni Malinen) > 4. Re: [PATCH] wpa_supplicant: harden systemd service (Jouni Malinen) > 5. Re: [RFC] mesh: allow processing authentication frames in > blocked state (Jouni Malinen) > 6. Re: [RFC] tests: verify RX/TX STBC overrides (Jouni Malinen) > 7. Re: [RFC PATCH 0/2] Do not de-authenticate if WoWLAN is > enabled (Jouni Malinen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Dec 2019 13:22:01 +0300 > From: bilalhp@xxxxxxxxx > To: hostap@xxxxxxxxxxxxxxxxxxx > Subject: [PATCH] wpa_cli to display WPS-PIN-ACTIVE and WPS-CANCEL > events > Message-ID: <1577701321-12833-1-git-send-email-bilalhp@xxxxxxxxx> > > From: Bilal Hatipoglu <bilal.hatipoglu@xxxxxxxxxxx> > > Signed-off-by: Bekir Celik <bekir.celik@xxxxxxxxxxx> > Signed-off-by: Bilal Hatipoglu <bilal.hatipoglu@xxxxxxxxxxx> > --- > wpa_supplicant/wpa_cli.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/wpa_supplicant/wpa_cli.c b/wpa_supplicant/wpa_cli.c > index 5b849fd..6d3f56a 100644 > --- a/wpa_supplicant/wpa_cli.c > +++ b/wpa_supplicant/wpa_cli.c > @@ -4004,6 +4004,10 @@ static void wpa_cli_action_process(const char *msg) > wpa_cli_exec(action_file, ifname, pos); > } else if (str_starts(pos, WPS_EVENT_ACTIVE)) { > wpa_cli_exec(action_file, ifname, pos); > + } else if (str_starts(pos, WPS_EVENT_PIN_ACTIVE)) { > + wpa_cli_exec(action_file, ifname, pos); > + } else if (str_starts(pos, WPS_EVENT_CANCEL)) { > + wpa_cli_exec(action_file, ifname, pos); > } else if (str_starts(pos, WPS_EVENT_TIMEOUT)) { > wpa_cli_exec(action_file, ifname, pos); > } else if (str_starts(pos, WPS_EVENT_FAIL)) { > -- > 2.7.4 > > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Dec 2019 20:07:18 +0530 > From: Krishna Chaitanya <chaitanya.mgit@xxxxxxxxx> > To: Jouni Malinen <j@xxxxx> > Cc: Brendan Jackman <brendan.jackman@xxxxxxxxxxxxxxxxx>, > "hostap@xxxxxxxxxxxxxxxxxxx" <hostap@xxxxxxxxxxxxxxxxxxx>, Chaitanya > Tata <chaitanya.tata@xxxxxxxxxxxxxxx>, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx>, Alexander Wetzel > <alexander@xxxxxxxxxxxxxx>, Antony King <antony.king@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH v2] wpa_supplicant: Send EAPoL-Key frames over > NL80211 where available > Message-ID: > <CABPxzYJu0+Puer+rMtTW+n3r7teQzV4yL-91UY=Ym1BC1WusoA@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset="UTF-8" > > 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. > > > > ------------------------------ > > Message: 3 > Date: Mon, 30 Dec 2019 17:38:24 +0200 > From: Jouni Malinen <j@xxxxx> > To: bilalhp@xxxxxxxxx > Cc: hostap@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH v2] Add application extension data to WPS IE > Message-ID: <20191230153824.GA16139@xxxxx> > Content-Type: text/plain; charset=us-ascii > > On Mon, Dec 30, 2019 at 01:12:02PM +0300, bilalhp@xxxxxxxxx wrote: > > Application Extension attribute is defined in WPS Spec v2.06 page 105. > > This patch makes hostapd add this application extension data to WPS IE > > if configured. The implementation is very similar to vendor extension. > > > > Currently, there is no way to configure it from config file, but it is > > also the case for wps_vendor_ext. It can be handled by an additional > > patch. > > I don't see any point in applying this patch without there being a > mechanism to actually use this functionality; this would be just > unreachable code. As far as wps_vendor_ext is concerned, that can be > used through wpa_supplicant D-Bus interface. > > -- > Jouni Malinen PGP id EFC895FA > > > > ------------------------------ > > Message: 4 > Date: Mon, 30 Dec 2019 18:02:06 +0200 > From: Jouni Malinen <j@xxxxx> > To: Topi Miettinen <toiwoton@xxxxxxxxx> > Cc: hostap@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] wpa_supplicant: harden systemd service > Message-ID: <20191230160206.GB16139@xxxxx> > Content-Type: text/plain; charset=us-ascii > > On Thu, Apr 04, 2019 at 02:22:59PM +0300, Topi Miettinen wrote: > > Subject: [PATCH] Harden systemd service > > > > Signed-off-by: Topi Miettinen <toiwoton@xxxxxxxxx> > > I have not seen any comments on this so far and since I'm not very > familiar with systemd, I'm not sure what exactly this does and how this > work with various different distributions. How has this been tested? Is > it clear that these capabilities do not result in regressions? It would > be helpful if the commit message were to address such details. > > > diff --git a/wpa_supplicant/systemd/wpa_supplicant.service.in b/wpa_supplicant/systemd/wpa_supplicant.service.in > > @@ -4,9 +4,28 @@ Before=network.target > > Wants=network.target > > > > [Service] > > -Type=dbus > > Why is this Type=dbus line being moved? > > > BusName=fi.w1.wpa_supplicant1 > > +CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW > > ExecStart=@BINDIR@/wpa_supplicant -u > > +IPAddressDeny=any > > Does that prevent TCP or UDP communication in some manner? If so, why? > Wouldn't that break WPS ER? (Or a more recent addition, DPP Controller?) > > > +LimitMEMLOCK=0 > > +LockPersonality=yes > > +MemoryDenyWriteExecute=yes > > +NoNewPrivileges=yes > > +PrivateTmp=yes > > +ProtectControlGroups=yes > > +ProtectHome=yes > > +ProtectKernelModules=yes > > +ProtectKernelTunables=yes > > +ProtectSystem=strict > > +RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK AF_PACKET > > Would this break use of AF_ALG? Or AF_BRIDGE? Or AF_LINK? > > > +RestrictNamespaces=yes > > +RestrictRealtime=yes > > +SystemCallArchitectures=native > > +SystemCallFilter=@system-service > > +TasksMax=1 > > +Type=dbus > > +UMask=0077 > > Everything else here looks like an addition, but the Type line is > removed and added, i.e., moved, which makes this patch more complex than > (hopefully) needed. > > -- > Jouni Malinen PGP id EFC895FA > > > > ------------------------------ > > Message: 5 > Date: Mon, 30 Dec 2019 18:12:57 +0200 > From: Jouni Malinen <j@xxxxx> > To: Felix Fietkau <nbd@xxxxxxxx> > Cc: hostap@xxxxxxxxxxxxxxxxxxx > Subject: Re: [RFC] mesh: allow processing authentication frames in > blocked state > Message-ID: <20191230161257.GC16139@xxxxx> > Content-Type: text/plain; charset=us-ascii > > On Mon, Feb 18, 2019 at 01:04:42PM +0100, Felix Fietkau wrote: > > If authentication fails repeatedly e.g. because of a weak signal, the link > > can end up in blocked state. If one of the nodes tries to establish a link > > again before it is unblocked on the other side, it will block the link to > > that other side. The same happens on the other side when it unblocks the > > link. In that scenario, the link never recovers on its own. > > > > To fix this, allow restarting authentication even if the link is in blocked > > state, but don't initiate the attempt until the blocked period is over. > > I have not seen any comments on this so far. Was there any addition work > going on in this area? > > PLINK_BLOCKED seems to be a implementation specific state, i.e., not > defined in IEEE Std 802.11-2016. The nl80211 part for it > (NL80211_PLINK_BLOCKED) is clearly defined to discard all frames ("all > frames transmitted from this mesh plink are discarded"), so this patch > would seem to be against that definition. As such, I'd like to see > nl80211.h in the kernel updated first if there is desire to change > behavior the plink blocked state. > > -- > Jouni Malinen PGP id EFC895FA > > > > ------------------------------ > > Message: 6 > Date: Mon, 30 Dec 2019 18:33:45 +0200 > From: Jouni Malinen <j@xxxxx> > To: Sergey Matyukevich <geomatsi@xxxxxxxxx> > Cc: hostap@xxxxxxxxxxxxxxxxxxx, Sergey Matyukevich > <sergey.matyukevich.os@xxxxxxxxxxxxx> > Subject: Re: [RFC] tests: verify RX/TX STBC overrides > Message-ID: <20191230163345.GA17575@xxxxx> > Content-Type: text/plain; charset=us-ascii > > On Wed, Jan 09, 2019 at 11:04:26PM +0300, Sergey Matyukevich wrote: > > Commit cdeea70f59d0 added wpa_s configuration options allowing HT STBC > > modifications for RX/TX spatial streams. Add tests to verify > > overriding of default HT STBC configuration for Tx and Rx > > spatial streams for hwsim driver. > > > > The test flow is straightforward: use wpa_s 'tx_stbc' and 'rx_stbc' > > configuration options to override default HT Rx/Tx STBC settings > > and check HT capabilities IEs in ASSOC frames. > > The following tests have been added: > > > > - ap_ht_stbc_disabled > > make sure that HT Rx/Tx STBC is disabled by default for hwsim driver > > This fails for me: > > START ap_ht_stbc_disabled 2/4 > Exception: STA[0]: TX STBC should be disabled, actual value: 1 > Exception: STA[0]: TX STBC should be disabled, actual value: 1 > FAIL ap_ht_stbc_disabled 0.260623 2019-12-30 16:37:16.001906 > > > - ap_ht_stbc_tx > > make sure that Tx STBC can be properly enabled for hwsim driver > > using wpa_s 'tx_stbc' configuration option > > This passed. > > > - ap_ht_stbc_rx > > make sure that Tx STBC can be properly enabled for hwsim driver > > using wpa_s 'tx_stbc' configuration option > > This fails: > > START ap_ht_stbc_rx 4/4 > Exception: STA[0]: RX STBC expected 1, actual 3 > Exception: STA[0]: RX STBC expected 1, actual 3 > FAIL ap_ht_stbc_rx 0.26011 2019-12-30 16:37:16.421911 > > > What is the expected behavior for these with the current mac80211 > snapshot? > > > This patch depends on the following hwsim driver change: > > https://patchwork.kernel.org/patch/10752835/ > > This and a fix to that (commit e9f33a8fee53, "mac80211: fix RX STBC > override byte order") are included in the kernel version I tested with. > > -- > Jouni Malinen PGP id EFC895FA > > > > ------------------------------ > > Message: 7 > Date: Mon, 30 Dec 2019 19:34:37 +0200 > From: Jouni Malinen <j@xxxxx> > To: Alfonso S?nchez-Beato <alfonso.sanchez-beato@xxxxxxxxxxxxx> > Cc: hostap@xxxxxxxxxxxxxxxxxxx > Subject: Re: [RFC PATCH 0/2] Do not de-authenticate if WoWLAN is > enabled > Message-ID: <20191230173437.GA22472@xxxxx> > Content-Type: text/plain; charset=utf-8 > > On Thu, Jun 14, 2018 at 11:00:41AM +0200, Alfonso S?nchez-Beato wrote: > > This is a follow-up from > > http://lists.infradead.org/pipermail/hostap/2017-March/thread.html#37365 . > > > > The objective is the same: be able to boot a system using WoWLAN after > > it has been powered off. The implementation is different in that now > > wpa_supplicant_deinit_iface() is called and does most of its work, but > > de-authenticating the interface if WoWLAN is enabled. > > > > Alfonso S?nchez-Beato (1): > > wpa_supplicant: do not de-authenticate if WoWLAN is enabled > > > > Matteo Croce (1): > > nl80211: Add function to check WoWLAN status > > Thanks, applied. > > -- > Jouni Malinen PGP id EFC895FA > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Hostap mailing list > Hostap@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/hostap > > > ------------------------------ > > End of Hostap Digest, Vol 51, Issue 42 > ************************************** _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
