Setting MTU or MAC in wifi device affects other devices

Bug #1769550 reported by Daniel Axtens
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Netplan
Confirmed
Undecided
Unassigned

Bug Description

I have a machine with the following network cards, per `ip l`:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:11:fe:31 brd ff:ff:ff:ff:ff:ff
3: ens7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:0f:51:ad brd ff:ff:ff:ff:ff:ff
4: ens8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:10:2d:ff brd ff:ff:ff:ff:ff:ff

ens3 is configured by cloud-init, and ens7 and ens8 are unconfigured.

To support a usb wifi that is only sometimes present, I add the following netplan config file in /etc/netplan/10-wifi.yaml:

network:
  version: 2
  wifis:
    usbwlan:
      renderer: NetworkManager
      match: {}
      access-points:
        "open-ap": {}
      dhcp4: true
      mtu: 1280

Then I run `netplan apply`. (The usb device is not present at this point, and there are no other wifi devices.)

If I run `ip l` again, I see that the MTUs of lo, ens7 and ens8 have all been changed to 1280:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:11:fe:31 brd ff:ff:ff:ff:ff:ff
5: eth0: <BROADCAST,MULTICAST> mtu 1280 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:0f:51:ad brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST> mtu 1280 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:10:2d:ff brd ff:ff:ff:ff:ff:ff

This seems to be due to the creation of /run/systemd/network/10-netplan-usbwlan.link, which reads:

[Match]

[Link]
WakeOnLan=off
MTUBytes=1280

This is created despite 'renderer: NetworkManager' in 10-wifi.yaml I suspect systemd-networkd is interpreting the empty [Match] as a wildcard and matching *everything* that doesn't have a more specific configuration, hence the matching on lo, ens7 and ens8.

======
Update
======

The same problem also affects MAC addresses:

network:
  version: 2
  wifis:
    usbwlan:
      renderer: NetworkManager
      match: {}
      access-points:
        "open-ap": {}
      dhcp4: true
      mtu: 1280
      macaddress: 00:11:22:33:44:55

leads to:

ubuntu@netplan2:~$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:11:22:33:44:55 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
...
11: wlx000b819914fd: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1280 qdisc fq_codel state DOWN mode DORMANT group default qlen 1000
    link/ether 00:0b:81:99:14:fd brd ff:ff:ff:ff:ff:ff

lo and ens7 etc have had their mac addresses changed. (Ironically, wlx* hasn't) It's the same fundamental issue that the match stanza is too broadly drawn for udev.

No doubt wake-on-lan would have the same issue as it's also specified in the link file, but I haven't checked.

Revision history for this message
Ryan Harper (raharper) wrote :

The current implementation writes link files for all interfaces since udev processes .link files no matter of backend choice.

It may be possible to skip the .link file for properties that NetworkManager can handle; it appears that NetworManager will apply MTU changes, but unlikely that it will attempt to rename an interface.

Could you:

1) remove /run/systemd-network/10-netplan-usbwlan.link
2) manually set the MTU on your wlan interface to 1500 (the default)
3) restart NetworkManager and check if that applies the MTU correctly?

Alternatively, you could look to tighten the Match properties, for example:

wifis:
  usbwlan:
    match:
       driver: iwlwifi

replacing the driver value with the one you use:

ethtool -i <name of wlan interface>

Changed in netplan:
status: New → Confirmed
Revision history for this message
Daniel Axtens (daxtens) wrote :

Hi Ryan,

Sorry, I missed your update somehow; I will try to test your suggestions shortly.

Regards,
Daniel

Revision history for this message
Daniel Axtens (daxtens) wrote :

Hi Ryan,

I tested your steps - I removed the file, I set the MTU to 1500 and I did 'service NetworkManager restart'. The MTU stayed at 1500.

I tried using a driver match. That worked, but the docs suggest it should not be needed.

Regards,
Daniel

Revision history for this message
Daniel Axtens (daxtens) wrote :

I've also added an update showing how this can also set the MAC addresses of devices as well as the MTU.

summary: - Setting MTU in wifi device affects other devices
+ Setting MTU or MAC in wifi device affects other devices
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.