Scan trigger failed: ret=-22 (Invalid argument)

Hello,

I use wpa_supplicant in Debian GNU/Linux unstable.
I have stuck in a problem with wpa_supplicant 2.6. After upgrading
wpa_supplicant from 2.4 to 2.6 my laptop (MacBook Air with wifi chip
"Broadcom Limited BCM4360 802.11ac Wireless Network Adapter
[14e4:43a0] (rev 03)",
with broadcom-sta's wl kernel module) fails to start scanning AP repeatedly
with the following (-ddd) messages:

wlp3s0: State: DISCONNECTED -> SCANNING
wlp3s0: Starting AP scan for wildcard SSID (Interleave with specific)
wlp3s0: Add radio work 'scan'@0x55fff6d144c0
wlp3s0: First radio work item in the queue - schedule start immediately
wlp3s0: Starting radio work 'scan'@0x55fff6d144c0 after 0.000011 second wait
wlp3s0: nl80211: scan request
nl80211: Scan extra IEs - hexdump(len=6): 7f 04 00 00 0a 02
nl80211: Scan trigger failed: ret=-22 (Invalid argument)
wlp3s0: State: SCANNING -> DISCONNECTED
nl80211: Set wlp3s0 operstate 0->0 (DORMANT)
netlink: Operstate: ifindex=2 linkmode=-1 (no change), operstate=5
(IF_OPER_DORMANT)
wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
wlp3s0: Radio work 'scan'@0x55fff6d144c0 done in 0.000103 seconds
wlp3s0: radio_work_free('scan'@0x55fff6d144c0: num_active_works --> 0
wlp3s0: Setting scan request: 1.000000 sec
EAPOL: disable timer tick
wlp3s0: State: DISCONNECTED -> SCANNING
(snip)

This has been reported more than a year ago with wpa_supplicant version 2.5 to
Debian's bug report system: https://bugs.debian.org/833507 (wpasupplicant:
Unable to connect WLAN (wlan0: CTRL-EVENT-SCAN-FAILED ret=-22)).

I have bisected commits between 2.4 and 2.6 and found the commit around 2.5-dev
https://w1.fi/cgit/hostap/commit/?id=ad4430971fb90cffe31c872e0e0e6cc8781048be
is the cause of the problem.
It looks like the current wl kernel module does not accept a Probe Request
frame with at least some part of the Extended Capabilities element.

wpas_ext_capab_byte function in wpa_supplicant/wpa_supplicant.c unconditionally
sets WNM-related values. Disabling the code like this


my machine restores to work well as before:

wlp3s0: State: DISCONNECTED -> SCANNING
wlp3s0: Starting AP scan for wildcard SSID (Interleave with specific)
wlp3s0: Add radio work 'scan'@0x5557661af4a0
wlp3s0: First radio work item in the queue - schedule start immediately
wlp3s0: Starting radio work 'scan'@0x5557661af4a0 after 0.000008 second wait
wlp3s0: nl80211: scan request
Scan requested (ret=0) - scan timeout 10 seconds
nl80211: Event message available
nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlp3s0
wlp3s0: nl80211: Scan trigger
wlp3s0: Event SCAN_STARTED (47) received
wlp3s0: Own scan request started a scan in 0.000062 seconds

Likewise a CONFIG_MBO block (several lines below the patch) would also need to
be disabled, which I have not tested yet because Debian's .config does not set
this option.

While one of my collegues uses Lenovo Thinkpad laptop, with Intel's iwlwifi
kernel module, which works with normal wpa_supplicant 2.6 without any problems.
So it should switch depending on the kernel module used.

I think one way to fix it would be to add some configuration variable for each
network (via ctrl_iface/dbus and/or in wpa_supplicant.conf(5)) to decide
whether it should emit WNM-related values or not and set the variable by hand
or an external program like NetworkManager depending on the kernel module the
network interface uses.

Any ideas?

Thanks in advance,

On 23/12/17 08:14, YOSHINO Yoshihito wrote:
> Hello,
> 
> I use wpa_supplicant in Debian GNU/Linux unstable.
> I have stuck in a problem with wpa_supplicant 2.6. After upgrading
> wpa_supplicant from 2.4 to 2.6 my laptop (MacBook Air with wifi chip
> "Broadcom Limited BCM4360 802.11ac Wireless Network Adapter
> [14e4:43a0] (rev 03)",
> with broadcom-sta's wl kernel module) fails to start scanning AP repeatedly
> with the following (-ddd) messages:

<snip>

> This has been reported more than a year ago with wpa_supplicant version 2.5 to
> Debian's bug report system: https://bugs.debian.org/833507 (wpasupplicant:
> Unable to connect WLAN (wlan0: CTRL-EVENT-SCAN-FAILED ret=-22)).
> 
> I have bisected commits between 2.4 and 2.6 and found the commit around 2.5-dev
> https://w1.fi/cgit/hostap/commit/?id=ad4430971fb90cffe31c872e0e0e6cc8781048be
> is the cause of the problem.
> It looks like the current wl kernel module does not accept a Probe Request
> frame with at least some part of the Extended Capabilities element.
> 
> wpas_ext_capab_byte function in wpa_supplicant/wpa_supplicant.c unconditionally
> sets WNM-related values. Disabling the code like this

<snip>

> Likewise a CONFIG_MBO block (several lines below the patch) would also need to
> be disabled, which I have not tested yet because Debian's .config does not set
> this option.
> 
> While one of my collegues uses Lenovo Thinkpad laptop, with Intel's iwlwifi
> kernel module, which works with normal wpa_supplicant 2.6 without any problems.
> So it should switch depending on the kernel module used.
> 
> I think one way to fix it would be to add some configuration variable for each
> network (via ctrl_iface/dbus and/or in wpa_supplicant.conf(5)) to decide
> whether it should emit WNM-related values or not and set the variable by hand
> or an external program like NetworkManager depending on the kernel module the
> network interface uses.
> 
> Any ideas?

I, too, would like to have this issue resolved. Jouni, what would you
recommend as a temporary workaround?

I’m forwarding a follow-up to a thread named "Scan trigger failed:
ret=-22 (Invalid argument)". There’s nothing actually private in this
email, so I suppose it is fine. As the result of this I have
temporarily disabled WNM support in Debian’s wpa-supplicant, but I
keep getting requests to re-enable in again, but I’m hesitant to
re-enable it.

I’m unsure what can be done about this.

---------- Forwarded message ---------
From: YOSHINO Yoshihito <yy.y.ja.jp@gmail.com>
Date: Wed, 27 Dec 2017 at 18:05
Subject: Re: Scan trigger failed: ret=-22 (Invalid argument)
To: Andrew Shadura <andrew@shadura.me>


Hi Andrew,

On Wed, Dec 27, 2017 at 8:39 PM, Andrew Shadura <andrew@shadura.me> wrote:
> Until this is fixed (hopefully) upstream, how do you think, what would
> be an impact of setting CONFIG_WNM=n? That should work around the
> issue for you, but how much of a degraded experience will it be for
> everyone else?

Hmm ... many other distributions seem to disable CONFIG_WNM:

Fedora (1:2.6-12)
https://src.fedoraproject.org/rpms/wpa_supplicant/blob/master/f/build-config

openSUSE Tumbleweed (2.6-4.2)
http://download.opensuse.org/tumbleweed/repo/src-oss/suse/src/wpa_supplicant-2.6-4.2.src.rpm

openSUSE Leap 42.3 (2.2-13.1)
https://download.opensuse.org/repositories/openSUSE:/Leap:/42.3:/Update/standard/src/wpa_supplicant-2.2-13.1.src.rpm

Arch Linux (1:2.6-11)
https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/wpa_supplicant

Gentoo (2.6-r4)
https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/wpa_supplicant/wpa_supplicant-2.6-r4.ebuild

FreeBSD port (2.6_2)
https://svnweb.freebsd.org/ports/head/security/wpa_supplicant/Makefile?view=log

FreeBSD base (2.4)
https://svnweb.freebsd.org/base/head/usr.sbin/wpa/wpa_supplicant/Makefile?view=log
https://svnweb.freebsd.org/base/head/usr.sbin/wpa/Makefile.inc?view=log
https://svnweb.freebsd.org/base/head/usr.sbin/wpa/Makefile.crypto?view=log

NetBSD (2.6nb1)
https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/net/wpa_supplicant/files/

OpenBSD (2.6p1)
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/wpa_supplicant/files/config

Upstream considers this experimental and incomplete, and the example config
disables this:
https://w1.fi/cgit/hostap/tree/wpa_supplicant/defconfig
> # Wireless Network Management (IEEE Std 802.11v-2011)
> # Note: This is experimental and not complete implementation.
> #CONFIG_WNM=y

(BTW, "CONFIG_WNM=n" does not disable this:
> # This file lists the configuration options that are used when building the
> # wpa_supplicant binary. All lines starting with # are ignored. Configuration
> # option lines must be commented out complete, if they are not to be included,
> # i.e., just setting VARIABLE=n is not disabling that variable.
)

I have also disabled this and it seems to work fine. I suppose it is reasonable
to disable this.

Note also that NM works fine on my machine without no-mac-addr-change.conf if
this is disabled or my temporary patch is applied.

Debian has enabled this since 2.2-1 because of the suggestion by Gerald Turner
https://bugs.debian.org/718651#42
but I do not see the exact reason why he has activated this.

Regards,
--
YOSHINO Yoshihito <yy.y.ja.jp@gmail.com>


--
Cheers,
  Andrej

Arend, did you see this? I just came across it due to the follow-up,
looks like I missed it over Christmas too :)

> I use wpa_supplicant in Debian GNU/Linux unstable.
> I have stuck in a problem with wpa_supplicant 2.6. After upgrading
> wpa_supplicant from 2.4 to 2.6 my laptop (MacBook Air with wifi chip
> "Broadcom Limited BCM4360 802.11ac Wireless Network Adapter
> [14e4:43a0] (rev 03)",
> with broadcom-sta's wl kernel module) fails to start scanning AP repeatedly
> with the following (-ddd) messages:


broadcom-sta is fair game for breaking to me, but others will obviously
disagree ;-)



> 
> It looks like the current wl kernel module does not accept a Probe Request
> frame with at least some part of the Extended Capabilities element.

That's really strange, why would wl.ko code care about the extended
capabilities that are fully implemented by hostapd anyway?

> wpas_ext_capab_byte function in wpa_supplicant/wpa_supplicant.c unconditionally
> sets WNM-related values. Disabling the code like this
> 
> --- a/wpa_supplicant/wpa_supplicant.c    2017-12-16 10:21:25.000000000 +0900
> +++ b/wpa_supplicant/wpa_supplicant.c    2017-12-23 14:23:41.244680071 +0900
> @@ -1428,13 +1428,16 @@
>          break;
>      case 2: /* Bits 16-23 */
>  #ifdef CONFIG_WNM
> -        *pos |= 0x02; /* Bit 17 - WNM-Sleep Mode */
> -        *pos |= 0x08; /* Bit 19 - BSS Transition */
> +        if (0) { /* FIXME switch depending on the kernel module */
> +            *pos |= 0x02; /* Bit 17 - WNM-Sleep Mode */
> +            *pos |= 0x08; /* Bit 19 - BSS Transition */
> +        }
>  #endif /* CONFIG_WNM */
>          break;
>      case 3: /* Bits 24-31 */
>  #ifdef CONFIG_WNM
> -        *pos |= 0x02; /* Bit 25 - SSID List */
> +        if (0) /* FIXME switch depending on the kernel module */
> +            *pos |= 0x02; /* Bit 25 - SSID List */
>  #endif /* CONFIG_WNM */
>  #ifdef CONFIG_INTERWORKING
>          if (wpa_s->conf->interworking)
> 
> my machine restores to work well as before:
[...]
> Likewise a CONFIG_MBO block (several lines below the patch) would also need to
> be disabled, which I have not tested yet because Debian's .config does not set
> this option.
> 
> While one of my collegues uses Lenovo Thinkpad laptop, with Intel's iwlwifi
> kernel module, which works with normal wpa_supplicant 2.6 without any problems.
> So it should switch depending on the kernel module used.

Not really. The kernel should just not reject this... but I also realize
we have little influence over wl.ko.

johannes

On 1/13/2019 9:07 PM, Johannes Berg wrote:
> Arend, did you see this? I just came across it due to the follow-up,
> looks like I missed it over Christmas too :)

I did. Just did not get to looking into it.

>> I use wpa_supplicant in Debian GNU/Linux unstable.
>> I have stuck in a problem with wpa_supplicant 2.6. After upgrading
>> wpa_supplicant from 2.4 to 2.6 my laptop (MacBook Air with wifi chip
>> "Broadcom Limited BCM4360 802.11ac Wireless Network Adapter
>> [14e4:43a0] (rev 03)",
>> with broadcom-sta's wl kernel module) fails to start scanning AP repeatedly
>> with the following (-ddd) messages:
>
> broadcom-sta is fair game for breaking to me, but others will obviously
> disagree ;-)

The broadcom-sta is no longer maintained. It exists to be provided to 
some laptop manufacturers, but has not been changed for quite a while 
now. So all bets are of. I considered keeping it compile and work 
against newer kernels on github or so, but have not done so yet and not 
sure I will given the amount of time I have for open-source related work 
these days.

>>
>> It looks like the current wl kernel module does not accept a Probe Request
>> frame with at least some part of the Extended Capabilities element.
> 
> That's really strange, why would wl.ko code care about the extended
> capabilities that are fully implemented by hostapd anyway?

Not sure either. The latest source I have here (broadcom-wl 
6.30.223.271) shows that the cfg80211 .scan() callback does not even 
pass the IEs. Are you using a different version or are you using WEXT?

Regards,
Arend