Bug 1703745

Summary: wpa_supplicant throws a CTRL-EVENT-SCAN-FAILED error with broadcom-wl-6.30.223.271 driver
Product: [Fedora] Fedora Reporter: Vinu Moses <vinu>
Component: wpa_supplicantAssignee: Davide Caratti <dcaratti>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 30CC: adrien-xx-redhatbz, andrew, antony.vennard, awilliam, ayurtsev, bas7, benjamin.masse, berzerkatives, bgalvani, blueowl, bnocera, casper, darrenjmcpherson, dbloodwxp, dcaratti, dcbw, dhirajhazra, dmanlfc, edward.lara.lara, fangbingw, fedora, gavin, gggsartori, hello, hockmanj, ivnmad, johndoe, john.j5live, keramidasceid, koen.schram, kwizart, lkundrak, mathstuf, mattias.costantini, musikplayr, neil, nicolas.vieville, niklas.onfedora, nsstrickland, plazaga, redhat-bugzilla, redhat, sagarun, seungjin, shenada, twegener, vaaghoofdharry
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: https://fedoraproject.org/wiki/Common_F30_bugs#broadcom-wl-mesh
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-24 14:23:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
NetworkManager config file none

Description Vinu Moses 2019-04-28 04:23:13 UTC
Description of problem:
After upgrade to f30 from f29, my TPLink Archer T9E PCIE wi-fi card (Broadcom BCM4360 chip) does not work. It worked fine with f29.

The wi-fi adapter is recognised and networks are displayed. When trying to connect to a network, it hangs and the logs fill up with the following error:
wpa_supplicant[1186]: wlp4s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1


Version-Release number of selected component (if applicable):
wpa_supplicant-2.7-5.fc30.x86_64
broadcom-wl-6.30.223.271-10.fc30.noarch

How reproducible:
Always

Steps to Reproduce:
1. Upgrade from 29 to f30 (using dnf system-upgrade)
2. 
3.

Actual results:
Wi-fi adapter displays networks but hangs while trying to connect to a network, and the logs fill up with a CTRL-EVENT-SCAN-FAILED error.

Expected results:
Wi-fi adapter should connect seamlessly to a network

Additional info:
04:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter (rev 03)

This seems similar to a bug described in ArchLinux (https://bugs.archlinux.org/task/61119)

Comment 1 dmanlfc 2019-04-28 11:08:19 UTC
Same problem here on a Macbook Air.
Worked fine on Fedora 29.
Now on Fedora 30 using dnf update immediately breaks wifi.

Apr 28 20:49:05 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:06 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:07 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:08 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:09 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:13 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:14 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:15 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:16 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:17 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr 28 20:49:18 dmansMacbookAir wpa_supplicant[1808]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1

Plugging in another wifi adapter works. Seems to be related to the Broadcom chipset.

Comment 2 dmanlfc 2019-04-28 11:32:51 UTC
Note: Downgrading wpa_supplicant resolved the issue for me.

https://rpmfind.net/linux/RPM/fedora/29/x86_64/w/wpa_supplicant-2.6-17.fc29.x86_64.html

This is not ideal due to the security issues with older versions of wpa_supplicant.

Comment 3 Vinu Moses 2019-04-29 01:04:14 UTC
(In reply to dmanlfc from comment #1)
> Same problem here on a Macbook Air.
> Worked fine on Fedora 29.
> Now on Fedora 30 using dnf update immediately breaks wifi.
> 
> Plugging in another wifi adapter works. Seems to be related to the Broadcom
> chipset.

That's what I've done as well; using another USB wi-fi adapter with a different chipset. The problem seems to be some incompatibility between the wpa_supplicant and the broadcom-wl driver.

Comment 4 Vinu Moses 2019-04-29 01:05:43 UTC
(In reply to dmanlfc from comment #2)
> Note: Downgrading wpa_supplicant resolved the issue for me.
> 
> https://rpmfind.net/linux/RPM/fedora/29/x86_64/w/wpa_supplicant-2.6-17.fc29.
> x86_64.html
> 
> This is not ideal due to the security issues with older versions of
> wpa_supplicant.

wpa_supplicant 2.8 is already out. Would broadcom-wl work with that?

Comment 5 dmanlfc 2019-05-01 11:56:27 UTC
I have built wpa_supplicant 2.8 which works fine with the broadcom-wl driver :-)

Comment 6 Vinu Moses 2019-05-01 14:46:36 UTC
(In reply to dmanlfc from comment #5)
> I have built wpa_supplicant 2.8 which works fine with the broadcom-wl driver
> :-)

Just checked on koji... there is no official wpa_supplicant 2.8 build yet. I'll be happy to check as soon as they are available.

Comment 7 Davide Caratti 2019-05-02 09:43:14 UTC
(In reply to Vinu Moses from comment #6)
> (In reply to dmanlfc from comment #5)
> > I have built wpa_supplicant 2.8 which works fine with the broadcom-wl driver
> > :-)
> 
> Just checked on koji... there is no official wpa_supplicant 2.8 build yet.
> I'll be happy to check as soon as they are available.

can you try the rpms at

https://koji.fedoraproject.org/koji/taskinfo?taskID=34574054

and see if the problem is fixed?
thank you in advance!

Comment 8 dmanlfc 2019-05-02 11:56:33 UTC
Hi David,

Sorry your x86_64 build failed on my laptop - same problem as per this bug report.

As soon as I copied over my built files the wifi worked just fine.
I suspect the .config options for wpa_supplicant are different between the builds. 

I followed the instruction here for my build...
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/wpa_supplicant.html

Dan

Comment 9 Davide Caratti 2019-05-02 12:12:06 UTC
(In reply to dmanlfc from comment #8)

hi Dan, thanks a lot for testing.

maybe this question is pedantic, but it's worth a check.
Can you please ensure that you restarted the systemd unit after you replaced the RPM ?

# systcemctl restart wpa_supplicant.service

(rationale: the current systemd unit does not restart the process, so we need a restart of the service to ensure that the binary daemon from the new rpm is in execution).

thanks!

Comment 10 dmanlfc 2019-05-02 12:34:04 UTC
Hi Dave,

The laptop was fully rebooted when testing.

Dan

Comment 11 Vinu Moses 2019-05-03 09:55:17 UTC
(In reply to Davide Caratti from comment #7)
> can you try the rpms at
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=34574054
> 
> and see if the problem is fixed?
> thank you in advance!

I installed wpa_supplicant-2.8-1.fc30.x86_64 from koji, rebooted and check. The error persists. I am still unable to connect with this particular broadcom adapter while other adapters connect. The error I get is the same as before:

May  3 15:20:50 vinu wpa_supplicant[1137]: wlp4s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1

Comment 12 Davide Caratti 2019-05-03 10:13:15 UTC
(In reply to Vinu Moses from comment #11)
> (In reply to Davide Caratti from comment #7)
> > can you try the rpms at
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=34574054
> > 
> > and see if the problem is fixed?
> > thank you in advance!
> 
> I installed wpa_supplicant-2.8-1.fc30.x86_64 from koji, rebooted and check.
> The error persists. I am still unable to connect with this particular
> broadcom adapter while other adapters connect. The error I get is the same
> as before:
> 
> May  3 15:20:50 vinu wpa_supplicant[1137]: wlp4s0: CTRL-EVENT-SCAN-FAILED
> ret=-22 retry=1

hello,

thanks for the feedback. According to comment #8 there is a build configuration that does not trigger the problem, I will try a koji scratch build that uses the same configuration and ask you to retry. While at it, can you check dmesg and see if a kernel warning (e.g. in brcmf_cfg80211_set_pmk() )?

thanks!
-- 
davide

Comment 13 Davide Caratti 2019-05-03 12:39:25 UTC
(In reply to Davide Caratti from comment #12)
> (In reply to Vinu Moses from comment #11)
> thanks for the feedback. According to comment #8 there is a build
> configuration that does not trigger the problem,

according to http://lists.infradead.org/pipermail/hostap/2019-January/039341.html, the problem might be caused by enablement of CONFIG_MESH in the build-config, that happened in with 2.7-2. If the above guess is correct, is correct, version 2.7-1 should also work with f30: please check.

> I will try a koji scratch
> build that uses the same configuration and ask you to retry. 

done:  http://koji.fedoraproject.org/koji/taskinfo?taskID=34599724

this has the same build-config as the one mentioned in comment #8: please check.
thanks,
-- 
davide

Comment 14 Vinu Moses 2019-05-03 13:29:58 UTC
(In reply to Davide Caratti from comment #12)
> thanks for the feedback. According to comment #8 there is a build
> configuration that does not trigger the problem, I will try a koji scratch
> build that uses the same configuration and ask you to retry. While at it,
> can you check dmesg and see if a kernel warning (e.g. in
> brcmf_cfg80211_set_pmk() )?

I did a dmesg | grep -i brcmf and did not pick up any similar kernel warnings in my dmesg output. I'll try your koji scratch build (that you mentioned in comment #13) once it's built. 

Thank you for helping.
--Vinu.

Comment 15 Vinu Moses 2019-05-03 14:12:52 UTC
(In reply to Davide Caratti from comment #13)
> (In reply to Davide Caratti from comment #12)
> > (In reply to Vinu Moses from comment #11)
> > thanks for the feedback. According to comment #8 there is a build
> > configuration that does not trigger the problem,
> 
> according to
> http://lists.infradead.org/pipermail/hostap/2019-January/039341.html, the
> problem might be caused by enablement of CONFIG_MESH in the build-config,
> that happened in with 2.7-2. If the above guess is correct, is correct,
> version 2.7-1 should also work with f30: please check.
> 
> > I will try a koji scratch
> > build that uses the same configuration and ask you to retry. 
> 
> done:  http://koji.fedoraproject.org/koji/taskinfo?taskID=34599724
> 
> this has the same build-config as the one mentioned in comment #8: please
> check.

Your koji scratch build (from https://koji.fedoraproject.org/koji/taskinfo?taskID=34599725), wpa_supplicant-2.8-1.fc30.bz1703745rebuild.x86_64, seems to solve the problem for me. The broadcom usb wi-fi adapter now connects and there are no errors thrown up in the logs (/var/log/messages).

Thank you for the fix, Davide! I really appreciate it.

Comment 16 Davide Caratti 2019-05-03 15:36:35 UTC
(In reply to Vinu Moses from comment #15)
> (In reply to Davide Caratti from comment #13)
> > (In reply to Davide Caratti from comment #12)
> > > (In reply to Vinu Moses from comment #11)
> > > thanks for the feedback. According to comment #8 there is a build
> > > configuration that does not trigger the problem,

@Vinu,
thanks for following up!

@Dan, maybe you can help us narrowing down the problem to a single knob, my guess is CONFIG_MESH.
Since you already are using hostapd-2.8 built from the w1.fi repository, and your bcm4360 connects successfully, can you try rebuilding using the configuration file at [1], with CONFIG_MESH disabled (i.e. commenting line 578)?

regards,
-- 
davide

[1] https://src.fedoraproject.org/rpms/wpa_supplicant/blob/master/f/build-config

Comment 17 dmanlfc 2019-05-04 04:43:28 UTC
Hi Davide,

Yes CONFIG_MESH is the problem.
- When enabled & service restarted - wifi fails
- When built as disabled etc - wifi works fine

Dan

Comment 18 Vasilis Keramidas 2019-05-04 15:27:37 UTC
I have the exact same problem and the package on comment 13 solved it.
Maybe it is a good idea to add this bug at https://fedoraproject.org/wiki/Common_F30_bugs so people are aware when they are upgrading to f30

Comment 19 hockmanj 2019-05-05 16:07:34 UTC
Had the exact same problem and the package on comment 13 fixed it. Agree it might be a good idea to add to the common bug list.

Comment 20 Davide Caratti 2019-05-10 16:27:20 UTC
(In reply to Davide Caratti from comment #13)
> (In reply to Davide Caratti from comment #12)
> > (In reply to Vinu Moses from comment #11)
> according to
> http://lists.infradead.org/pipermail/hostap/2019-January/039341.html, the
> problem might be caused by enablement of CONFIG_MESH in the build-config,
> that happened in with 2.7-2. If the above guess is correct, is correct,
> version 2.7-1 should also work with f30: please check.

Let's recap of the current state of the analysis: a bug, probably in the broadcom-wl driver, causes scan failures. The problem does not happen if the supplicant code is compiled with CONFIG_MESH commented out in build-config. Disabling CONFIG_MESH might interfere with other ongoing developments, e.g. NetworkManager: while a fix needs to be done somewhere (probably in the driver), using a build with CONFIG_MESH commented out is a viable workaround for "normal" wi-fi connectivity.

> > I will try a koji scratch
> > build that uses the same configuration and ask you to retry. 
> 
> done:  http://koji.fedoraproject.org/koji/taskinfo?taskID=34599724

the above URL contains a scratch build, so binaries might disappear soon. Moreover, its build configuration is the same as the one in comment #8 - so it disables more knobs than we need on f30. I just rebuilt the v2.8 package, with only CONFIG_MESH turned off in my copr repository [1], like Dan did in comment #17: please try this and see if it connects successfully.

After that, unless somebody disagrees, I will change the bug component according to the analysis and try to report the bug to broadcom-wl developers. 
Any feedback appreciated. Thanks a lot for the collaboration!

-- 
davide


[1] https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/build/907266/

Comment 21 Vasilis Keramidas 2019-05-10 18:12:43 UTC
Hello Davide,

The copr repo you posted does not have a x86_64 version of the package for fedora 30, so it could not work on my system.
Is it possible to create a x86_64 version of the package for fedora 30?

Thank you,
Vasilis

Comment 22 Vinu Moses 2019-05-12 04:37:41 UTC
(In reply to Davide Caratti from comment #20)
> the above URL contains a scratch build, so binaries might disappear soon.
> Moreover, its build configuration is the same as the one in comment #8 - so
> it disables more knobs than we need on f30. I just rebuilt the v2.8 package,
> with only CONFIG_MESH turned off in my copr repository [1], like Dan did in
> comment #17: please try this and see if it connects successfully.
> 
> After that, unless somebody disagrees, I will change the bug component
> according to the analysis and try to report the bug to broadcom-wl
> developers. 
> Any feedback appreciated. Thanks a lot for the collaboration!
> 
> [1]
> https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/build/907266/

hello Davide,

As mentioned by Vasilis, there is no x86 64bit build. Could you provide one to test, please?

I also noticed that a new wpa_supplicant package has been submitted to bodhi for testing. Does it include a fix for this bug, as I don't see it in the changelog?
https://bodhi.fedoraproject.org/updates/FEDORA-2019-ff1b728d09

Comment 23 Davide Caratti 2019-05-13 08:43:47 UTC
(In reply to Vasilis Keramidas from comment #21)
> Hello Davide,
> 
> The copr repo you posted does not have a x86_64 version of the package for
> fedora 30, so it could not work on my system.
> Is it possible to create a x86_64 version of the package for fedora 30?

(In reply to Vinu Moses from comment #22)
> (In reply to Davide Caratti from comment #20)
> 
> As mentioned by Vasilis, there is no x86 64bit build. Could you provide one
> to test, please?

I made a mess of the build configuration, sorry for that. Please try this:
https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/build/907850/

> I also noticed that a new wpa_supplicant package has been submitted to bodhi
> for testing. Does it include a fix for this bug, as I don't see it in the
> changelog?
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-ff1b728d09

the version on bodhi is built from the official repository, has CONFIG_MESH enabled
and you will see this bug still present. 
In order to fix this bug in a definitive way, Broadcom must patch its kernel driver,
so  that it's not confused anymore by the extra_ie containing WLAN_EID_MESH_ID (I
will understand how to report a bug this week).

Thanks for testing!
-- 
davide

Comment 24 Vinu Moses 2019-05-13 09:46:59 UTC
(In reply to Davide Caratti from comment #23)
> I made a mess of the build configuration, sorry for that. Please try this:
> https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/build/907850/

Hello Davide,
This build, mentioned above, (wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm) works for me.

> 
> > I also noticed that a new wpa_supplicant package has been submitted to bodhi
> > for testing. Does it include a fix for this bug, as I don't see it in the
> > changelog?
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-ff1b728d09
> 
> the version on bodhi is built from the official repository, has CONFIG_MESH
> enabled
> and you will see this bug still present. 
> In order to fix this bug in a definitive way, Broadcom must patch its kernel
> driver,
> so  that it's not confused anymore by the extra_ie containing
> WLAN_EID_MESH_ID (I
> will understand how to report a bug this week).

As we already know that there is a bug involved, would it not be a good idea to disable CONFIG_MESH in this build, until Broadcom patches it's kernel driver?

Comment 25 Davide Caratti 2019-05-13 10:22:36 UTC
(In reply to Vinu Moses from comment #24)
> (In reply to Davide Caratti from comment #23)
>
> As we already know that there is a bug involved, would it not be a good idea
> to disable CONFIG_MESH in this build, until Broadcom patches it's kernel
> driver?

If the driver was opensource, I would say it's ok to temporarily keep CONFIG_MESH
disabled, until the fix is propagated to the kernel. But in this case, we don't
have any knowledge about when Broadcom is going to push a fix, and when this fix
is going to be packaged for the Fedora kernel.

So, disabling CONFIG_MESH in the build might "hide" the bug and thus slow-down
the release of a fix. Moreover, other projects (e.g. NetworkManager) might be
interested in running the supplicant with mesh support: my proposal is to keep
this BZ open to track the need of a fix in the broadcom-wl driver. WDYT?

-- 
davide

Comment 26 Antoine Cotten 2019-05-13 15:47:06 UTC
(In reply to Davide Caratti from comment #25)
> we don't have any knowledge about when Broadcom is going to push a fix, and when this
> fix is going to be packaged for the Fedora kernel.

Broadcom hasn't updated their driver for a while. The code available on their website has stopped working since Linux 4.7. All patches since that release have been contributed by the community, through Debian and Arch mostly.

A few relevant resources:
* https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=broadcom-sta
* https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/broadcom-wl-dkms

My take on this bug is that a potential fix can only come from the community considering the state of that driver.

Comment 27 Dark Shenada 2019-05-14 16:35:43 UTC
CONFIG_MESH may not the root cause.

Firstval, wpa_supplicant-2.8-1.fc30.bz1703745rebuild.src.rpm works for me.
Neither wpa_supplicant-2.8-2.fc30.src.rpm or wpa_supplicant-2.8-1.fc30.src.rpm works for me.

But, wpa_supplicant-2.8-2.fc30.src.rpm + build-config in wpa_supplicant-2.8-1.fc30.bz1703745rebuild.src.rpm works for me.

Device:
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4331 802.11a/b/g/n (rev 02)

KMod:
akmod-wl-6.30.223.271-24.fc30.x86_64

Comment 28 Dark Shenada 2019-05-14 16:43:41 UTC
(In reply to Dark Shenada from comment #27)
> CONFIG_MESH may not the root cause.
> 
> Firstval, wpa_supplicant-2.8-1.fc30.bz1703745rebuild.src.rpm works for me.
> Neither wpa_supplicant-2.8-2.fc30.src.rpm or
> wpa_supplicant-2.8-1.fc30.src.rpm works for me.

Neither wpa_supplicant-2.8-2.fc30.src.rpm or wpa_supplicant-2.8-1.fc30.src.rpm w/o CONFIG_MESH in build-config works for me.

> 
> But, wpa_supplicant-2.8-2.fc30.src.rpm + build-config in
> wpa_supplicant-2.8-1.fc30.bz1703745rebuild.src.rpm works for me.
> 
> Device:
> 03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4331
> 802.11a/b/g/n (rev 02)
> 
> KMod:
> akmod-wl-6.30.223.271-24.fc30.x86_64

Comment 29 Davide Caratti 2019-05-14 17:06:11 UTC
(In reply to Dark Shenada from comment #27)
> CONFIG_MESH may not the root cause.
> 
> Firstval, wpa_supplicant-2.8-1.fc30.bz1703745rebuild.src.rpm works for me.
> Neither wpa_supplicant-2.8-2.fc30.src.rpm or
> wpa_supplicant-2.8-1.fc30.src.rpm works for me.
> 
> But, wpa_supplicant-2.8-2.fc30.src.rpm + build-config in
> wpa_supplicant-2.8-1.fc30.bz1703745rebuild.src.rpm works for me.

both
 - wpa_supplicant-2.8-1.fc30.src.rpm
 - wpa_supplicant-2.8-2.fc30.src.rpm

are built with CONFIG_MESH=y, so they will trigger the bug on  wl-6.30.223.
as per comment #23, 2.8 build without CONFIG_MESH is available at

https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/build/907850/

(In reply to Antoine Cotten from comment #26)
> (In reply to Davide Caratti from comment #25)
> > we don't have any knowledge about when Broadcom is going to push a fix, and when this
> > fix is going to be packaged for the Fedora kernel.
> 
> Broadcom hasn't updated their driver for a while. The code available on
> their website has stopped working since Linux 4.7. All patches since that
> release have been contributed by the community, through Debian and Arch
> mostly.
> 
> A few relevant resources:
> * https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=broadcom-sta
> *
> https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/
> broadcom-wl-dkms
> 
> My take on this bug is that a potential fix can only come from the community
> considering the state of that driver.

Ouch.

that driver is distributed in binary with a small adaptation layer to Linux cfg80211.
maybe it's possible a quirk where the IE having WLAN_EID_MESH_ID is removed from the
scan request, and that's enough to survive (but I'm unsure if a similar bug will then
be triggered at the association). Anybody wants to try?

Comment 30 Zex 2019-05-16 06:07:54 UTC
wpa_supplicant-2.8-1.fc30.bz1703745rebuild didn't work for me.

Comment 31 Herald van der Breggen 2019-05-16 08:28:28 UTC
YES, just installing wpa_supplicant-2.8-1.fc30.bz1703745rebuild.x86_64.rpm fixed it for me. (hardware: Broadcom BCM43b1 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334))

Thanks!

Comment 32 Ming 2019-05-16 18:27:26 UTC
We are all over the radar:

Just tried the wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm and couldn't get it to work. But wpa_supplicant-2.8-1.fc30.bz1703745rebuild.x86_64.rpm works for me.

wpa_supplicant-2.8-1.fc30.bz1703745rebuild works for Herlad, comment 31, and me but not for Zex ,comment 30.
wpa_supplicant-2.8-2.fc30.bz1703745 works for Vinu ,comment 24, but not for me.

This is really a good one.

Comment 33 Vasilis Keramidas 2019-05-16 18:57:25 UTC
My two cents:

The dcaratti/wpa_supplicant copr works fine on my pc

sudo dnf list wpa_supplicant
Last metadata expiration check: 0:00:07 ago on Πεμ 16 Μαΐ 2019 09:56:30 μμ EEST.
Installed Packages
wpa_supplicant.x86_64              1:2.8-2.fc30.bz1703745                            @dcaratti-wpa_supplicant

Comment 34 Herald van der Breggen 2019-05-16 19:26:02 UTC
Ah! I upgraded from 2.8-1.fc30.bz1703745rebuild to 2.8-2.fc30.bz1703745 (comment 33 and comment 24) and this works also for me! Thanks!

Comment 35 Zex 2019-05-17 03:38:42 UTC

For me, it's a bit interesting though. I was using a Kali2 to rescue Fedora30, meanwhile, Kali2 was upgrading itself. When it's done the same issue happened, wpa application version on Kali2 is 2.7+git20190128+0c1e29f-5 amd64. 

Then I tried 
1. setup an insecure hotspot, both of them are fine.
2. set invisible but secure wifi to visible, it works.
3. set it back to invisible, both failed.

Some disturbing wpa supplicant logs from F30:

100+ of "wlo1: CTRL-EVENT-BEACON-LOSS" followed by a
"wlo1: CTRL-EVENT-DISCONNECTED bssid=xxx reason=3 locally_generated=1"

The following always show

"dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.P2PDevice dbus_property=P2PDeviceConfig getter failed"

Comment 36 Ivan Virgili 2019-05-17 15:04:59 UTC
I initially upgraded from F29 to F30, but I then performed a clean F30 installation to double check if the upgrade was the issue.
In both cases my issue is that F30 takes ages to connect to the wifi.
Sometimes it works after 5 attempts, other times it can take 40 attempts.
If I try to change network, same issue again.
Once it connects, everything works as expected.

I tried different versions of wpa_supplicant from wpa_supplicant-2.7-5.fc30 upwards, but no luck.
Currently on wpa_supplicant-1:2.8-2.fc30.x86_64

$ lspci |grep -i wireless
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter (rev 03)

This is what I can see when it hangs, but there might be more info I can provide with a different command (suggestions?):

$ nmcli d
DEVICE  TYPE      STATE                     CONNECTION 
wlp3s0  wifi      connecting (configuring)  MyNetwork   
lo      loopback  unmanaged                 --  


Ivan

Comment 37 Ivan Virgili 2019-05-17 15:28:10 UTC
Just tested with 

wpa_supplicant-2.6-20.fc30.x86_64.rpm
wpa_supplicant-2.7-1.fc30.x86_64.rpm

and it connects on first attempt.

The issue starts from wpa_supplicant-2.7-2.fc30.x86_64.rpm onwards.

Ivan

Comment 38 Adrien Bustany 2019-05-17 16:04:40 UTC
wpa_supplicant-2.8-1.fc30.bz1703745rebuild.x86_64 also fixes the issue for me on a MacBookPro11,1 with the BCM4360 802.11ac Wireless Network Adapter

Comment 39 Ivan Virgili 2019-05-17 21:50:42 UTC
wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm works for me as well.

$ lspci |grep -i wireless
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter (rev 03)

Comment 40 Jason Elwell 2019-05-18 00:26:26 UTC
Firstly, thank you, all, especially Davide Caratti for the builds.

wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm also works for me (from https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/build/907850/) after a reboot (unnatural) or BOTH:
$ sudo systemctl stop NetworkManager
$ sudo systemctl stop wpa_supplicant
then:
$ sudo systemctl start NetworkManager

$ lspci |grep -i broadcom
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n (rev 01)

$ rpm -q akmod-wl
akmod-wl-6.30.223.271-24.fc30.x86_64

$ uname -r
5.0.16-300.fc30.x86_64

I rebuilt wpa_supplicant-2.6-17.fc29.src.rpm and wpa_supplicant-2.7-1.fc29.src.rpm, which appear to work just fine, and was fun to relearn.  The default repo wpa_supplicant-2.8-1.fc31.x86_64.rpm and wpa_supplicant-2.8-2.fc30.x86_64.rpm don't work, obviously, or I wouldn't be here :)  The package wpa_supplicant-2.8-1.fc30.bz1703745rebuild.x86_64.rpm appears to still work just fine.  But, before testing, you must ALWAYS 'systemctl stop wpa_supplicant'

For those of you playing along at home, to enable Davide's copr repo for this, so a simple upgrade will auto install it (until the default version is higher): 'sudo dnf copr enable dcaratti/wpa_supplicant'  You can disable the repo, once it's fixed, with: 'sudo dnf copr remove dcaratti/wpa_supplicant'


If I can help test something, I'm more than happy to help.

Comment 41 gggsartori 2019-05-19 08:52:27 UTC
I have the same problem as above comment

lspci |grep -i broadcom
04:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n (rev 01)

rpm -q akmod-wl
akmod-wl-6.30.223.271-24.fc30.x86_64

uname -r
5.0.16-300.fc30.x86_64

I've downloaded source code and compiled wpa_supplicant following this link:
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/wpa_supplicant.html
with the same config file.
I stripped and replaced executable wpa_supplicant in /usr/sbin , restarted service wpa_supplicant and now it works.

Comment 42 Nicolas Chauvet (kwizart) 2019-05-19 12:49:54 UTC
Add cc Nicolas Vieville (RPM Fusion broadcom-wl maintainer).
@Nicolas, do you know if there is any flag that can be added to the broadcom driver to avoid the rebuild of wpa-supplicant for f30 ?

Any others advices welcomed.

Comment 43 Nicolas Chauvet (kwizart) 2019-05-19 12:56:13 UTC
Side note on this topic since there are lot of broadcom-wl users.
There is an alternative firmware that can be used for broadcom devices that might works better than the default firmware using the fedora b43 driver.
You can get it with rpmfusion-nonfree-tainted:

dnf remove b43-openfwwf
dnf install rpmfusion-nonfree-tainted
dnf install b43-firmware

and reboot (or reload the b43 driver).

Comment 44 nicolas.vieville 2019-05-19 16:48:49 UTC
(In reply to Nicolas Chauvet (kwizart) from comment #42)

Hello Nicolas,

> Add cc Nicolas Vieville (RPM Fusion broadcom-wl maintainer).
> @Nicolas, do you know if there is any flag that can be added to the broadcom
> driver to avoid the rebuild of wpa-supplicant for f30 ?

I was following this bug report, but as I didn't have upgraded to f30, I 
couldn't experiment with this issue and my BCM4313.

Now that f30 has landed on my laptop, I had this issue too.

As you suggested there was some flags to test and to add in the broadcom 
sources, in order to not have this problem (commenting actually this bug 
report through the new working driver and wpa_supplicant-2.8-2.fc30.x86_64).
 
> Any others advices welcomed.

The new akmod-wl package was build for f30 (and other releases) on 
rpmfusion koji and can be installed for example for f30 from the web page:

http://koji.rpmfusion.org/koji/buildinfo?buildID=11288

The package can be installed now with:

sudo dnf install http://koji.rpmfusion.org/kojifiles/packages/wl-kmod/6.30.223.271/25.fc30/x86_64/akmod-wl-6.30.223.271-25.fc30.x86_64.rpm

It will be available on rpmfusion repository/mirrors in the next days.

Any comment and feedback about this are welcome.

Cordially,


-- 
NVieville

Comment 45 Jason Elwell 2019-05-20 03:09:23 UTC
For me, the Koji build of akmod-wl-6.30.223.271-25.fc30.x86_64.rpm still needs the altered wpa_supplicant build.  I hope I've done it wrong, here is the NON-working config:

$ rpm -q akmod-wl
akmod-wl-6.30.223.271-25.fc30.x86_64
$ uname -r
5.0.16-300.fc30.x86_64
$ modinfo wl
filename:       /lib/modules/5.0.16-300.fc30.x86_64/extra/wl/wl.ko
...
$ rpm -qf /lib/modules/5.0.16-300.fc30.x86_64/extra/wl/wl.ko
kmod-wl-5.0.16-300.fc30.x86_64-6.30.223.271-25.fc30.x86_64
$ rpm -q wpa_supplicant
wpa_supplicant-2.8-2.fc30.x86_64
$ lspci |grep -i broadcom
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n (rev 01)

I even updated to the b43-firmware package (Thanks for that info!) in lieu of b43-openfwwf, and I rebooted a few times to make sure.

Comment 46 nicolas.vieville 2019-05-20 05:43:57 UTC
(In reply to Jason Elwell from comment #45)
> For me, the Koji build of akmod-wl-6.30.223.271-25.fc30.x86_64.rpm still
> needs the altered wpa_supplicant build.  I hope I've done it wrong, here is
> the NON-working config:
> 
> [...]

Thanks for the feedback.

Do you see some "CTRL-EVENT-SCAN-FAILED" messages in your logs (journalctl -xe) 
while using koji akmod-wl-6.30.223.271-25.fc30.x86_64.rpm package. 
What are the messages you can see in your logs in relationship with this issue?

Please feel free to post any comment or logs (as attachment) you think useful?

Cordially,


-- 
NVieville

Comment 47 Vasilis Keramidas 2019-05-20 16:28:27 UTC
It seems that build provided by NVieville does not work. Using the following packages:

sudo dnf list wpa_supplicant
Last metadata expiration check: 0:02:00 ago on Δευ 20 Μαΐ 2019 07:17:36 μμ EEST.
Installed Packages
wpa_supplicant.x86_64                            1:2.8-2.fc30                            @updates

sudo dnf list akmod-wl
Last metadata expiration check: 0:03:52 ago on Δευ 20 Μαΐ 2019 07:17:36 μμ EEST.
Installed Packages
akmod-wl.x86_64                                 6.30.223.271-25.fc30                         @@commandline


still produces the following messages:

Μαΐ 20 19:19:19 keramidopc wpa_supplicant[1394]: wlp9s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Μαΐ 20 19:19:20 keramidopc wpa_supplicant[1394]: wlp9s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Μαΐ 20 19:19:21 keramidopc wpa_supplicant[1394]: wlp9s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Μαΐ 20 19:19:22 keramidopc wpa_supplicant[1394]: wlp9s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Μαΐ 20 19:19:23 keramidopc wpa_supplicant[1394]: wlp9s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1

Comment 48 nicolas.vieville 2019-05-20 21:05:10 UTC
Hello,

I can confirm that build I provided (akmod-wl-6.30.223.271-25.fc30.x86_64.rpm) has random 
behavior and doesn't work as expected.
Yesterday it worked from the moment it was loaded to the system shutdown (few hours).
Today, no wifi all day, until one last reboot 10 minutes ago and it worked immediately 
once gdm was launched (before opening the session).

So I am sorry to say that the patched wl module is not working (too few random success)
with wpa_supplicant-2.8-2.fc30.x86_64.

I'll keep a copy of Davide Caratti wpa_supplicant packages in order to not being off.

Any hints about possible path to follow to catch this issue are welcome.

Cordially,


-- 
NVieville

Comment 49 Christophe H 2019-05-28 12:16:22 UTC
Hi,

Just confirming that wpa_supplicant-2.8-1.fc30.bz1703745rebuild DOES work for me. A recent upgrade to (possibly 2.8-2) broke it, so I have since I reverted to the previous version and listed the package under the dnf excludepkgs directive.

Thanks,

Christophe

Comment 50 Mattias 2019-05-29 19:48:32 UTC
Hi Davide,

I just installing wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm fixed the problem for me. (wlp5s0 BCM4352 802.11ac Wireless Network Adapter rev 03)

Thanks!

Comment 51 Nicolas Chauvet (kwizart) 2019-05-29 20:09:56 UTC
For the record, there is no "fix" in wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm that is in any way acceptable to add to the fedora package.
This package is a workaround until a proper fix is found. (probably on the wk-kmod side)

Any improvements done by others (distro or wl-kmod package maintainers) is welcomed.

Comment 52 Niklas Pihl 2019-05-30 11:00:42 UTC
For me installing workaround package "wpa_supplicant-2.8-2.fc30.bz1703745.x86_64.rpm" solves the issue on an Acer Aspire v3-571
with "Network controller [0280]: Broadcom Inc. and subsidiaries BCM43228 802.11a/b/g/n [14e4:4359]" network adapter.

Thank you :)

Comment 53 Nick Strickland 2019-05-30 22:01:36 UTC
Absolutely had to make an account to thank Davide for his solution in comment #13 (and his copr repo!).
I've been stumped for days trying to figure this out, and I was elated to find the solution.

Thank you again!

Comment 54 basilicum 2019-06-04 18:15:55 UTC
Herewith I share my experience with the wpa_supplicant-1:2.8-2.fc30.bz1703745.x86_64. See comment 40.

Hardware: MacBookAir, Model: A1465, mid2013-early2015, 11 inch, 6.1

$lspci -vnn -d 14e4:
03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)
	Subsystem: Apple Inc. Device [106b:0117]
	Flags: bus master, fast devsel, latency 0, IRQ 18
	Memory at b0600000 (64-bit, non-prefetchable) [size=32K]
	Memory at b0400000 (64-bit, non-prefetchable) [size=2M]
	Capabilities: <access denied>
	Kernel driver in use: wl
	Kernel modules: bcma, wl

A week ago, I did a fresh install of fedora 30. Before I ran fedora 29. Occasionally the wifi needed a few retries to connect. With fedora 28 and prior I had never any problem.

With fedora 30, wifi in most cases did not connect, however occasionally it did connect after some playing with reinstall wl-broadcom, restarting networkmanager, reboot etc.

I installed the dcaratti/wpa_supplicant as follows:
$dnf copr enable dcaratti/wpa_supplicant
$dnf update wpa_supplicant
Upgraded:
  wpa_supplicant-1:2.8-2.fc30.bz1703745.x86_64   
$systemctl stop NetworkManager
$systemctl stop wpa_supplicant
$systemctl start NetworkManager

In most cases the wifi works ! However sometimes it does not connect and I have to play around with restarting networkmanager, reboot etc.

Hope this report will be usefull for solving this bug.

Thanks to all !

Comment 55 Antony 2019-06-05 14:03:54 UTC
(In reply to basilicum from comment #54)
> Herewith I share my experience with the
> wpa_supplicant-1:2.8-2.fc30.bz1703745.x86_64. See comment 40.
> 

I also came here thanks to the CT SCAN issue. I can confirm that this build of wpa_supplicant works on my dell xps 9343:

$ lspci | grep -i broadcom
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4352 802.11ac Wireless Network Adapter (rev 03)

My install is not fresh. If it matters:

$ sudo dnf list akmod-wl
Installed Packages
akmod-wl.x86_64                                6.30.223.271-26.fc30                                @rpmfusion-nonfree-updates

Comment 56 nicolas.vieville 2019-06-12 12:36:26 UTC
Created attachment 1579823 [details]
NetworkManager config file

Hello,

Here is attached a NetworkManager config file (broadcom_wl.conf) that disables randomizing MAC address while scanning access points.

This is a quick and dirty workaround that prevent the "CTRL-EVENT-SCAN-FAILED ret=-22 retry=1" errors, and allow wireless device to connect to access point with Fedora standard wpa_supplicant package (wpa_supplicant-2.8-2.fc30.x86_64) and actual akmod-wl rpmfusion package (akmod-wl-6.30.223.271-26.fc30.x86_64).

It may not be desirable to disable randomizing MAC address of the wireless device while connecting to Public access points in a security point of view, this is the major drawback of this workaround.

In order to try and test this file, one have to copy the broadcom_wl.conf file in /etc/NetworkManager/conf.d directory (as root or sudo):

cp broadcom_wl.conf /etc/NetworkManager/conf.d/

Then get a copy of wpa_supplicant packages files from Davide Caratti copr repository, in case this workaround doesn't work.

Then remove Davide Caratti copr repository from dnf configuration and reinstall standard Fedora wpa_supplicant packages (always as root or sudo)

dnf copr remove dcaratti/wpa_supplicant
dnf distro-sync

Then reboot and see if Broadcom wireless device connects to AP.

In case this workaround doesn't work, (re)install wpa_supplicant packages files previously copied from Davide Caratti copr repository.

As this workaround seems not to be so good for security reasons, and doesn't fix the problem at the device driver level, I still interested by any proposal that could lead to such a fix.

If the community believes that this workaround would be worthy of inclusion in the rpmfusion broadcom-wl package, I would be very happy to hear its arguments and opinions before proceeding.

Feel free to make any comment about this.

Cordially,


-- 
NVieville

Comment 57 Adam Williamson 2019-06-12 15:11:17 UTC
"If the community believes that this workaround would be worthy of inclusion in the rpmfusion broadcom-wl package, I would be very happy to hear its arguments and opinions before proceeding."

It would be better to propose this in rpmfusion's own Bugzilla, I think, rather than here. That's where you'll find the rpmfusion community. :)

Comment 58 nicolas.vieville 2019-06-12 16:40:24 UTC
(In reply to Adam Williamson from comment #57)
> "If the community believes that this workaround would be worthy of inclusion
> in the rpmfusion broadcom-wl package, I would be very happy to hear its
> arguments and opinions before proceeding."
> 
> It would be better to propose this in rpmfusion's own Bugzilla, I think,
> rather than here. That's where you'll find the rpmfusion community. :)

You are right. Sorry if my previous message was not posted on the appropriate
list.

But given the number of comments on this Fedora bug report and the same number 
on the rpmfusion bug report, it seemed to me better to post on this thread in 
order to reach more people who might be able to test the workaround. There seems
I was wrong.
So I wonder if it would be possible for all potential testers that test reports 
would be posted to rpmfusion bug report linked to this one:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=5245

It would be very useful. Thanks in advance.

Thank you Adam for pointing this to me.

Cordially,


-- 
NVieville

Comment 59 Fangbing Wu 2019-06-12 23:39:55 UTC
This config fixed mu ThinkPad Wifi. None of the other work around posted here work. Thanks a lot!

Comment 60 Fangbing Wu 2019-06-13 16:57:08 UTC
Well, I spoke too soon. with the brodcom config, my Wifi worked once. Then it fails again.

Comment 61 DMcP 2019-06-19 19:20:11 UTC
Hi all,

Very sorry, 1st time linux user here and just installed Fedora30. I am experiencing the same issues above but don't know how to install the build supplied by comment 13 (https://koji.fedoraproject.org/koji/taskinfo?taskID=34599724)

I can use the terminal etc and tried a plethora of solutions thats google has returned. But not sure how to install the package above.

Any help would be appreciated.

Thanks,
Darren

Comment 62 Vasilis Keramidas 2019-06-19 19:35:07 UTC
(In reply to DMcP from comment #61)
> Hi all,
> 
> Very sorry, 1st time linux user here and just installed Fedora30. I am
> experiencing the same issues above but don't know how to install the build
> supplied by comment 13
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=34599724)
> 
> I can use the terminal etc and tried a plethora of solutions thats google
> has returned. But not sure how to install the package above.
> 
> Any help would be appreciated.
> 
> Thanks,
> Darren

Check https://fedoraproject.org/wiki/Common_F30_bugs#Broadcom_wireless_adapters_using_proprietary_broadcom-wl_driver_do_not_work_reliably for more info

Comment 63 nicolas.vieville 2019-06-22 17:31:16 UTC
Hello,

For the record and a review before adding below bug reports to the
bug tracker, here are two links that seem to say that randomizing MAC
addresses for certain wireless drivers (wl concerned) while scanning 
for AP is not always well supported:

https://bugzilla.gnome.org/show_bug.cgi?id=777523
https://bugzilla.redhat.com/show_bug.cgi?id=1695696

For the record too, since the workaround of #56 was applied to the
configuration of NetworkManager package (10 days ago), with the standard 
fedora wpa_supplicant package installed, no more connection problems
were encountered.
Some other distributions use the same workaround too in their 
NetworkManager package.

Cordially,


-- 
NVieville

Comment 64 Davide Caratti 2019-06-24 14:23:40 UTC
(In reply to nicolas.vieville from comment #63)
> Hello,
> 
> For the record and a review before adding below bug reports to the
> bug tracker, here are two links that seem to say that randomizing MAC
> addresses for certain wireless drivers (wl concerned) while scanning 
> for AP is not always well supported:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=777523
> https://bugzilla.redhat.com/show_bug.cgi?id=1695696
> 
> For the record too, since the workaround of #56 was applied to the
> configuration of NetworkManager package (10 days ago), with the standard 
> fedora wpa_supplicant package installed, no more connection problems
> were encountered.
> Some other distributions use the same workaround too in their 
> NetworkManager package.
> 
> Cordially,
> 
> 
> -- 
> NVieville

hello Nicolas,

thank you for the update. Good to know you managed to workaround the problem
also with the official wpa_supplicant. Due to the lack of sources, I'm reluctant
to even try developing a fix for broadcom-wl. For those willing to keep the mac
address randomization turned on, also with broadcom, I will keep my copr repo
updated as long as I can; but for sure no bug is identified / no further
development is planned in the package for the reported problem.

Closing as NOTABUG, feel free to reopen in case you need further information!
regards,
-- 
davide

Comment 65 Ben Boeckel 2019-07-10 13:08:47 UTC
*** Bug 1728251 has been marked as a duplicate of this bug. ***

Comment 66 Tim Wegener 2019-07-22 02:30:04 UTC
From https://fedoraproject.org/wiki/Common_F30_bugs#Broadcom_wireless_adapters_using_proprietary_broadcom-wl_driver_do_not_work_reliably

> The problem seems to be that a new feature in wpa_supplicant that was enabled in Fedora 30 confuses the broadcom-wl driver. As the driver is not open source we cannot provide a fixed version of it, and we will not disable a useful wpa-supplicant feature just to make a proprietary driver work correctly. 

Out of curiosity, why does the new feature involved here have to be enabled at compile time rather than being controlled via /etc/wpa_supplicant/wpa_supplicant.conf, say?

Comment 67 Beniamino Galvani 2019-08-21 16:24:45 UTC
(In reply to Tim Wegener from comment #66)
> Out of curiosity, why does the new feature involved here have to be enabled
> at compile time rather than being controlled via
> /etc/wpa_supplicant/wpa_supplicant.conf, say?

wpa_supplicant doesn't apply the configuration read from /etc/wpa_supplicant/wpa_supplicant.conf to interfaces controlled via D-Bus by NetworkManager and so any change to the file has no effect.

NetworkManager tries to detect at runtime if the supplicant and driver support features before enabling them, but this doesn't help if the driver is broken like in this case.