Re: wowlan wpa_supplicant_remove_iface return value

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux