netplan does not generates .network files just for ethernet

Bug #1618522 reported by Simon Fels on 2016-08-30
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nplan (Ubuntu)
Medium
Unassigned
systemd (Ubuntu)
Low
Unassigned

Bug Description

On my pi3 I have an image with the ubuntu-core snap rev 354 and I get the following netplan configuration file after the first boot:

ubuntu@localhost:~$ cat /etc/netplan/00-initial-config.yaml
network:
 version: 2
 ethernets:
   all:
    match:
     name: "*"
    dhcp4: true

This generates the following .networkd file

ubuntu@localhost:~$ cat /run/systemd/network/10-netplan-all.network
[Match]
Name=*

[Network]
DHCP=ipv4

If I look now at the output of networkctl I see it also tries to manage my mlan0 device which is a WiFi one and should be managed according to the netplan rule:

ubuntu@localhost:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier configured
  5 eth1 ether no-carrier configuring
  6 eth0 ether routable configured
  7 mlan0 wlan no-carrier configuring

In summary, the networkd generator inside netplan currently does not limit the generated .network file to tell networkd to only look at ethernet devices but rather tell it to control every device available on the system.

Expectation: Specifying a wildcard rule in a netplan configuration file for ethernet devices should tell the configured networking system to only consider ethernet devices and nothing else.

Simon Fels (morphis) on 2016-08-30
description: updated
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nplan (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) on 2016-08-30
Changed in nplan (Ubuntu):
status: Confirmed → In Progress
importance: Undecided → Medium
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) on 2016-09-01
Changed in nplan (Ubuntu):
milestone: none → ubuntu-16.09
Martin Pitt (pitti) wrote :

This is unfortunately really hairy. networkd, NM etc. have "Type=" fields, which more or less match on the DEVTYPE uevent property. This is properly set for wifis, but it's empty for actual ethernets and also for vlans, some wifi devices, etc. So while I can set the restriction for "wifis:", the attached patch does not actually work as the device type is never actually "ether" (or similar).

So I'm afraid this is currently unfixable at the netplan/networkd/NM level and we need to work around this by replacing the matching of "*" to "en*".

Changed in nplan (Ubuntu):
status: In Progress → Triaged
assignee: Martin Pitt (pitti) → nobody
milestone: ubuntu-16.09 → none
tags: added: patch
Michael Hudson-Doyle (mwhudson) wrote :

Ugggh. Can we at least think about what would be involved in fixing this in the kernel or wherever so it's not a problem forever?

Michael Hudson-Doyle (mwhudson) wrote :

I proposed https://github.com/snapcore/snapd/pull/1830 to work around this.

Martin Pitt (pitti) wrote :

One way to improve that in userspace would be to at least allow a way to match on "no devtype" in networkd. You cannot currently say Type="" or similar.

Lennart Poettering> hmm, for networkctl we patch that to make this more useful to look at
Lennart Poettering> shouldn'we just do the same in networkd
Lennart Poettering> i.e. accept our fate?
Lennart Poettering> i am pretty sure "networkctl" should show in the Type column precisely the types you can [Match] on, no?
Tom Gundersen> yeah, i guess we can just do that

Changed in systemd (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Michael Hudson-Doyle (mwhudson) wrote :

That makes sense I guess. It seems networkctl prints "Type: ether" for things that have DEVTYPE=bridge, just to make things more confusing?

This is somewhat related to https://github.com/systemd/systemd/issues/3998.

For now, there's still no way to do this in systemd; it will require an upstream fix.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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