GNOME Bugzilla – Bug 777523
Setting Fake MAC when scanning Wi-Fi blocks some WLAN cards fully from being used
Last modified: 2017-09-03 21:00:35 UTC
Some WLAN card drivers do not support MAC address setting. When it tries to set fake MAC address, it fails, and NM then always retry, which makes the card totally unusable. Known bad cards: - rtl8188eu - rtl8189es - rtl8723bs (including rtl8703as) With devices wich such cards, NM won't totally scan network or connect to network, fully blocks the possibility to get the devices connected. Maybe a weaker mode should become default -- "try". In this mode, a fake MAC will be tried to be set, however, it won't fail if it cannot be set.
the behavior regarding setting the MAC address is fully configurable. So, and affected user can at least work around it. for example a file /etc/NetworkManager/conf.d/99-mac-addr.conf: [device.mac-addr] wifi.scan-rand-mac-address=0 [connection.mac-addr] wifi.cloned-mac-address=preserve #ethernet.cloned-mac-address=preserve Could you attach a logfile of NetworkManager with level=TRACE to show the issue? (see https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf ). Thanks Shouldn't the drivers be fixed instead?
https://pastebin.anthonos.org/view/d05770ef Here's the log. Thanks! Icenowy
thanks it seems the driver entirely refuses to reset the MAC address. Can you set the MAC address via ip link set wlan0 address "$ADDR" or is macchanger able to change the MAC address on the device? macchanger -r wlan0
Yes. The command won't fail, but the MAC do not change.
the default behavior changed, because we think that the new behavior makes sense for the majority of users. Unfortunately, I breaks with certain drivers. It's unclear how to work around that in NetworkManager. There could be a "enable-with-best-effort" variant of the MAC address spoofing options. But that seems very over-complicated to implement (and become obsolete once drivers are fixed). I would rather not change anything in NetworkManager (upstream) and require drivers to be fixed. Note that the setting *is* already configurable, and downstream/distributions are welcome to choose a different default, if they think that is preferable. I suggest to close as NOT_GNOME/WONT_FIX.
*** Bug 775529 has been marked as a duplicate of this bug. ***
bug 775529 mentions driver issues for: - Realtek RTL8188EU - Realtek RTL8723BS - ESP8089
*** Bug 780119 has been marked as a duplicate of this bug. ***
quote bug 780119: > I have tested many usb wifi dongles with NetworkManager 1.4.x and 1.6.x in > linux kernel 4.9.x, include ath9k, rt2x00usb, rtl8xxxu, rtl8188, mt7601u
(In reply to Thomas Haller from comment #9) > quote bug 780119: > > > I have tested many usb wifi dongles with NetworkManager 1.4.x and 1.6.x in > > linux kernel 4.9.x, include ath9k, rt2x00usb, rtl8xxxu, rtl8188, mt7601u From my own experience, ath9k_htc (I used ar9271) and mt7601u is ok. (My kernel is 4.9 or 4.11-rc1, depends on devices) (I think only ath9k_htc have usb dongles, right?) rtl8188eu really sucks.
For my distro, here's a temporary quirking script: https://github.com/AOSC-Dev/aosc-os-abbs/blob/staging/extra-network/networkmanager/autobuild/overrides/usr/libexec/nm-fakemac-quirk
[[OFF-TOPIC]] it seems preferably not to write to /etc/NetworkManager/NetworkManager.conf directly. Instead put a file to /etc/NetworkManager/conf.d/. Or maybe even better, use /usr/lib/NetworkManager/conf.d. F="/usr/lib/NetworkManager/conf.d/10-disable-wifi-scan.conf" if ((quirk)); then if [[ ! -f "$F" ]]; then cat <<EOF > "$F" [device-disable-wifi-scan] wifi.scan-rand-mac-address=no EOF fi fi The user can shadow this file by creating an empty /etc/NetworkManager/conf.d/10-disable-wifi-scan.conf. see `man NetworkManager.conf` about the conf.d directories, and see "DEVICE SECTION" "Sections" about [device] vs. [device-disable-wifi-scan]. Note also `/usr/sbin/NetworkManager --print-config`
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b869d9cc0dda4fe5300f5ec5b5a090199ecd4e3e on master adds the possibility to disable the settings based on the driver. See "examples/nm-conf.d/31-mac-addr-change.conf".
No this can't be right. wifi.scan-rand-mac-address should only be changing the mac address during scans Drivers could not care less and will scan using their default mac address anyway or do passive scans. The fault here is that the drivers scan the network okay authenticate but will not complete to associated. Is Network Manager trying to change the mac address on connections? All the devices I have that use mac80211 are broken when wifi.scan-rand-mac-address is enabled.
(In reply to Icenowy Zheng from comment #10) > (In reply to Thomas Haller from comment #9) > > quote bug 780119: > > > > > I have tested many usb wifi dongles with NetworkManager 1.4.x and 1.6.x in > > > linux kernel 4.9.x, include ath9k, rt2x00usb, rtl8xxxu, rtl8188, mt7601u > > From my own experience, ath9k_htc (I used ar9271) and mt7601u is ok. (My > kernel is 4.9 or 4.11-rc1, depends on devices) > > (I think only ath9k_htc have usb dongles, right?) > > rtl8188eu really sucks. My Xiaomi Wifi Gen2 use mt7601u driver, I tested in Fedora 25/ ubuntu 1704 and Debian 9 testing, none of them could work without wifi.scan-rand-mac-address=no.
(In reply to Malcolm Priestley from comment #14) > The fault here is that the drivers scan the network okay authenticate but > will not complete to associated. You are right, NM uses random MAC in all conditions, not only in scacnning.
(In reply to Malcolm Priestley from comment #14) > No this can't be right. > > wifi.scan-rand-mac-address should only be changing the mac address during > scans But it will refuse to really do scan if MAC didn't really change. > > Drivers could not care less and will scan using their default mac address > anyway or do passive scans. > > The fault here is that the drivers scan the network okay authenticate but > will not complete to associated. > > Is Network Manager trying to change the mac address on connections? When connecting it will try to change MAC back. > > All the devices I have that use mac80211 are broken when > wifi.scan-rand-mac-address is enabled.
(In reply to An Yang from comment #15) > (In reply to Icenowy Zheng from comment #10) > > (In reply to Thomas Haller from comment #9) > > > quote bug 780119: > > > > > > > I have tested many usb wifi dongles with NetworkManager 1.4.x and 1.6.x in > > > > linux kernel 4.9.x, include ath9k, rt2x00usb, rtl8xxxu, rtl8188, mt7601u > > > > From my own experience, ath9k_htc (I used ar9271) and mt7601u is ok. (My > > kernel is 4.9 or 4.11-rc1, depends on devices) > > > > (I think only ath9k_htc have usb dongles, right?) > > > > rtl8188eu really sucks. > > My Xiaomi Wifi Gen2 use mt7601u driver, I tested in Fedora 25/ ubuntu 1704 > and Debian 9 testing, none of them could work without > wifi.scan-rand-mac-address=no. My card is 360 Wifi Gen2, and my NM version is 1.6.2.
(In reply to Thomas Haller from comment #13) > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/ > ?id=b869d9cc0dda4fe5300f5ec5b5a090199ecd4e3e on master adds the possibility > to disable the settings based on the driver. See > "examples/nm-conf.d/31-mac-addr-change.conf". Tested this commit, and it works on a RTL8188EU card (broken) compared with an AR9462 card (proper MAC setting).
In my computer, PCIe wifi(ath9k) works fine, but USB dongles(include ath9k) won't work, maybe something is wrong in systemd-udevd?
(In reply to Icenowy Zheng from comment #18) > My card is 360 Wifi Gen2, and my NM version is 1.6.2. In my debian9 testing system, udev 239-19 is used, which version of udev do you use?
I use ip link set dev interface address XX:XX:XX:XX:XX:XX and wpa_supplicant -i interface -c my-ap.conf to test, it fails too. Something is wrong in wifi driver, cloud you give any advice to fix it?
In kernel, dev_set_mac_address() and ndo_set_mac_address() were called, there so many wireless drivers do NOT support it.
I tried to hack the vt6656_stage driver at the weekend to do it. Even though the code suggested that it could it flatly refused to change it's mac address, although it would scan no problem as that is done by mac80211. But when it comes to encryption that can't be done in software with that driver. With most most drivers it's the firmware that will not allow the change. If it can be done in software alone that is a work around.
(In reply to An Yang from comment #23) > In kernel, dev_set_mac_address() and ndo_set_mac_address() were called, > there so many wireless drivers do NOT support it. A way round for drivers is simply spoof the mac address back to it's own mac address using the encryption key provided.
(In reply to Malcolm Priestley from comment #24) > Even though the code suggested that it could it flatly refused to change > it's mac address, although it would scan no problem as that is done by > mac80211. Maybe all the wifi drivers depend on mac80211 could NOT change their MAC address at all. In net/mac80211/iface.c line 211 of linux kernel 4.9.14: static int ieee80211_change_mac(struct net_device *dev, void *addr) call eth_mac_addr(dev, sa); In net/ethernet/eth.c line 303, eth_mac_addr(), eth_mac_addr just call memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN); So I guess, the wifi drivers without net_device support directly, will act as the following, even the MAC address was changed in the kernel successfully, from AP side, it will find the orig MAC address.
(In reply to Thomas Haller from comment #12) > [[OFF-TOPIC]] > > it seems preferably not to write to /etc/NetworkManager/NetworkManager.conf > directly. Instead put a file to /etc/NetworkManager/conf.d/. > Or maybe even better, use /usr/lib/NetworkManager/conf.d. > > F="/usr/lib/NetworkManager/conf.d/10-disable-wifi-scan.conf" > if ((quirk)); then > if [[ ! -f "$F" ]]; then > cat <<EOF > "$F" > [device-disable-wifi-scan] > wifi.scan-rand-mac-address=no > EOF > fi > fi > > The user can shadow this file by creating an empty > /etc/NetworkManager/conf.d/10-disable-wifi-scan.conf. > > see `man NetworkManager.conf` about the conf.d directories, and see "DEVICE > SECTION" "Sections" about [device] vs. [device-disable-wifi-scan]. > > Note also `/usr/sbin/NetworkManager --print-config` I just joined to say that after a lot of headache, adding this: [device-disable-wifi-scan] wifi.scan-rand-mac-address=no seems to have fixed my problems with dropping my wifi connection after a few seconds, forcing me to restart the network-manager systemd service to get another five seconds worth of internet. However, my wifi-card is BCM43142 802.11b/g/n, driver wl (broadcom-sta-dkms). I'm on debian testing (Buster). My wifi card seems to suffer from a lot of problems, however this fix was rarely suggested in my forays into forums - lucky I stumbled past here! Also, please remove this if it is inappropriate to use this bug list for this. I am not sure about the customs in bugzilla.
Pretty much the standard fix for all distributions. Poking around many of the drivers did not provide any fixes. 80% of drivers do not support this, strangely some of the drivers that do are very old ones like rtl8192e and that's in staging!