Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi

[Matthew Crews]

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 adduser 3.115
ii dbus 1.10.22-0+deb9u1
ii init-system-helpers 1.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 libgnutls30 3.5.8-5+deb9u3
ii libgudev-1.0-0 230-3
ii libjansson4 2.9-1
ii libmm-glib0 1.6.4-1
ii libndp0 1.6-1+b1
ii libnewt0.52 0.52.19-1+b1
ii libnl-3-200 3.2.27-2
ii libnm0 1.6.2-3
ii libpam-systemd 232-25+deb9u1
ii libpolkit-agent-1-0 0.105-18
ii libpolkit-gobject-1-0 0.105-18
ii libreadline7 7.0-3
ii libselinux1 2.6-3+b3
ii libsoup2.4-1 2.56.0-2+deb9u1
ii libsystemd0 232-25+deb9u1
ii libteamdctl0 1.26-1+b1
ii libuuid1 2.29.2-1
ii lsb-base 9.20161125
ii policykit-1 0.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 <none>

-- no debconf information

[Jérôme]

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?

[Jeremy Bicha]

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

[Diego Escalante Urrelo]

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

[Alkis Georgopoulos]

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.

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

[Andrej Shadura]

Post by Alkis Georgopoulos
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.

[Andrej Shadura]

Post by Andrej Shadura

Post by Alkis Georgopoulos
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.

[Alkis Georgopoulos]

Post by Andrej Shadura
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!

[Alkis Georgopoulos]

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?

[Alkis Georgopoulos]

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.

[John Scott]

Control: unblock 895696 by -1
Control: forcemerge 895696 870159
Control: affects -1 firmware-ath9k-htc
Control: reassign 895696 wpasupplicant
Control: forcemerge -1 895696

Debian bug number was missed in the changelog, but this has been fixed, and I
can also report that this was also the cause of issues with ath9k-htc. I'm
merging in those and will mark done momentarily.

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 <***@debian.org> Tue, 24 Mar 2020 11:13:16 +0100