search

qca / open-ath9k-htc-firmware

The firmware for QCA AR7010/AR9271 802.11n USB NICs
Other
432 stars 183 forks source link

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

Open olerem opened 7 years ago

olerem commented 7 years ago

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 commented 7 years ago

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

olerem commented 7 years ago

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

erikarn commented 7 years ago

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 notifications@github.com 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 https://github.com/qca/open-ath9k-htc-firmware/issues/132#issuecomment-318964476, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7UNLsXXB4mXbBIlKIWhrkZCPbh28ks5sTVfcgaJpZM4OLhS6 .

jscott0 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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