Bug#879484: [Pkg-utopia-maintainers] Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
control: clone -1 -2 control: reassign -2 wpassupplicant control: found -2 2:2.9.0-11 control: affects -2 network-manager control: retitle -2 activation failure with long interface names Am 24.03.20 um 11:19 schrieb Alkis Georgopoulos: > On 3/24/20 11:07 AM, Andrej Shadura wrote: >> Could you please provide more background? It’s not quite clear to me >> how this commit fixes the issue. > > > Hello Andrej, > > I'm happy to provide the "end user" side of the story, but I can't > provide the "developer" side, as it's the Realtek engineers that > pinpointed this, I'm not familiar with the wpa codebase at all, and I > can't comment why this patch fixes this issue. > > So, the background is: > > MAC address randomization was enabled for all wifi adapters; then users > reported "keeps asking for a password" problems; the real problem was > never pinpointed, they blamed "it's an issue with these Realtek drivers, > tell them to fix them", and the "disable MAC randomization workaround" > was proposed until the real issue is fixed. > > So I did report this to Realtek, and they came up with the fix, but it > was not in their drivers as I expected, but in wpasupplicant. > Nevertheless, I tested it and it indeed solves the issue. > They also proposed a second workaround, that ifname=0 in the kernel > cmdline also works around the issue, and I tested it, and indeed that > works as well. > > Then, realizing that it's not related to Realtek drivers, I tested with > an atheros-based wifi adapter, and that one was affected as well. > > So, to reproduce the issue, the following are needed (which are the > default in Debian): > > 1) In /etc/NetworkManager/NetworkManager.conf, to either have the > following, or leave it undefined (while e.g. Ubuntu has "no" there): > > [device] > wifi.scan-rand-mac-address=yes > > 2) Make sure that the USB id isn't "blacklisted" in > /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf > > 3) Restart network manager if there were changes: > systemctl stop network-manager > killall wpa_supplicant > systemctl start network-manager > > 4) Insert a wifi adapter that produces a name with 15 characters like > wlx74ee2ae2436a. > > And the result is that without the patch it will keep asking for a > password, > while with the patch, it'll work fine. > > So I believe that if this is triaged / fixed, then there won't be any > need to apply the "disable MAC randomization" workarounds. Thanks for the additional context, Alkis, this is very helpful. I've cloned this bug report and reassigned it to wpasupplicant. This way you don't need to repeat everything you already wrote. I'll leave it up to Andrej to drop/change the file /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf when cherry-picking this patch. Michael signature.asc Description: OpenPGP digital signature
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 3/24/20 11:07 AM, Andrej Shadura wrote: Could you please provide more background? It’s not quite clear to me how this commit fixes the issue. Hello Andrej, I'm happy to provide the "end user" side of the story, but I can't provide the "developer" side, as it's the Realtek engineers that pinpointed this, I'm not familiar with the wpa codebase at all, and I can't comment why this patch fixes this issue. So, the background is: MAC address randomization was enabled for all wifi adapters; then users reported "keeps asking for a password" problems; the real problem was never pinpointed, they blamed "it's an issue with these Realtek drivers, tell them to fix them", and the "disable MAC randomization workaround" was proposed until the real issue is fixed. So I did report this to Realtek, and they came up with the fix, but it was not in their drivers as I expected, but in wpasupplicant. Nevertheless, I tested it and it indeed solves the issue. They also proposed a second workaround, that ifname=0 in the kernel cmdline also works around the issue, and I tested it, and indeed that works as well. Then, realizing that it's not related to Realtek drivers, I tested with an atheros-based wifi adapter, and that one was affected as well. So, to reproduce the issue, the following are needed (which are the default in Debian): 1) In /etc/NetworkManager/NetworkManager.conf, to either have the following, or leave it undefined (while e.g. Ubuntu has "no" there): [device] wifi.scan-rand-mac-address=yes 2) Make sure that the USB id isn't "blacklisted" in /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf 3) Restart network manager if there were changes: systemctl stop network-manager killall wpa_supplicant systemctl start network-manager 4) Insert a wifi adapter that produces a name with 15 characters like wlx74ee2ae2436a. And the result is that without the patch it will keep asking for a password, while with the patch, it'll work fine. So I believe that if this is triaged / fixed, then there won't be any need to apply the "disable MAC randomization" workarounds. Thanks!
Bug#879484: [Pkg-utopia-maintainers] Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 24/03/2020 10:07, Andrej Shadura wrote: On 24/03/2020 03:41, Alkis Georgopoulos wrote: The two-liner patch made it upstream: http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563 It would be awesome if it was cherrypicked/backported, as it's rather significant and it solves this issue. Could you please provide more background? It’s not quite clear to me how this commit fixes the issue. I’d be happy to apply it, of course, but some rationale would be great. Nevermind, I found your launchpad issue. -- Cheers, Andrej
Bug#879484: [Pkg-utopia-maintainers] Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 24/03/2020 03:41, Alkis Georgopoulos wrote: The two-liner patch made it upstream: http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563 It would be awesome if it was cherrypicked/backported, as it's rather significant and it solves this issue. Could you please provide more background? It’s not quite clear to me how this commit fixes the issue. I’d be happy to apply it, of course, but some rationale would be great. -- Cheers, Andrej
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 3/24/20 8:07 AM, Michael Biebl wrote: I'd prefer a separate, new bug report against wpasupplicant. The original bug report is about disabling mac randomization, so afaics a different issue from yours. My problem was exactly the one described here. With MAC randomization enabled, network manager kept asking for a password. The workaround mentioned here (disabling MAC randomization) did work around the problem. But it's just an unsafe workaround, not a solution. Then I reported the issue to Realtek, and they pinpointed the underlying bug in wpasupplicant. After applying their patch in wpasupplicant, there's no need to disable MAC randomization in network-manager anymore. I can file a separate issue, but it will have pretty much the same description, that "when MAC randomization is enabled, network-manager keeps asking for a password"... Maybe we can just put "wpasupplicant" in the "affects" list, and when someone else here confirms what I say, we can then remove "network-manager"? Unfortunately I'm not familiar with debian bug tags though... :/ Btw, another workaround than disabling MAC randomization, is to pass ifnames=0 in the kernel cmdline, as this then causes USB wifi adapters to have smaller interface names (wlan0) that do not trigger the wpasupplicant bug.
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
Am 24.03.20 um 06:37 schrieb Alkis Georgopoulos: > On 3/24/20 5:22 AM, Michael Biebl wrote: >> You should file a bug report against wpasupplicant. >> Andrew, the wpasupplicant maintainer, is not reading network-manager bug >> reports. > > > Thank you Michael, > > I was thinking of: > 1) Getting feedback from someone affected by this bug (like me) that > this patch indeed solves it, and then > 2) Find out how to "reassign this issue to wpasupplicant instead of > network-manager", without opening a new bug for the same issue and then > having to manage two bugs... > > Is that an appropriate approach? I'd prefer a separate, new bug report against wpasupplicant. The original bug report is about disabling mac randomization, so afaics a different issue from yours. signature.asc Description: OpenPGP digital signature
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 3/24/20 5:22 AM, Michael Biebl wrote: You should file a bug report against wpasupplicant. Andrew, the wpasupplicant maintainer, is not reading network-manager bug reports. Thank you Michael, I was thinking of: 1) Getting feedback from someone affected by this bug (like me) that this patch indeed solves it, and then 2) Find out how to "reassign this issue to wpasupplicant instead of network-manager", without opening a new bug for the same issue and then having to manage two bugs... Is that an appropriate approach?
Bug#879484: [Pkg-utopia-maintainers] Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
Hi Am 24.03.20 um 03:41 schrieb Alkis Georgopoulos: > The two-liner patch made it upstream: > > http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563 > > > It would be awesome if it was cherrypicked/backported, as it's rather > significant and it solves this issue. You should file a bug report against wpasupplicant. Andrew, the wpasupplicant maintainer, is not reading network-manager bug reports. Regards signature.asc Description: OpenPGP digital signature
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
The two-liner patch made it upstream: http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563 It would be awesome if it was cherrypicked/backported, as it's rather significant and it solves this issue.
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
I reported this to Realtek and they pinpointed it to a bug in wpasupplicant. I tested the patch and it works fine for 8812au, 88x2bu and 8821cu. I then reported it to launchpad in case it makes it for Ubuntu 20.04: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/1867908 If others here test that oneliner-patch and find that it solves this issue, maybe we can just report it upstream and to wpasupplicant in debian, not in network-manager.
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
FWIW, I almost completely gave up before I ran into the NM bugzilla describing how some drivers break with rand-mac. I even went and bought a USB dongle to try and get Debian (or anything) running on wifi, but that didn't work either because the driver suffers the same problem than wl. I have edited my /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf to also have the following three driver: matches. [device-mac-addr-change-wifi] match-device=(...),driver:wl,driver:rtl8192eu,driver:rtl8xxxu I would propose adding this change to that file because otherwise it's impossible to get Debian working on those cards unless you know a lot about the desktop stack, or you are extremely good with googling. For context: * the 'wl' driver is broadcom-sta, and is used by many MacBook Pro Retina (mine is MacBookPro11,1). * rtl8192eu[1] is a maintenance fork that works slightly better than rtl8xxxu on the USB dongle I got, and rtl8xxxu seems to be an ever popular driver for cheap USB dongles. USB dongle (works with rtl8xxxu and rtl8192eu): Bus 001 Device 008: ID 2357:0109 TP-Link TL WN823N RTL8192EU MacBookPro wifi (works with wl): 03:00.0 Network controller [0280]: Broadcom Limited BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03) 1 - rtl8192eu fork: https://github.com/Mange/rtl8192eu-linux-driver
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
The Ubuntu bug for this issue is https://launchpad.net/bugs/1681513 Jérôme, yes, I want there to be an on/off switch for this feature in at least GNOME before we re-enable this privacy feature in Ubuntu. Thanks, Jeremy Bicha
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
I was hit by this too. This is what I understand: This setting is enabled by default for privacy/security reasons. It makes connection fail with some HW/drivers due to the drivers themselves, so the rootcause is not in network-manager itself. This results in poor user experience for impacted users but the devs may not be willing to sacrifice security to workaround an issue in buggy drivers. Is this a setting that could be exposed in a GUI such as network-manager-gnome? Could it be an acceptable compromise? The user with a connection issue would open the connection settings dialog et found a checkbox: [X] Randomize MAC address during scan There would be a tooltip explaining that while this might be desirable, it is known to cause issues on some HW/drivers. The user would uncheck it and try again. Should we open a bug on network-manager-gnome for this? -- Jérôme
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
Package: network-manager Version: 1.6.2-3 Severity: wishlist Dear Maintainer, I think that Network-Manager default settings should be changed to default to non-random MAC addresses on WiFi. Even though there are security reasons for enabling this by default, this results in less "out of the box" support for WiFi cards on fresh Debian installs and on Live CDs. Other GNU/Linux distributions have this setting disabled by default. * What led up to the situation? I was using a live CD of Debian 9.2 with Gnome (written to a USB thumb rive), and my wireless card was not connecting to my network, even though Network- Manager was detecting both the card and the network. I tried a live CD for Ubuntu 17.10 Gnome version, and it connected without issue. I investigated, and saw that Ubuntu's live CD has a setting in "/etc/NetworkManager/NetworkManager.conf" that is not present on Debian's version: [device] wifi.scan-rand-mac-address=no * What exactly did you do (or not do) that was effective (or ineffective)? I added this setting to "/etc/NetworkManager/NetworkManager.conf" on my Debian live CD, and after restarting Network Manager my wireless card connected to my WiFi network without issue. [device] wifi.scan-rand-mac-address=no -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.115 ii dbus 1.10.22-0+deb9u1 ii init-system-helpers1.48 ii libaudit1 1:2.6.7-2 ii libbluetooth3 5.43-2+deb9u1 ii libc6 2.24-11+deb9u1 ii libglib2.0-0 2.50.3-2 ii libgnutls303.5.8-5+deb9u3 ii libgudev-1.0-0 230-3 ii libjansson42.9-1 ii libmm-glib01.6.4-1 ii libndp01.6-1+b1 ii libnewt0.520.52.19-1+b1 ii libnl-3-2003.2.27-2 ii libnm0 1.6.2-3 ii libpam-systemd 232-25+deb9u1 ii libpolkit-agent-1-00.105-18 ii libpolkit-gobject-1-0 0.105-18 ii libreadline7 7.0-3 ii libselinux12.6-3+b3 ii libsoup2.4-1 2.56.0-2+deb9u1 ii libsystemd0232-25+deb9u1 ii libteamdctl0 1.26-1+b1 ii libuuid1 2.29.2-1 ii lsb-base 9.20161125 ii policykit-10.105-18 ii udev 232-25+deb9u1 ii wpasupplicant 2:2.4-1+deb9u1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base 2.76-5+deb9u1 ii iptables 1.6.0+snapshot20161117-6 ii iputils-arping 3:20161105-1 ii isc-dhcp-client 4.3.5-3 ii modemmanager 1.6.4-1 ii ppp 2.4.7-1+4 Versions of packages network-manager suggests: pn libteam-utils -- no debconf information
