Can't associate if NetworkManager enables wifi.scan-rand-mac-address

[olerem]

To keep track of this issue.

With new version of NetworkManager ath9k-htc can't establish connection with any AP. Current workaround is to disable wifi.scan-rand-mac-address by creating config:
/etc/NetworkManager/conf.d/no_mac_random.conf
[device-wlxa0f3c1187111]
match-device=wlxa0f3c1187111
wifi.scan-rand-mac-address=0

wlxa0f3c1187111 should be replaced to the name of you wifi interface.

[Legimet]

I can confirm that this is an issue with Debian stretch. I noticed it when network-manager was upgraded to 1.4.

[olerem]

Currently, no one is working on this issue. Every one is welcome to fix it.

[erikarn]

Can we tell the upper layers that ath9k_htc devices don't support this feature?

…

-a

On 30 July 2017 at 21:28, Oleksij Rempel ***@***.***> wrote: Currently, no one is working on this issue. Every one is welcome to fix it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#132 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGl7UNLsXXB4mXbBIlKIWhrkZCPbh28ks5sTVfcgaJpZM4OLhS6> .

[jscott0]

Something I noticed on Debian (edit: it's upstream, not Debian-specific) is that wpa_supplicant provides a file /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf which reads

# Certain drivers are known not to support changing the MAC address.
# Disable touching the MAC address on such devices.
#
# See man NetworkManager.conf
#
# https://bugzilla.gnome.org/show_bug.cgi?id=777523

[device-mac-addr-change-wifi]
match-device=driver:rtl8723bs,driver:rtl8189es,driver:r8188eu,driver:8188eu,driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no
wifi.cloned-mac-address=preserve
ethernet.cloned-mac-address=preserve

Some of the comments at the NetworkManager bug:

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.
and even more interestingly

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

In my computer, PCIe wifi(ath9k) works fine, but USB dongles(include ath9k) won't work, maybe something is wrong in systemd-udevd?

If there are no objections or anyone beating me to it, I think I'll file a bug with them.

[jscott0]

I take that back: it turns out this is an issue that applies to all devices with interface names using the maximum number of characters, and is allegedly fixed with the following recent change to wpa_supplicant. The patch allegedly allows using MAC randomization proper, rather than disabling all support. Thanks to the investigator here and here

https://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563

[jscott0]

I am super glad to report that this is in fact caused by the newly-fixed issue in wpasupplicant. MAC randomization works with this change in Debian for example:
wpa (2:2.9.0-12) unstable; urgency=medium

• Add an upstream patch to fix the MAC randomisation issue with some cards
  (LP: #1867908).

-- Andrej Shadura andrewsh@debian.org Tue, 24 Mar 2020 11:13:16 +0100