[systemd-devel] networkd-218 seems to ignore .link files

Jan Engelhardt jengelh at inai.de
Tue May 19 09:57:19 PDT 2015


On Tuesday 2015-05-19 18:38, Tom Gundersen wrote:
>>> > # networkctl status --no-pager eth0
>>> > ??????● 3: eth0
>>> >    Link File: n/a
>>> > Network File: n/a
>>> >         Type: ether
>>> >        State: off (unmanaged)
>>> >         Path: pci-0000:01:00.0
>>> >       Driver: r8169 [...]
>>> > # cat /etc/systemd/network/01-mgmt.link
>>> > [Match]
>>> > Path=pci-0000:01:00.0
>>> > Type=ether
>>>
>>> Type must be the same as what is returned in DEVTYPE=, which I guess
>>> is unset for this device. So drop this and it should work.
>>>
>>> I see where the confusion stems from though, as we try to be helpful
>>> and use a heuristic to print a Type in networkctl even when the kernel
>>> does not expose a type. [...]
>>
>> What precisely is the heuristic?[...]
>
>There are two 'types', the ARP hardware identifier (link type as
>exposed over rtnl) and the DEVTYPE (as exposed by libudev). The
>matching logic only uses DEVTYPE.

Unlike hwdevtype, arphrd is at least set _all the time_.

>The output of networkctl (and the udev naming to a more limited degree) uses
>the ARP hardware identifier and then falls back to DEVTYPE in the case of
>ethernet devices to distinguish wlan and wwan interfaces from other kinds of
>ethernet interfaces.
>
>In an ideal world, we would only use DEVTYPE and the kernel would
>assign this reasonably to all devices. In the meantime we could do
>some combination of DEVTYPE and ARPHRD, but the danger here is that we
>will lock ourselves into some heuristic and make it impossible to
>improve the kernel DEVTYPE's in the future as it would change the
>behavior of current setups, which is why I have preferred to not
>support any matching when DEVTYPE is not set. I'm very open to change
>this if anyone has a convincing scheme in mind though.

So, perhaps just making networkd support both DevType={match on DEVTYPE string}
and LinkType={ether,loopback,other ARPHRD_* constants} be the interim solution
for that.


More information about the systemd-devel mailing list