Bug 1695696 - Random Wifi MAC prevents authentication
Summary: Random Wifi MAC prevents authentication
Keywords:
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 30
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-03 15:41 UTC by andrew
Modified: 2019-04-08 07:31 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Wifi log (36.65 KB, text/plain)
2019-04-03 15:41 UTC, andrew
no flags Details
Verbose Wifi logging (8.72 MB, text/plain)
2019-04-03 16:52 UTC, andrew
no flags Details
nmcli -f all device show wlp7s0 (5.42 KB, text/plain)
2019-04-05 13:13 UTC, andrew
no flags Details

Description andrew 2019-04-03 15:41:51 UTC
Created attachment 1551429 [details]
Wifi log

Description of problem:

Wifi nic will scan and list APs but not be able to connect to any of them. 

Solution:

Adding the following lines to /etc/NetworkManager/NetworkManager.conf

[device]
wifi.scan-rand-mac-address=no


Version-Release number of selected component (if applicable):

NetworkManager-1.16.0-1.fc30.x86_64


How reproducible: Every time for every wifi AP


Steps to Reproduce:
1. Update from F29
2. Attempt to connect to wifi AP

Actual results:

Failure

Expected results:

Sucess. 

Additional info:

$ 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

Comment 1 Thomas Haller 2019-04-03 16:29:13 UTC
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`

thank you.

Comment 2 andrew 2019-04-03 16:52:31 UTC
Created attachment 1551439 [details]
Verbose Wifi logging

Captures a fail-success-fail sequence.

Comment 3 andrew 2019-04-03 16:54:05 UTC
Hi Thomas,

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. 

Sincerely,
Andrew

Comment 4 Thomas Haller 2019-04-05 11:57:06 UTC
Thank you for the log. This is sufficent.

What gives `nmcli -f all device show wlp7s0` ?

Comment 5 andrew 2019-04-05 13:13:35 UTC
Created attachment 1552516 [details]
nmcli -f all device show wlp7s0

This is with MAC Address Randomization set to NO, so my wifi functions.

Comment 6 Thomas Haller 2019-04-05 14:17:05 UTC
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 [1].

[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=78d9bd62ff152523489226b0bc7fd4f2b8ddc80d

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 [1].


(this is of course a driver bug, but NM probably should install the snippet to disable setting the MAC address with "wl" driver).

Comment 7 Thomas Haller 2019-04-05 14:18:29 UTC
(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.

Comment 9 andrew 2019-04-05 15:11:42 UTC
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?

Comment 10 Thomas Haller 2019-04-05 15:23:00 UTC
(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.

Comment 11 Thomas Haller 2019-04-05 15:27:22 UTC
(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."

Comment 12 Lubomir Rintel 2019-04-08 07:29:10 UTC
(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:

[useless-crap]
match-device=driver:wl
warn-broken="Disabling all the useful things because the driver is known to be badly broken"
wifi.cloned-mac-address=preserve
ethernet.cloned-mac-address=preserve

Tbh neither seems like a particularly good idea to me and I'd just CANTFIX this bug.


Note You need to log in before you can comment on or make changes to this bug.