Re: [systemd-devel] networkd-218 seems to ignore .link files
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-:01:00.0
Driver: r8169 [...]
# cat /etc/systemd/network/01-mgmt.link
[Match]
Path=pci-: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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, May 19, 2015 at 6:57 PM, Jan Engelhardt jeng...@inai.de wrote:
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-:01:00.0
Driver: r8169 [...]
# cat /etc/systemd/network/01-mgmt.link
[Match]
Path=pci-: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_.
True, but not always to something useful (which is why we special case
ARPHRD_ETHER and DEVTYPE==wlan|wwan).
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.
I'd rather we just decide on some scheme once and for all. Interim
solutions have a way of becoming permanent...
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tuesday 2015-05-19 19:03, Tom Gundersen wrote: Unlike hwdevtype, arphrd is at least set _all the time_. True, but not always to something useful (which is why we special case ARPHRD_ETHER and DEVTYPE==wlan|wwan). How so? If ethernet frames is what the OS has to send to the device to make me be able to use that network, then FWIW, it's Ethernet alright. Most people's networks, too, are Ethernet, even though the router might be doing some PPP over ADSL (and deep down, I hear they threw in ATM _as well_). Having link/ppp or link/atm be shown for WWAN seems even less useful than link/ether. :p ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, Apr 21, 2015 at 6:26 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 21.04.15 14:47, Tom Gundersen (t...@jklm.no) wrote: I'm having a similar problem while running systemd version-219. Did you work out what was wrong? My link file is ignored even when I symlink /etc/systemd/network/99-default.link to /dev/null. I don't see anything interesting in 'journalctl'. # udevadm info /sys/class/net/eth0 P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Contror E: ID_MODEL_ID=0x8168 E: ID_NET_DRIVER=r8169 E: ID_NET_NAME_MAC=enx000db936008c E: ID_NET_NAME_PATH=enp1s0 E: ID_OUI_FROM_DATABASE=PC Engines GmbH E: ID_PATH=pci-:01:00.0 E: ID_PATH_TAG=pci-_01_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. E: ID_VENDOR_ID=0x10ec E: IFINDEX=3 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=53326 # networkctl status --no-pager eth0 ��● 3: eth0 Link File: n/a Network File: n/a Type: ether State: off (unmanaged) Path: pci-:01:00.0 Driver: r8169 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH) MTU: 1500 # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-: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. We probably should not do that, or allow the same to be used in the .link matching logic (the heuristic is unlikely to be perfect, so I hesitate a bit with the latter). What precisely is the heuristic? To assume that things are ethernet if not otherwise specified? Honestly, I think that's good enough, and probably widely accepted. If this goes wrong I am pretty sure that's something to fix in the driver, by simply exposing the type then... 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. 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. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, Apr 14, 2015 at 7:08 PM, Andrew Cooks aco...@linux.com wrote: On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt jeng...@inai.de wrote: On Monday 2015-01-12 18:29, Tom Gundersen wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? Well, the manpage states: All link files are collectively sorted and processed in lexical order, with that, I would assume that 99a, being processed after 99, would override 99. It works for me when naming it 98-ether.link instead. Not in my case. I have a feeling networkd won't touch [08:00:27:0a:c5:b2]'s interface name because it has already been named by udev to enp0s3 before networkd got a chance to run. Could that be it? I'm having a similar problem while running systemd version-219. Did you work out what was wrong? My link file is ignored even when I symlink /etc/systemd/network/99-default.link to /dev/null. I don't see anything interesting in 'journalctl'. # udevadm info /sys/class/net/eth0 P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Contror E: ID_MODEL_ID=0x8168 E: ID_NET_DRIVER=r8169 E: ID_NET_NAME_MAC=enx000db936008c E: ID_NET_NAME_PATH=enp1s0 E: ID_OUI_FROM_DATABASE=PC Engines GmbH E: ID_PATH=pci-:01:00.0 E: ID_PATH_TAG=pci-_01_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. E: ID_VENDOR_ID=0x10ec E: IFINDEX=3 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=53326 # networkctl status --no-pager eth0 ��● 3: eth0 Link File: n/a Network File: n/a Type: ether State: off (unmanaged) Path: pci-:01:00.0 Driver: r8169 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH) MTU: 1500 # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-: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. We probably should not do that, or allow the same to be used in the .link matching logic (the heuristic is unlikely to be perfect, so I hesitate a bit with the latter). Cheers, Tom [Link] Name=mgmt MACAddressPolicy=persistent ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, 21.04.15 11:42, Andrew Cooks (aco...@linux.com) wrote: # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-:01:00.0 Type=ether [Link] Name=mgmt MACAddressPolicy=persistent Consider testing the .link file with udevadm test-builtin net_setup_link... Thanks, this is exactly what I needed to find the problem. There were two issues with my .link file: I needed to call my local override 100-mgmt.link instead of 01-mgmt.link. IMHO, the ordering of the .link files is somewhat unfortunate, even though the documentation did try to explain it. Secondly, the Path in the [Match] section was wrong. The examples use pci-:xx:yy.0-* and 'udevadm info /sys/class/net/enp1s0' shows 'ID_PATH=pci-:01:00.0' (exactly what I used, as the man page instructs), but it only started working when I tried 'Path=*:01:00.0*'. Hmm, that's really weird. This should work without the *, too. Are really *both* the trailing and starting * necessary? Could you please file a bug about this in fdo bz? This is something to fix, and we shouldn't forget about it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, 21.04.15 14:47, Tom Gundersen (t...@jklm.no) wrote: I'm having a similar problem while running systemd version-219. Did you work out what was wrong? My link file is ignored even when I symlink /etc/systemd/network/99-default.link to /dev/null. I don't see anything interesting in 'journalctl'. # udevadm info /sys/class/net/eth0 P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Contror E: ID_MODEL_ID=0x8168 E: ID_NET_DRIVER=r8169 E: ID_NET_NAME_MAC=enx000db936008c E: ID_NET_NAME_PATH=enp1s0 E: ID_OUI_FROM_DATABASE=PC Engines GmbH E: ID_PATH=pci-:01:00.0 E: ID_PATH_TAG=pci-_01_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. E: ID_VENDOR_ID=0x10ec E: IFINDEX=3 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=53326 # networkctl status --no-pager eth0 ��● 3: eth0 Link File: n/a Network File: n/a Type: ether State: off (unmanaged) Path: pci-:01:00.0 Driver: r8169 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH) MTU: 1500 # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-: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. We probably should not do that, or allow the same to be used in the .link matching logic (the heuristic is unlikely to be perfect, so I hesitate a bit with the latter). What precisely is the heuristic? To assume that things are ethernet if not otherwise specified? Honestly, I think that's good enough, and probably widely accepted. If this goes wrong I am pretty sure that's something to fix in the driver, by simply exposing the type then... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Mon, 20.04.15 13:17, Ian Pilcher (arequip...@gmail.com) wrote: On 04/20/2015 01:06 PM, Lennart Poettering wrote: On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote: I would love to be able to set the MTU of a physical interface in a .network file. Is this possible? (The systemd.network(5) doesn't list it.) Yes, this is supported via MTU=. This needs documentation indeed. Hmm. I've just tried both MTU and MTUBytes with no effect. E.g.: [Match] Name=eno1 [Network] Address=172.31.250.1/24 Gateway=172.31.250.254 DNS=172.31.250.254 MTUBytes=5000 (Unless this requires something later than systemd 216 on Fedora 21.) It needs to be in a [Link] section in the .network file. The option is indeed called MTUBytes= though. Oh, and as I see now all this is actually correctly documented in systemd.network(5)... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, Apr 21, 2015 at 12:40 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 15.04.15 01:08, Andrew Cooks (aco...@linux.com) wrote: On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt jeng...@inai.de wrote: On Monday 2015-01-12 18:29, Tom Gundersen wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? Well, the manpage states: All link files are collectively sorted and processed in lexical order, with that, I would assume that 99a, being processed after 99, would override 99. It works for me when naming it 98-ether.link instead. Not in my case. I have a feeling networkd won't touch [08:00:27:0a:c5:b2]'s interface name because it has already been named by udev to enp0s3 before networkd got a chance to run. Could that be it? Note that networkd doesn't rename interfaces, only udev does. udev implements .link processing, nothing else. I'm having a similar problem while running systemd version-219. Did you work out what was wrong? Maybe this is debian and the saving of interface names is still in place? Nope, sorry, this is based on yocto. The good news is that all legacy stuff can be safely ignored. # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-:01:00.0 Type=ether [Link] Name=mgmt MACAddressPolicy=persistent Consider testing the .link file with udevadm test-builtin net_setup_link... Thanks, this is exactly what I needed to find the problem. There were two issues with my .link file: I needed to call my local override 100-mgmt.link instead of 01-mgmt.link. IMHO, the ordering of the .link files is somewhat unfortunate, even though the documentation did try to explain it. Secondly, the Path in the [Match] section was wrong. The examples use pci-:xx:yy.0-* and 'udevadm info /sys/class/net/enp1s0' shows 'ID_PATH=pci-:01:00.0' (exactly what I used, as the man page instructs), but it only started working when I tried 'Path=*:01:00.0*'. # udevadm test-builtin net_setup_link /sys/class/net/enp1s0 calling: test-builtin === trie on-disk === tool version: 219 file size: 6685604 bytes header size 80 bytes strings1715076 bytes nodes 4970448 bytes Load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /etc/systemd/network/enp3s0.link Parsed configuration file /etc/systemd/network/enp2s0.link Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/100-mgmt.link Created link configuration context. device 0xb77f6040 has devpath '/devices/pci:00/:00:04.0/:01:00.0/ne' ID_NET_DRIVER=r8169 device 0xb77f6040 filled with db file data device 0xb77f6940 has devpath '/devices/pci:00/:00:04.0/:01:00.0' Config file /lib/systemd/network/99-default.link applies to device enp1s0 ID_NET_LINK_FILE=/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context. # cat 100-mgmt.link [Match] Path=*:01:00.0* [Link] Name=ManagementPort MACAddressPolicy=persistent Thanks for the help, Lennart! a. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On 01/12/2015 05:38 PM, Tom Gundersen wrote: Some of the .link settings may make sense to tweak also per-network, in which case we support changing them in .network files. I would love to be able to set the MTU of a physical interface in a .network file. Is this possible? (The systemd.network(5) doesn't list it.) -- Ian Pilcher arequip...@gmail.com I grew up before Mark Zuckerberg invented friendship ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote: On 01/12/2015 05:38 PM, Tom Gundersen wrote: Some of the .link settings may make sense to tweak also per-network, in which case we support changing them in .network files. I would love to be able to set the MTU of a physical interface in a .network file. Is this possible? (The systemd.network(5) doesn't list it.) Yes, this is supported via MTU=. This needs documentation indeed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On 04/20/2015 01:06 PM, Lennart Poettering wrote: On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote: I would love to be able to set the MTU of a physical interface in a .network file. Is this possible? (The systemd.network(5) doesn't list it.) Yes, this is supported via MTU=. This needs documentation indeed. Hmm. I've just tried both MTU and MTUBytes with no effect. E.g.: [Match] Name=eno1 [Network] Address=172.31.250.1/24 Gateway=172.31.250.254 DNS=172.31.250.254 MTUBytes=5000 (Unless this requires something later than systemd 216 on Fedora 21.) -- Ian Pilcher arequip...@gmail.com I grew up before Mark Zuckerberg invented friendship ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Wed, 15.04.15 01:08, Andrew Cooks (aco...@linux.com) wrote: On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt jeng...@inai.de wrote: On Monday 2015-01-12 18:29, Tom Gundersen wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? Well, the manpage states: All link files are collectively sorted and processed in lexical order, with that, I would assume that 99a, being processed after 99, would override 99. It works for me when naming it 98-ether.link instead. Not in my case. I have a feeling networkd won't touch [08:00:27:0a:c5:b2]'s interface name because it has already been named by udev to enp0s3 before networkd got a chance to run. Could that be it? Note that networkd doesn't rename interfaces, only udev does. udev implements .link processing, nothing else. I'm having a similar problem while running systemd version-219. Did you work out what was wrong? Maybe this is debian and the saving of interface names is still in place? # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-:01:00.0 Type=ether [Link] Name=mgmt MACAddressPolicy=persistent Consider testing the .link file with udevadm test-builtin net_setup_link... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt jeng...@inai.de wrote: On Monday 2015-01-12 18:29, Tom Gundersen wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? Well, the manpage states: All link files are collectively sorted and processed in lexical order, with that, I would assume that 99a, being processed after 99, would override 99. It works for me when naming it 98-ether.link instead. Not in my case. I have a feeling networkd won't touch [08:00:27:0a:c5:b2]'s interface name because it has already been named by udev to enp0s3 before networkd got a chance to run. Could that be it? I'm having a similar problem while running systemd version-219. Did you work out what was wrong? My link file is ignored even when I symlink /etc/systemd/network/99-default.link to /dev/null. I don't see anything interesting in 'journalctl'. # udevadm info /sys/class/net/eth0 P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Contror E: ID_MODEL_ID=0x8168 E: ID_NET_DRIVER=r8169 E: ID_NET_NAME_MAC=enx000db936008c E: ID_NET_NAME_PATH=enp1s0 E: ID_OUI_FROM_DATABASE=PC Engines GmbH E: ID_PATH=pci-:01:00.0 E: ID_PATH_TAG=pci-_01_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. E: ID_VENDOR_ID=0x10ec E: IFINDEX=3 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=53326 # networkctl status --no-pager eth0 ��● 3: eth0 Link File: n/a Network File: n/a Type: ether State: off (unmanaged) Path: pci-:01:00.0 Driver: r8169 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH) MTU: 1500 # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-:01:00.0 Type=ether [Link] Name=mgmt MACAddressPolicy=persistent ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Monday 2015-01-12 18:29, Tom Gundersen wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? Well, the manpage states: All link files are collectively sorted and processed in lexical order, with that, I would assume that 99a, being processed after 99, would override 99. It works for me when naming it 98-ether.link instead. Not in my case. I have a feeling networkd won't touch [08:00:27:0a:c5:b2]'s interface name because it has already been named by udev to enp0s3 before networkd got a chance to run. Could that be it? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Mon, Jan 12, 2015 at 11:46 PM, Jan Engelhardt jeng...@inai.de wrote: On Monday 2015-01-12 18:29, Tom Gundersen wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? Well, the manpage states: All link files are collectively sorted and processed in lexical order, with that, I would assume that 99a, being processed after 99, would override 99. So the ordering is correct, but not its semantics. Later in the same manpage it is explained: The first (in lexical order) of the link files that matches a given device is applied. In other words, since '99-' is ordered before '99a' only '99-' is applied and '99a' is ignored. It works for me when naming it 98-ether.link instead. Not in my case. I have a feeling networkd won't touch [08:00:27:0a:c5:b2]'s interface name because it has already been named by udev to enp0s3 before networkd got a chance to run. Could that be it? Ah, link files are applied by udev (and udev only). They are meant as a way to set sane network-agnostic values when the device first appears. If you think some of the documentation is unclear on this point, please let me know. Some of the .link settings may make sense to tweak also per-network, in which case we support changing them in .network files. This does not apply to interface names though, as changing that at run-time tends to cause lots of problems. We therefore make sure that the interface name is only ever changed by udev, and only before the presence of the device is announced via libudev to the rest of userspace. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
Hi Jan, On Mon, Jan 12, 2015 at 12:20 AM, Jan Engelhardt jeng...@inai.de wrote: In systemd-218, I have configured the following testcase: /etc/systemd/network# ls -al total 20 drwxr-xr-x 2 root root 4096 Jan 11 18:14 . drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link Hm, isn't this just a problem of 99a-ether.link being ordered after 99-default.link? It works for me when naming it 98-ether.link instead. -rw-r--r-- 1 root root 241 Jan 11 18:12 brd0.network -rw-r--r-- 1 root root 56 Jan 11 18:12 brg0.netdev # cat 99a-ether.link [Match] MACAddress=08:00:27:0a:c5:b2 [Link] Description=ethernet_link Alias=ether0 Name=ether0 # systemctl status -l systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2015-01-11 18:14:59 EST; 39s ago Docs: man:systemd-networkd.service(8) Main PID: 417 (systemd-network) Status: Processing requests... CGroup: /system.slice/systemd-networkd.service └─417 /usr/lib/systemd/systemd-networkd Jan 11 18:14:59 jng-sfac systemd-networkd[417]: brg0: netdev ready Jan 11 18:14:59 jng-sfac systemd[1]: Started Network Service. Why would it be ignoring the link definition file for ether0? If I invoke `rmmod e1000; modprobe e1000`, systemctl status has one extra line to say: Jan 11 18:17:52 jng-sfac systemd-networkd[417]: eth0: renamed to enp0s3 The L2 address is certainly correct: 2: enp0s3: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 08:00:27:0a:c5:b2 brd ff:ff:ff:ff:ff:ff I'm not able to reproduce this with current git. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
