1

I'm using SuSE 12.2 with custom kernel 4.4.21 (minor changes related to real time environment).

Is it really necessary to down/up the interface during the MAC address change? What I observed is that it is not really necessary (the change succeeds on enabled interface, without a need to turn it off).

However - most of the examples in the internet suggests to down interface, then change the MAC address, and after that up it again, e.g. howtogeek.com. Is this procedure described somewhere in documentation?

saleph
  • 13

2 Answers2

1

Changing the MAC address of an interface is hardware and driver dependent. When the interface is up, more actions must be done to update the interface's state while still running. Some drivers just don't support it, either yet, or because the interface's hardware can't permit such feature.

The modern method to distinguish this capability on an interface is the priv_flag IFF_LIVE_ADDR_CHANGE which appeared in kernel 3.6. I can't tell if before there was an other mechanism for this and if thus it was possible before. One can just run an older kernel and check what's working.

The patch introducing this is:

2012-06-30 net: introduce new priv_flag indicating iface capable of change mac when running

Introduce IFF_LIVE_ADDR_CHANGE priv_flag and use it to disable netif_running() check in eth_mac_addr()

As one can expect, this feature was added right after to a few simple virtual devices, like the dummy interface:

2012-06-30 virtio_net: use IFF_LIVE_ADDR_CHANGE priv_flag
2012-06-30 team: use IFF_LIVE_ADDR_CHANGE priv_flag
2012-06-30 dummy: use IFF_LIVE_ADDR_CHANGE priv_flag

Some examples of further additions of this feature over time, per driver:

2014-06-10 gre: allow changing mac address when device is up
2018-07-03 r8169: fix mac address change

Here's a very old 3Com Tornado network card not allowing this, that I still have available:

# uname -r
4.19.0-0.bpo.6-686-pae
# ethtool -i eth1|grep driver
driver: 3c59x
# lspci|grep 3Com
02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
# ip link set dev eth1 address 02:00:00:00:00:01
RTNETLINK answers: Device or resource busy
# ip link set dev eth1 down
# ip link set dev eth1 address 02:00:00:00:00:01
# ip link set dev eth1 up
# ip link show dev eth1
2: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 02:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff

So the suggestion of having the interface down to change the MAC address still applies here.

A.B
  • 36,364
  • 2
  • 73
  • 118
  • Exactly what I needed, thanks! So if I understand it correctly, the suggestion for down/up interface during mac change is compability related? Just to cover all the cases, also for older NIC/kernels? – saleph Feb 27 '20 at 06:40
  • 1
    Yes, the recommendation covers both older kernels and drivers not supporting this feature. If some tool requires the ability to change MAC while UP for whatever reason, then this should be stated proeminently. The first link for IFF_LIVE_ADDR_CHANGE in my answer gives hints about what drivers support it, but I can't tell if that's all of them. Also note that this doesn't interfere with the ability for a NIC to be used in a bridge: the NIC, now a bridge port, will still be able to send on-the-fly other source MACs different than its own MAC (unless the card is even older and doesn't support it) – A.B Feb 27 '20 at 09:33
1

First of all, and to address your question, you should verify that the new settings shown are already effective. Just don't trust what ifconfig or some command may say - test it. For example by sniffing the traffic from your network interface using tcpdump or Wireshark.

The bigger question is, why do you want to change your MAC address.

If your concern is privacy, that is a perfectly valid reason. But then you should change it before the network service starts. There are different ways of automating this.

If you think about it, it is possible that your computer will already have sent a DHCP request to the network (for instance, if your ethernet cable was plugged in), thus leaking your true MAC address. So changing the MAC address thereafter does not change the fact that the previous (true) address could have leaked (and may have been recorded somewhere).

Network Manager already has options to randomize the MAC address. Or you might be using a plain /etc/network/interfaces file. A pre-up directive will take care of it.

See for example this post for more details.

So doing ifdown, changing MAC address, then ifup manually is probably not good practice if the goal is privacy.

Finally, it's important to keep in mind that a typical DHCP request contains not only the MAC address but also the host name and various identifiers, some of which may be constant/unique. So, merely changing the MAC address may not suffice for anonymisation purposes.

Kate
  • 849
  • I've tested it on a real scenario, if the change didn't happen, our tool won't even start. The reason for MAC change is third party HW requirement for doing that, there is no privacy/security concerns applicable here. – saleph Feb 27 '20 at 06:31