Bug 1703745

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.

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.

(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.

(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?

I have built wpa_supplicant 2.8 which works fine with the broadcom-wl driver :-)

(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.

(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!

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

(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!

Hi Dave,

The laptop was fully rebooted when testing.

Dan

(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

(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

(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

(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.

(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.

(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

Hi Davide,

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

Dan

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

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.

(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/

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

(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

(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

(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?

(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

(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.

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

(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

(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?

wpa_supplicant-2.8-1.fc30.bz1703745rebuild didn't work for me.

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!

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.

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

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!

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"

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

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

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

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)

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.

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.

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.

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).

(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

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.

(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

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

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

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

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!

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.

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 :)

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!

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 !

(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

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

"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. :)

(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

This config fixed mu ThinkPad Wifi. None of the other work around posted here work. Thanks a lot!

Well, I spoke too soon. with the brodcom config, my Wifi worked once. Then it fails again.

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

(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

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

(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

*** Bug 1728251 has been marked as a duplicate of this bug. ***

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?

(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.

(In reply to nicolas.vieville from comment #56)
> 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).
> […]

I see no one commented: this workaround doesn't work. In fact, my gf's laptop started experiencing the problem this report is about, and it turned out dcaratti's wpa_supplicant got replaced by one from main repos. So I went to try your workaround, and found out it was in place for a year.

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

Dcaratti's repo seems not to have been updated for Fedora 32. I manually downloaded Fedora 31 version and locked wpa_supplicant from upgrades. I'm hoping it not gonna break in the future.

> I see no one commented: this workaround doesn't work. In fact, my gf's
> laptop started experiencing the problem this report is about, and it turned
> out dcaratti's wpa_supplicant got replaced by one from main repos. So I went
> to try your workaround, and found out it was in place for a year.
> 
> > Then get a copy of wpa_supplicant packages files from Davide Caratti copr
> > repository, in case this workaround doesn't work.
> 
> Dcaratti's repo seems not to have been updated for Fedora 32. I manually
> downloaded Fedora 31 version and locked wpa_supplicant from upgrades. I'm
> hoping it not gonna break in the future.

hello Konstantin,

I rebuilt the package for f32, and did a better configuration of repos,
so it should be easier to trigger the new builds in the future. Can you please
check if the workaround is still effective?

thanks,
-- 
davide

(In reply to Davide Caratti from comment #69)
> > I see no one commented: this workaround doesn't work. In fact, my gf's
> > laptop started experiencing the problem this report is about, and it turned
> > out dcaratti's wpa_supplicant got replaced by one from main repos. So I went
> > to try your workaround, and found out it was in place for a year.
> > 
> > > Then get a copy of wpa_supplicant packages files from Davide Caratti copr
> > > repository, in case this workaround doesn't work.
> > 
> > Dcaratti's repo seems not to have been updated for Fedora 32. I manually
> > downloaded Fedora 31 version and locked wpa_supplicant from upgrades. I'm
> > hoping it not gonna break in the future.
> 
> hello Konstantin,
> 
> I rebuilt the package for f32, and did a better configuration of repos,
> so it should be easier to trigger the new builds in the future. Can you
> please
> check if the workaround is still effective?
> 
> thanks,
> -- 
> davide

Wow, thank you! 

Unfortunately no, it didn't install wpa_supplicant from your repo. I did `dnf versionlock delete wpa_supplicant` and then `dnf update`. Afterwards when I execute `yum list installed | grep wpa_supplicant`, it says it is installed from "@fedora", not from "@copr:copr.fedoraclosed.org:dcaratti:wpa_supplicant".

While on it, I'm wondering if it would be useful to name the package differently from wpa_supplicant (for example "wpa_supplicant_broadcom"), and set a "conflicts" field to "wpa_supplicant"? When you gonna stop updating the repo, this would help to avoid a silent breakage because wpa_supplicant got silently replaced with the one from Fedora repos.

(In reply to Konstantin from comment #70)
> (In reply to Davide Caratti from comment #69)
> > > I see no one commented: this workaround doesn't work. In fact, my gf's
> 
> Wow, thank you! 
> 
> Unfortunately no, it didn't install wpa_supplicant from your repo. I did
> `dnf versionlock delete wpa_supplicant` and then `dnf update`. Afterwards
> when I execute `yum list installed | grep wpa_supplicant`, it says it is
> installed from "@fedora", not from
> "@copr:copr.fedoraclosed.org:dcaratti:wpa_supplicant".

maybe you need to enable the copr repo. See below:

[user@localhost ~]$ cat /etc/fedora-release
Fedora release 32 (Thirty Two)
[user@localhost ~]$ dnf info wpa_supplicant
Last metadata expiration check: 0:25:14 ago on Mon 20 Jul 2020 04:13:35 PM CEST.
Installed Packages
Name         : wpa_supplicant
Epoch        : 1
Version      : 2.9
Release      : 3.fc32
Architecture : x86_64
Size         : 5.5 M
Source       : wpa_supplicant-2.9-3.fc32.src.rpm
Repository   : @System
From repo    : fedora
Summary      : WPA/WPA2/IEEE 802.1X Supplicant
URL          : http://w1.fi/wpa_supplicant/
License      : BSD
Description  : wpa_supplicant is a WPA Supplicant for Linux, BSD and Windows with support
             : for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE 802.1X/WPA
             : component that is used in the client stations. It implements key negotiation
             : with a WPA Authenticator and it controls the roaming and IEEE 802.11
             : authentication/association of the wlan driver.

[user@localhost ~]$ sudo dnf -y copr enable dcaratti/wpa_supplicant
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.

The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.

Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Repository successfully enabled.
[user@localhost ~]$ sudo dnf -y upgrade  wpa_supplicant
Copr repo for wpa_supplicant owned by dcaratti                                                9.1 kB/s | 3.3 kB     00:00
Dependencies resolved.
==============================================================================================================================
 Package            Arch       Version                       Repository                                                  Size
==============================================================================================================================
Upgrading:
 wpa_supplicant     x86_64     1:2.9-5.fc32.bz1703745        copr:copr.fedorainfracloud.org:dcaratti:wpa_supplicant     1.4 M

Transaction Summary
==============================================================================================================================
Upgrade  1 Package

Total download size: 1.4 M
Downloading Packages:
wpa_supplicant-2.9-5.fc32.bz1703745.x86_64.rpm                                                3.2 MB/s | 1.4 MB     00:00
------------------------------------------------------------------------------------------------------------------------------
Total                                                                                         3.2 MB/s | 1.4 MB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                      1/1
  Running scriptlet: wpa_supplicant-1:2.9-5.fc32.bz1703745.x86_64                                                         1/1
  Upgrading        : wpa_supplicant-1:2.9-5.fc32.bz1703745.x86_64                                                         1/2
  Running scriptlet: wpa_supplicant-1:2.9-5.fc32.bz1703745.x86_64                                                         1/2
  Running scriptlet: wpa_supplicant-1:2.9-3.fc32.x86_64                                                                   2/2
  Cleanup          : wpa_supplicant-1:2.9-3.fc32.x86_64                                                                   2/2
  Running scriptlet: wpa_supplicant-1:2.9-3.fc32.x86_64                                                                   2/2
  Verifying        : wpa_supplicant-1:2.9-5.fc32.bz1703745.x86_64                                                         1/2
  Verifying        : wpa_supplicant-1:2.9-3.fc32.x86_64                                                                   2/2

Upgraded:
  wpa_supplicant-1:2.9-5.fc32.bz1703745.x86_64


> While on it, I'm wondering if it would be useful to name the package
> differently from wpa_supplicant (for example "wpa_supplicant_broadcom"), and
> set a "conflicts" field to "wpa_supplicant"? When you gonna stop updating
> the repo, this would help to avoid a silent breakage because wpa_supplicant
> got silently replaced with the one from Fedora repos.

thanks for the suggestion, but I think we shouldn't put effort on this
workaround. The root cause has been identified in the broadcom-wl code,
and the solution should be done there (ideally, it should be made open
source also :) ).

I don't have a system to try, but I'm curious to see if the same issue
would be visible if we use iwd in place of wpa_supplicant. WDYT?

(In reply to Davide Caratti from comment #71)
> (In reply to Konstantin from comment #70)
> > (In reply to Davide Caratti from comment #69)
> > > > I see no one commented: this workaround doesn't work. In fact, my gf's
> >
> > Wow, thank you!
> >
> > Unfortunately no, it didn't install wpa_supplicant from your repo. I did
> > `dnf versionlock delete wpa_supplicant` and then `dnf update`. Afterwards
> > when I execute `yum list installed | grep wpa_supplicant`, it says it is
> > installed from "@fedora", not from
> > "@copr:copr.fedoraclosed.org:dcaratti:wpa_supplicant".
>
> maybe you need to enable the copr repo. See below:
> […]

Thank you! Well, I had the repo enabled. Anyway, Idk what changed, but I ran `dnf update` again ≈30 minutes ago, and this time the update happened from your repo as expected.

> I don't have a system to try, but I'm curious to see if the same issue
> would be visible if we use iwd in place of wpa_supplicant. WDYT?

Nice idea! I tried it, and turns out iwd works well for me. I should note however, the first time I tried to connect to a network, I got this kernel warning¹ which I'm not sure what it warns about, but I couldn't reproduce it anymore.

Regarding iwd setup, I followed this blog post². TL;DR here's how I enable it:

1. sudo dnf install iwd
2. sudo systemctl enable iwd
3. sudo systemctl disable wpa_supplicant
4. Edit `/etc/NetworkManager/NetworkManager.conf` and find (or create) a "[device]" section with "wifi.backend=iwd" text. So it looks like this:
    [device]
    wifi.backend=iwd
5. sudo systemctl stop wpa_supplicant
6. sudo systemctl start iwd
7. sudo systemctl restart NetworkManager

May be interesting to note: incidentally, the blog post mentions a config option `wifi.scan-rand-mac-address=no` which judging by the thread here may be nice to have set. I didn't though. So far everything is nice and dandy.

1: https://pastebin.com/BQ8yQkf1
2: https://blobfolio.com/2019/10/replacing-wpa-supplicant-with-iwd-in-ubuntu-eoan/

Hello,

(In reply to Konstantin from comment #72)
> (In reply to Davide Caratti from comment #71)
> > (In reply to Konstantin from comment #70)
> > > (In reply to Davide Caratti from comment #69)
> > > > > I see no one commented: this workaround doesn't work. In fact, my gf's

Using successfully this workaround since 2019-06-12 to today with a BCM4313 
device, from F30 to F32 (5.7.8-200.fc32.x86_64 kernel).

The BCM4313 device description:
04:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01)

I wonder if you could please provide the model of the Broadcom device you use ?
I suspect that some devices are recalcitrant to this workaround, maybe the 
combination with some wireless AP devices have an impact on this (really 
difficult to get what's going on with this issue):

lspci -nn | grep 14e4

> > > Wow, thank you!
> > >
> > > [...]
> >
> > I don't have a system to try, but I'm curious to see if the same issue
> > would be visible if we use iwd in place of wpa_supplicant. WDYT?
> 
> Nice idea! I tried it, and turns out iwd works well for me. I should note
> however, the first time I tried to connect to a network, I got this kernel
> warning¹ which I'm not sure what it warns about, but I couldn't reproduce it
> anymore.
> 
> Regarding iwd setup, I followed this blog post². TL;DR here's how I enable
> it:
> 
> 1. sudo dnf install iwd
> 2. sudo systemctl enable iwd
> 3. sudo systemctl disable wpa_supplicant
> 4. Edit `/etc/NetworkManager/NetworkManager.conf` and find (or create) a
> "[device]" section with "wifi.backend=iwd" text. So it looks like this:
>     [device]
>     wifi.backend=iwd
> 5. sudo systemctl stop wpa_supplicant
> 6. sudo systemctl start iwd
> 7. sudo systemctl restart NetworkManager
 
Thank you very much for testing this suggestion and for how to use it.
Should be very helpful for users.

> May be interesting to note: incidentally, the blog post mentions a config
> option `wifi.scan-rand-mac-address=no` which judging by the thread here may
> be nice to have set. I didn't though. So far everything is nice and dandy.

If you use the broadcom-wl rpmfusion package, and in order to enable 
wifi.scan-rand-mac-address setting, be careful to disable the default settings 
provided by default in its /usr/lib/NetworkManager/conf.d/90-broadcom-wl.conf
NetworManager config file. 
As explained in its /usr/share/doc/broadcom-wl/fedora.readme file, you should
create one empty file using the exact same name in the
/etc/NetworkManager/conf.d directory to disable its effects.

In a root console:

touch /etc/NetworkManager/conf.d/90-broadcom-wl.conf

Reload NetworkManager in a user console:

systemctl restart NetworkManager.service

Then to verify your NetworkManager settings you should use this command line 
in a user console (maybe before and after settings modification):

NetworkManager --print-config

wifi.scan-rand-mac-address=no setting for wl driver should be gone.

If your device keeps working well with wifi.scan-rand-mac-address enabled 
and the Broadcom wireless driver, then using iwd should be the way to go for
secure usage.
I wonder if you could please provide some feedback about these points ?

Hope this will help to keep users fine with their Broadcom wireless devices
using the Broadcom 802.11 STA driver.

Feel free to make any comment about this subjects.

Cordially,


-- 
NVieville

(In reply to nicolas.vieville from comment #73)
> Using successfully this workaround since 2019-06-12 to today with a BCM4313 
> device, from F30 to F32 (5.7.8-200.fc32.x86_64 kernel).
> 
> The BCM4313 device description:
> 04:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4313
> 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01)
> 
> I wonder if you could please provide the model of the Broadcom device you
> use ?
> I suspect that some devices are recalcitrant to this workaround, maybe the 
> combination with some wireless AP devices have an impact on this (really 
> difficult to get what's going on with this issue):
> 
> lspci -nn | grep 14e4

Thank you! The output is:

    $ lspci -nn | grep 14e4
    02:00.0 Multimedia controller [0480]: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera [14e4:1570]
    03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)

FTR: currently I have returned back to wpa_supplicant (more on this below), and when I execute `NetworkManager --print-config` I see that your workaround with `wifi.scan-rand-mac-address=no` is applied. Full output is: https://pastebin.com/z2pLvvRf

> > > I don't have a system to try, but I'm curious to see if the same issue
> > > would be visible if we use iwd in place of wpa_supplicant. WDYT?
> > 
> > Nice idea! I tried it, and turns out iwd works well for me. I should note
> > however, the first time I tried to connect to a network, I got this kernel
> > warning¹ which I'm not sure what it warns about, but I couldn't reproduce it
> > anymore.
> > 
> > Regarding iwd setup, I followed this blog post². TL;DR here's how I enable
> > it:
> > 
> > 1. sudo dnf install iwd
> > 2. sudo systemctl enable iwd
> > 3. sudo systemctl disable wpa_supplicant
> > 4. Edit `/etc/NetworkManager/NetworkManager.conf` and find (or create) a
> > "[device]" section with "wifi.backend=iwd" text. So it looks like this:
> >     [device]
> >     wifi.backend=iwd
> > 5. sudo systemctl stop wpa_supplicant
> > 6. sudo systemctl start iwd
> > 7. sudo systemctl restart NetworkManager
>  
> Thank you very much for testing this suggestion and for how to use it.
> Should be very helpful for users.
> 
> > May be interesting to note: incidentally, the blog post mentions a config
> > option `wifi.scan-rand-mac-address=no` which judging by the thread here may
> > be nice to have set. I didn't though. So far everything is nice and dandy.
> 
> If you use the broadcom-wl rpmfusion package, and in order to enable 
> wifi.scan-rand-mac-address setting, be careful to disable the default
> settings 
> provided by default in its /usr/lib/NetworkManager/conf.d/90-broadcom-wl.conf
> NetworManager config file. 
> As explained in its /usr/share/doc/broadcom-wl/fedora.readme file, you should
> create one empty file using the exact same name in the
> /etc/NetworkManager/conf.d directory to disable its effects.
> 
> In a root console:
> 
> touch /etc/NetworkManager/conf.d/90-broadcom-wl.conf
> 
> Reload NetworkManager in a user console:
> 
> systemctl restart NetworkManager.service
> 
> Then to verify your NetworkManager settings you should use this command line 
> in a user console (maybe before and after settings modification):
> 
> NetworkManager --print-config
> 
> wifi.scan-rand-mac-address=no setting for wl driver should be gone.
> 
> If your device keeps working well with wifi.scan-rand-mac-address enabled 
> and the Broadcom wireless driver, then using iwd should be the way to go for
> secure usage.
> I wonder if you could please provide some feedback about these points ?
> 
> Hope this will help to keep users fine with their Broadcom wireless devices
> using the Broadcom 802.11 STA driver.

Sorry, bad news on iwd. The laptop owner just complained wifi stopped working after waking up from suspend. Apparently it is something completely different from what we discuss here: NetworkManager simply stopped showing any wifi network. Last two lines on iwd were:

    июл 20 22:54:52 mac2013 iwd[10736]: Unexpected connection related event -- is another supplicant running?
    июл 21 15:10:39 mac2013 iwd[10736]: Received Deauthentication event, reason: 0, from_ap: true


The fix was to simply restart iwd service, but for now I got back wpa_supplicant from dcaratti's repo as it just works™.

(In reply to Konstantin from comment #74)
> > lspci -nn | grep 14e4
> 
> Thank you! The output is:
> 
>     $ lspci -nn | grep 14e4
>     02:00.0 Multimedia controller [0480]: Broadcom Inc. and subsidiaries
> 720p FaceTime HD Camera [14e4:1570]
>     03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries
> BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)
> 
> FTR: currently I have returned back to wpa_supplicant (more on this below),
> and when I execute `NetworkManager --print-config` I see that your
> workaround with `wifi.scan-rand-mac-address=no` is applied. Full output is:
> https://pastebin.com/z2pLvvRf

Thank you very much for this feedback. 

I see in the output of `NetworkManager --print-config` that the workaround is
applied 2 times. One from the /usr/lib/NetworkManager/conf.d/90-broadcom-wl.conf
file, and one from the broadcom_wl.conf file located in some directory browsed by
NetworkManager when launched (probably /etc/NetworkManager). Maybe it's too many.

> 
> [...]
> 
> Sorry, bad news on iwd. The laptop owner just complained wifi stopped
> working after waking up from suspend. Apparently it is something completely
> different from what we discuss here: NetworkManager simply stopped showing
> any wifi network. Last two lines on iwd were:
> 
>     июл 20 22:54:52 mac2013 iwd[10736]: Unexpected connection related event
> -- is another supplicant running?
>     июл 21 15:10:39 mac2013 iwd[10736]: Received Deauthentication event,
> reason: 0, from_ap: true
> 
> 
> The fix was to simply restart iwd service, but for now I got back
> wpa_supplicant from dcaratti's repo as it just works™.

Thank you for this precision. The manpage for NetworkManager.conf add an 
indication for iwd saying it is 'experimental'. Maybe it is related.

Cordially,


-- 
NVieville

I sent a bugreport upstream through a form here https://www.broadcom.com/company/contact/emea-sales-contact-form I hope I chosen the form correctly. Anyway, let's see what they gonna answer. Given how many Broadcom chips the problem affects, I think it is a serious issue. I wrote a list of chips mentioned here too, just for the safe case.

Huh. So this is interesting. I have suddenly started to need this workaround *on my backup laptop*, which doesn't use Broadcom wifi at all. It uses iwlwifi. It's an old Sony Vaio Z, the wireless adapter is shown in dmesg as 'Intel(R) Centrino(R) Advanced-N 6200 AGN, REV=0x74'. Back in June, on Fedora 33, it suddenly stopped connecting to wifi, with this same symptom (repeated CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 errors). Downgrading kernel didn't shift it, the onset of the problem doesn't seem to have coincided with a wpa_supplicant update. It persisted for months and across an upgrade to F34. I re-discovered this bug via https://bbs.archlinux.org/viewtopic.php?id=235916 and added the same workaround - a NetworkManager config drop-in to disable wifi.scan-rand-mac-address - and it worked first try. Strange...

This issue surfaced in FC35 once again (it sued to work in FC34 strangely enough).

As the COPR repo doesn't have any FC35 builds yet (and I confirmed the issue by building wpa_supplicant locally w/o CONFIG_MESH enabled which worked as expcted): Why does the official package need mesh mode support anyway? Wouldn't it be possible to provide a separate build / package for those people who absolutely need this 802.11 feature?

(In reply to monochromec from comment #78)
> This issue surfaced in FC35 once again (it sued to work in FC34 strangely
> enough).
> 
> As the COPR repo doesn't have any FC35 builds yet (and I confirmed the issue
> by building wpa_supplicant locally w/o CONFIG_MESH enabled which worked as
> expcted):

(sorry, I just forgot to rebuild. Now fixed; and I will make myself a note to refresh the build *before* the launch of a new fedora release)

> Why does the official package need mesh mode support anyway?
> Wouldn't it be possible to provide a separate build / package for those
> people who absolutely need this 802.11 feature?

as per comment #25: if we turn off this feature, just because it's incompatible with a closed source driver, then we would actually hide the problem instead of fixing it.

Hi Davide, Thanks for looking into this right away!

Unfortunately, either the build was wrong or a different problem now surfaced. With your build, NM now fails again to authenticate via wpa_supplicant but reports a different error: "CTRL-EVENT-SCAN-FAILED, ret=-16".

Do we need a new BR for this?

Davide: as per my comment #77 above, at this point the feature now appears to be incompatible with at least one case using an open source driver.

hello, and thanks for your patience :)

(In reply to monochromec from comment #80)
> Hi Davide, Thanks for looking into this right away!
> 
> Unfortunately, either the build was wrong or a different problem now
> surfaced. With your build, NM now fails again to authenticate via
> wpa_supplicant but reports a different error: "CTRL-EVENT-SCAN-FAILED,
> ret=-16".

that's -EBUSY: it seems the driver doesn't like the request of scanning at the moment. How much does this "moment" last ... it's in the source we can't read :)
Question, is this something "persistent" (e.g. you see that also after reboot)? I'm asking, because a dnf update of wpa_supplicant doesn't restart the service.  Also, please check if disabling MAC address randomization ( as per comment #63 ) is helpful.

> Do we need a new BR for this?

maybe, this bugzilla tracks "unknown" problems in Broadcom's wl driver that have been caused enabling CONFIG_MESH in the build.
see below:

(In reply to Adam Williamson from comment #81)
> Davide: as per my comment #77 above, at this point the feature now appears
> to be incompatible with at least one case using an open source driver.

ok, and probably it's more than 2 NIC models... but in this case the problem is independent from the enablement of CONFIG_MESH, and it's more related to the MAC address randomization causing troubles on some drivers. That can't be turned on/off in this component, it's either something you do with NetworkManager configuration (as a workaround) or fix in the kernel driver to properly operate in case of MAC address change. Correct?

Error still persisting on an MBP 8,11 with a BMC4331.

Invocation is:

wpa_supplicant -d -P /run/wpa_supplicant-wlan0.pid -i wlan0 -D nl80211 -c/etc/wpa_supplicant/wpa_supplicant.conf

w/o MAC address randomization interfering.

WL version is 6.30.223.271-17.fc35 with wpa_supplicant 2.10 from the COPR repo.

More than happy to provide additional info if required.

(In reply to monochromec from comment #83)
> Error still persisting on an MBP 8,11 with a BMC4331.
> 
> Invocation is:
> 
> wpa_supplicant -d -P /run/wpa_supplicant-wlan0.pid -i wlan0 -D nl80211
> -c/etc/wpa_supplicant/wpa_supplicant.conf
> 
> w/o MAC address randomization interfering.
> 
> WL version is 6.30.223.271-17.fc35 with wpa_supplicant 2.10 from the COPR
> repo.

that's probably something described correctly at [1]. 
 
> More than happy to provide additional info if required.

I'd like to give a try to that patch, would you test it if I do a scratch build?

thanks!
-- 
davide

[1] http://lists.infradead.org/pipermail/hostap/2022-January/040185.html

No problem - happy to help. Just update this issue - I'll upgrade the build from your repo as soon as see your comment.

I get this error now on F35 (fully updated) x86_64 system with PCIe Broadcom dual-band BCM943228HM4L card (detected by kernel as Broadcom BCM4359 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)), when I try to connect to an AP that operates in the 2.4 GHz band on channel 12 or 13. These channels are legal in our country, regulatory domain seems be set right, but AP is not visible in NetworkManager nor iwlist scan, and when I set this connection with right channel/frequency and then connect to it as to hidden network, then connection fails and system log has lot of this records (CTRL-EVENT-SCAN-FAILED ret=-22 retry=1).
Wireless card without problems show and can to connect to APs in 5.4 GHz band and to APs in 2.4 GHz at channels 1-11 (tried with AP working at channel 12 or 13 - after changing only its frequency to channel 11, AP is visible, and is possible to connect it).
In dmesg isn't info about firmware load - not sure, if it matters.

Some details:
kernel 5.16.18-200.fc35.x86_64, wl driver from akmod-wl-6.30.223.271-39.fc35.x86_64

relevant part dmesg (there is nothing about firmware download, it is right??):
[    6.421189] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    6.422341] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    6.470441] wl: loading out-of-tree module taints kernel.
[    6.471103] wl: module license 'MIXED/Proprietary' taints kernel.
[    6.480004] wl: module verification failed: signature and/or required key missing - tainting kernel
[    6.482813] wl 0000:01:00.0: enabling device (0000 -> 0002)
[    6.511570] eth3: Broadcom BCM4359 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)
[    6.675979] wl 0000:01:00.0 wlan0: renamed from eth3

# lspci -vvnnn -s 01:00.0
01:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM43228 802.11a/b/g/n [14e4:4359]
        Subsystem: Dell Wireless 1530 Half-size Mini PCIe Card [1028:0011]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 51400000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=2 PME-
        Capabilities: [58] Vendor Specific Information: Len=78 <?>
        Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [d0] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 75.000W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L1, Exit Latency L1 <64us
                        ClockPM+ Surprise- LLActRep+ BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
                        TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 14, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [13c v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
        Capabilities: [160 v1] Device Serial Number 00-00-3f-ff-ff-38-b8-76
        Capabilities: [16c v1] Power Budgeting <?>
        Kernel driver in use: wl
        Kernel modules: bcma, wl

# iw reg get
global
country CZ: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 13), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

# iw phy0 reg get
global
country CZ: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 13), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

# iw phy0 info
Wiphy phy0
        wiphy index: 0
        max # scan SSIDs: 1
        max scan IEs length: 0 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CMAC (00-0f-ac:6)
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
        Band 1:  
                Bitrates (non-HT):
                        * 1.0 Mbps
                        * 2.0 Mbps (short preamble supported)
                        * 5.5 Mbps (short preamble supported)
                        * 11.0 Mbps (short preamble supported)
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 2412 MHz [1] (20.0 dBm)
                        * 2417 MHz [2] (20.0 dBm)
                        * 2422 MHz [3] (20.0 dBm)
                        * 2427 MHz [4] (20.0 dBm)
                        * 2432 MHz [5] (20.0 dBm)
                        * 2437 MHz [6] (20.0 dBm)
                        * 2442 MHz [7] (20.0 dBm)
                        * 2447 MHz [8] (20.0 dBm)
                        * 2452 MHz [9] (20.0 dBm)
                        * 2457 MHz [10] (20.0 dBm)
                        * 2462 MHz [11] (20.0 dBm)
                        * 2467 MHz [12] (20.0 dBm)
                        * 2472 MHz [13] (20.0 dBm)
                        * 2484 MHz [14] (disabled)
        Band 2:
                Bitrates (non-HT):
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 5160 MHz [32] (23.0 dBm)
...
                        * 6120 MHz [34] (disabled)
                        * 6130 MHz [36] (disabled)
                        * 6140 MHz [38] (disabled)
        Supported commands:
                 * set_interface
                 * new_key
                 * join_ibss
                 * set_pmksa
                 * del_pmksa
                 * flush_pmksa
                 * connect
                 * disconnect
        software interface modes (can always be added):
        valid interface combinations:
                 * #{ managed } <= 1, #{ AP } <= 1,
                   total <= 2, #channels <= 1, STA/AP BI must match
        Device supports scan flush.
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Supported TX frame types:
                 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        Supported RX frame types:
                 * managed: 0x40 0xd0
                 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
        Supported extended features:


Relevant part /var/log/messages (when trying to connect to AP at channel 12):
...
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4951] device (wlan0): Activation: starting connection 'semetrika' (0fdb2e41-68e4-4f08-bc76-4fcec662dbc7)
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4951] audit: op="connection-activate" uuid="0fdb2e41-68e4-4f08-bc76-4fcec662dbc7" name="semetrika" pid=8354 uid=1000 result="success"
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4952] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4954] manager: NetworkManager state is now CONNECTING
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4958] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4960] device (wlan0): Activation: (wifi) access point 'semetrika' has security, but secrets are required.
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4960] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4968] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4969] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4971] device (wlan0): Activation: (wifi) connection 'semetrika' has security, and secrets exist.  No new secrets needed.
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4971] Config: added 'ssid' value 'semetrika'
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4971] Config: added 'scan_ssid' value '1'
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4971] Config: added 'freq_list' value '2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484'
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4971] Config: added 'bgscan' value 'simple:30:-70:86400'
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4971] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256'
Apr  4 14:17:43 mantov NetworkManager[740]: <info>  [1649074663.4972] Config: added 'psk' value '<hidden>'
Apr  4 14:17:43 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:44 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:45 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:46 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:47 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:48 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:49 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:17:50 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
...
Apr  4 14:18:05 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:18:06 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:18:07 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
Apr  4 14:18:08 mantov NetworkManager[740]: <warn>  [1649074688.4943] device (wlan0): Activation: (wifi) association took too long, failing activation
Apr  4 14:18:08 mantov NetworkManager[740]: <info>  [1649074688.4944] device (wlan0): state change: config -> failed (reason 'ssid-not-found', sys-iface-state: 'managed')
Apr  4 14:18:08 mantov NetworkManager[740]: <info>  [1649074688.4954] manager: NetworkManager state is now DISCONNECTED
Apr  4 14:18:08 mantov NetworkManager[740]: <warn>  [1649074688.4964] device (wlan0): Activation: failed for connection 'semetrika'
Apr  4 14:18:08 mantov NetworkManager[740]: <info>  [1649074688.4968] device (wlan0): supplicant interface state: inactive -> disconnected
Apr  4 14:18:08 mantov NetworkManager[740]: <info>  [1649074688.4974] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Apr  4 14:18:08 mantov wpa_supplicant[913]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
Apr  4 14:18:10 mantov NetworkManager[740]: <info>  [1649074690.5390] device (wlan0): supplicant interface state: disconnected -> inactive



I do not know all detils about this WiFi card, nor when I should have try/configure something different.