Created attachment 1551429 [details]
Description of problem:
Wifi nic will scan and list APs but not be able to connect to any of them.
Adding the following lines to /etc/NetworkManager/NetworkManager.conf
Version-Release number of selected component (if applicable):
How reproducible: Every time for every wifi AP
Steps to Reproduce:
1. Update from F29
2. Attempt to connect to wifi AP
$ journalctl -u wpa_supplicant.service -u NetworkManager | tail -n 250 > Wifi-issues.log
$ lspci | grep Bro
07:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n (rev 01)
$ lsmod | grep wl
wl 6463488 0
cfg80211 794624 1 wl
please enable level=TRACE logging of NetworkManager and provide debug logs of supplicant.
See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 for how to get debug logs from NM. Please note the comment about ratelimiting done by journal and disable ratelimiting.
For debug logs from supplicant, you could edit the systemd unit file to pass "-ddd" to wpa_supplicant. See `systemctl cat wpa_supplicant.service`
Created attachment 1551439 [details]
Verbose Wifi logging
Captures a fail-success-fail sequence.
I've uploaded a more verbose log as you've indicated and managed to capture a fail-success-fail sequence that seemed to happen without any intervention on my part.
At the time, I had not yet disabled rate limiting on the logging, I will continue to try to capture the sequence.
Thank you for the log. This is sufficent.
What gives `nmcli -f all device show wlp7s0` ?
Created attachment 1552516 [details]
nmcli -f all device show wlp7s0
This is with MAC Address Randomization set to NO, so my wifi functions.
It seems "wl" driver behaves badly when the MAC address is changed.
We have an upstream example configuration file to disable wifi.scan-rand-mac-address for certain drivers .
We should probably also put this into Fedora.
Note that on Ubuntu 18.04, package "wpasupplicant" provides a file /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf with similar content to the upstream examples file. See the commit message in .
(this is of course a driver bug, but NM probably should install the snippet to disable setting the MAC address with "wl" driver).
(In reply to andrew from comment #5)
> Created attachment 1552516 [details]
> nmcli -f all device show wlp7s0
> This is with MAC Address Randomization set to NO, so my wifi functions.
Thanks for confirming.
I was interested that DRIVER.GENERAL indeed shows "wl".
This is independent from MAC Address Randomization.
Great! Thanks Thomas! From the stand point of an end user, this is a regression in the upgrade from F29 to F30. Will this be included in the final F30 release?
(In reply to andrew from comment #9)
> Great! Thanks Thomas! From the stand point of an end user, this is a
> regression in the upgrade from F29 to F30. Will this be included in the
> final F30 release?
NetworkManager did not change regarding "wifi.scan-rand-mac-address" between F29 and F30.
That indicates that this problem was introduced in F30 by "wl" driver.
(In reply to Thomas Haller from comment #10)
> (In reply to andrew from comment #9)
> > Great! Thanks Thomas! From the stand point of an end user, this is a
> > regression in the upgrade from F29 to F30. Will this be included in the
> > final F30 release?
> NetworkManager did not change regarding "wifi.scan-rand-mac-address" between
> F29 and F30.
> That indicates that this problem was introduced in F30 by "wl" driver.
but the answer is: "if (and only if) the patch passes review and gets merged upstream, then it can be added to Fedora quickly."
(In reply to andrew from comment #0)
> $ lsmod | grep wl
> wl 6463488 0
> cfg80211 794624 1 wl
This is not a Fedora driver. Please report the problem to whoever you got the driver from.
The best we can do is to provide a workaround for the broken driver -- which is what Thomas did.
(In reply to Thomas Haller from comment #11)
> but the answer is: "if (and only if) the patch passes review and gets merged
> upstream, then it can be added to Fedora quickly."
That may very well mean just "no."
I did comment on your PR, and I don't think the patch is good as it is. You're blacklisting drivers that shouldn't be on a blacklist.
That said, I'm fine with blacklisting just this one particular driver. It's an out-of-tree driver that is known to be beyond repair due to its maintenance model for years. One problem I have with this solution is that the problem is worked around silently, without an error or a warning logged.
Perhaps we should just hardcode this driver in code; or indicate the reason why we're blacklisting this driver:
warn-broken="Disabling all the useful things because the driver is known to be badly broken"
Tbh neither seems like a particularly good idea to me and I'd just CANTFIX this bug.