Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
22.05.2020 22:17, Ede Wolf пишет: > Am 22.05.20 um 17:58 schrieb Andrei Borzenkov: >>> >>> The problem is, that sysctl.conf is being executed before the interfaces >>> get their eventual names. >>> >> >> That sounds like actual bug. What systemd version do you use? > > At least it is, what the journal suggest, as seen below. However, > generally it sounds like a good idea to read sysctl.conf as early as > possible > > > As for my version: > > $ pacman -Qs systemd > local/systemd 245.5-2 > system and service manager > local/systemd-libs 245.5-2 > systemd client libraries > local/systemd-sysvcompat 245.5-2 > sysvinit compat for systemd > > $ uname -a > Linux willy 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 > + x86_64 GNU/Linux > > Same issues with the arch lts-kernel, this behaviour is consistent and > easily reproducable. > > > And the logs read: > > journalctl -b0 | grep -E 'sysctl|ens3|eth0' > 08:56:46 systemd[263]: systemd-sysctl.service: Executing: > /usr/lib/systemd/systemd-sysctl > 08:56:46 systemd-sysctl[263]: Couldn't write '2' to > 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or > directory > 08:56:46 systemd-sysctl[263]: Couldn't write '2' to > 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory Sorry, I did not pay attention. Errors come from systemd-syctl service which indeed runs concurrently with udev and races with interface renaming. But udev also applies settings individually to each interface, see below. > 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 > 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed > dead > -> plugged > 08:56:47 systemd[1]: > sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed > dead -> plugged > 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, > ens3 has been renamed to eth0. >> >> I wonder where this comes from. >> > 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, > eth0 has been renamed to ens3. > 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled > 08:56:51 systemd-networkd[459]: ens3: Link UP > 08:56:51 systemd-networkd[459]: ens3: Gained carrier > ... > > Same wonders here, but, despite the mysterial double renaming, > systemd-sysctl is still being called before even the first rename. A > good second here. So I have no chance to set any values for ens3 at all. > Given lack of errors after interface rename, settings were most probably applied correctly. > >> >> udev applies sysctl just once - when interface first appears. > > Any deeper insight on this? I was under the impression, sysctl is read > by systemd-sysctl only and not by udev at all? But admittedly, I am not > very knowledgable here. So I'd like to improve. > udev invokes systemd-sysctl for specific interface as part of event processing, normally in 99-systemd.rules but of course could be anywhere. Just search for systemd-sysctl in rules files. > >> using final name (that can be different from initial kernel name). So if >> device appeared under eth0 and got name ens3 during event procesing, >> udev applies sysctl to ens3 and never to eth0. If udev applied settings >> to eth0 before rename, these settings would be preserved after rename. > > That does at least not correspond to my observation. > > It seems, the kernel creates > > net/ipv6/conf/eth0/use_tempaddr > > upon detection and after renaming, > > net/ipv6/conf/ens3/use_tempaddr > > does not keep the values. > tw:~ # systemctl stop NetworkManager.service tw:~ # ip l set dev enp0s5 down tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr 1 tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode 1 tw:~ # echo 3 > /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode tw:~ # echo 2 > /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr 2 tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode 3 tw:~ # ip l set dev enp0s5 name ififif tw:~ # ip l set dev ififif up tw:~ # cat /proc/sys/net/ipv6/conf/ififif/use_tempaddr 2 tw:~ # cat /proc/sys/net/ipv6/conf/ififif/addr_gen_mode 3 What likely happens in your case is something else changes settings after they had been applied by udev. Notice I had to stop NetworkManager to avoid interfering as soon as link comes up. > Is there a way to make systemd-sysctl a bit more verbose, so we can see > wether the eth0 setting are actually being applied? > Sure, you can simply set SYSTEMD_LOG_LEVEL=debug on kernel command line and it will apply to all systemd components or you can set this variable for specific service. But as mentioned earlier, errors that you see are red herring - they are literally expected if you attempt to set sysctl values for individual interface globally. Or you must make sure interface gets final name before systemd-sysctl.service runs, e.g. in initrd. > So fa
Re: [systemd-devel] What is the point of making timesyncd bus-activatible?
On Tue, 19 May 2020 at 10:31, Arian Van Putten wrote: > > Hey list, > > systemd-timesyncd has an Alias=dbus-org.freedesktop.timesync1.service and an > accompanying dbus service file too. > > It is started in early boot; `Before=sysinit.target` so why would making it > dubs-activatible ever make sense? It is always started way before > dbus.service itself is started. > > It also seems that the unit type is not Type=dbus (and doesn't set a BusName) > which confuses me a bit. So maybe I'm misunderstanding how dbus integration > works here. Ist that because we want to consider the services "ready" before > they even register a name on the bus? > > Similarly systemd-resolved.service and systemd-networkd.service have such > aliases whilst they're both pulled in by `multi-user.target` and also do not > have `Type=dbus` and `BusName=` set. > > What are the reasons for that? For resolve1 i guess it makes sense as you > dont have to think about ordering when making dns calls in services. But I am > still confused why it is not of Type=dbus. Is that because it not only gives > a dbus API but also a DNS api? > it serves requests on 127.0.0.53 and provides dynamic files generated in /run/systemd/resolve/ which can be targets of /etc/resolv.conf symlink. Hence even without anything talking to it over dbus or lo interface, it can be serving information to the system. I.e. it populates both /run/systemd/resolve/resolv.conf and /run/systemd/resolve/stub-resolv.conf either of which can be symlinked to /etc/resolv.conf for nss modules to use. -- Regards, Dimitri. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
However, all is not gold with Deepin as well, as when using a .link file in /etc/systemd/network to rename the interface, Deeping as well does not work any more. Here, eth0 aka enp0s3 aka custom lan-01: # journalctl -b0 | grep -E 'sysctl|lan-01|enp0s3|eth0' May 22 22:31:22 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 22:31:22 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 22:31:22 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/lan-01/stable_secret', ignoring: No such file or directory May 22 22:31:22 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/lan-01/addr_gen_mode', ignoring: No such file or directory May 22 22:31:22 test1-PC kernel: virtio_net virtio0 lan-01: renamed from enp0s3 May 22 22:31:22 test1-PC systemd-networkd[267]: enp0s3: Interface name change detected, enp0s3 has been renamed to lan-01. May 22 22:31:22 test1-PC systemd-networkd[267]: lan-01: Gained carrier So we have the renaming from kernel ethx to sytemd persistent, then systemd-sysctl, and then again the renaming from the systemd persistent to the user defined .link file. Same is true, when using an udev rule to customly rename an interface instead of a .link file: root@test1-PC:~# journalctl -b0 | grep -E 'sysctl|lan-01|enp0s3|eth0' May 22 22:41:01 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 22:41:01 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 22:41:01 test1-PC systemd-sysctl[258]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/lan-01/stable_secret', ignoring: No such file or directory May 22 22:41:01 test1-PC systemd-sysctl[258]: Couldn't write '2' to 'net/ipv6/conf/lan-01/addr_gen_mode', ignoring: No such file or directory May 22 22:41:01 test1-PC kernel: virtio_net virtio0 lan-01: renamed from enp0s3 May 22 22:41:01 test1-PC systemd-networkd[263]: enp0s3: Interface name change detected, enp0s3 has been renamed to lan-01. May 22 22:41:01 test1-PC systemd-networkd[263]: lan-01: Gained carrier Am 22.05.20 um 21:50 schrieb Ede Wolf: That sounds like actual bug. What systemd version do you use? I've just did a test with Deepin, as I've had VM flying around of that debian based distribution, and here it seems to work, using systemd 241 instead of 245. systemd-sysctl is clearly called after the renaming: May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier So here eth0 is the invalid interface, as it should be. Not sure now wether this a regression or distribution specific. Where are the dependencies defined what service runs first at this early stage? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
There are other issues with either systemd-245 or arch. When NOT using any net.ipv6.conf.xxx.use_tempaddr=2 statements in sysctl.conf, but instead are only using IPv6PrivacyExtensions=yes on arch/systemd-245 this setting gets ignored. On Deepin however a temporary address is assigned, as expected. Am 22.05.20 um 21:50 schrieb Ede Wolf: That sounds like actual bug. What systemd version do you use? I've just did a test with Deepin, as I've had VM flying around of that debian based distribution, and here it seems to work, using systemd 241 instead of 245. systemd-sysctl is clearly called after the renaming: May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier So here eth0 is the invalid interface, as it should be. Not sure now wether this a regression or distribution specific. Where are the dependencies defined what service runs first at this early stage? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
That sounds like actual bug. What systemd version do you use? I've just did a test with Deepin, as I've had VM flying around of that debian based distribution, and here it seems to work, using systemd 241 instead of 245. systemd-sysctl is clearly called after the renaming: May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier So here eth0 is the invalid interface, as it should be. Not sure now wether this a regression or distribution specific. Where are the dependencies defined what service runs first at this early stage? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Am 22.05.20 um 17:58 schrieb Andrei Borzenkov: The problem is, that sysctl.conf is being executed before the interfaces get their eventual names. That sounds like actual bug. What systemd version do you use? At least it is, what the journal suggest, as seen below. However, generally it sounds like a good idea to read sysctl.conf as early as possible As for my version: $ pacman -Qs systemd local/systemd 245.5-2 system and service manager local/systemd-libs 245.5-2 systemd client libraries local/systemd-sysvcompat 245.5-2 sysvinit compat for systemd $ uname -a Linux willy 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 + x86_64 GNU/Linux Same issues with the arch lts-kernel, this behaviour is consistent and easily reproducable. And the logs read: journalctl -b0 | grep -E 'sysctl|ens3|eth0' 08:56:46 systemd[263]: systemd-sysctl.service: Executing: /usr/lib/systemd/systemd-sysctl 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead -> plugged 08:56:47 systemd[1]: sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed dead -> plugged 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, ens3 has been renamed to eth0. I wonder where this comes from. 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, eth0 has been renamed to ens3. 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled 08:56:51 systemd-networkd[459]: ens3: Link UP 08:56:51 systemd-networkd[459]: ens3: Gained carrier ... Same wonders here, but, despite the mysterial double renaming, systemd-sysctl is still being called before even the first rename. A good second here. So I have no chance to set any values for ens3 at all. udev applies sysctl just once - when interface first appears. Any deeper insight on this? I was under the impression, sysctl is read by systemd-sysctl only and not by udev at all? But admittedly, I am not very knowledgable here. So I'd like to improve. using final name (that can be different from initial kernel name). So if device appeared under eth0 and got name ens3 during event procesing, udev applies sysctl to ens3 and never to eth0. If udev applied settings to eth0 before rename, these settings would be preserved after rename. That does at least not correspond to my observation. It seems, the kernel creates net/ipv6/conf/eth0/use_tempaddr upon detection and after renaming, net/ipv6/conf/ens3/use_tempaddr does not keep the values. Is there a way to make systemd-sysctl a bit more verbose, so we can see wether the eth0 setting are actually being applied? So far we only see the error from ens3, but no positives from the eth0 settings. Nonetheless, this would still impose a problem. As the eth* names are not reliable, faking a setting intended for ens3 to eth0 in sysctl.conf is a bit risky and most likely not the idea behind the whole renaming thingy. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
22.05.2020 15:44, Ede Wolf пишет: > Hello, > > Thanks for replying. As I have written, I am using no custom .rules or > .link file. /etc/udev/rules.d is empty and /etc/systemd/network only > contains .network files. > This is irrelevant. *ANY* rule can set device name which will rename interface. It does not matter whether these rules are in /usr/lib or /etc. Where do you think those "predictable" names come from? Kernel starts always with ethX. > But I believe the problem would not change. As wether I rename an > interface or 99-default.link as part of systemd-networkd does it, should > make no difference. > > The problem is, that sysctl.conf is being executed before the interfaces > get their eventual names. > That sounds like actual bug. What systemd version do you use? > What would work is disabling interface renaming alltogether by adding > net.ifnames=0 to the kernel, but those ethx names are not reliably > persistent. So nothing is really won here. Unless you only have one > interface, that is. > > Unless I have missed somthing, that's why I am asking, those settings > would need to be moved from sysctl.conf to the [Network] section of a > corresponding unit file alltogether, so that systemd has control over it. > > As a workaround I have set default values: > > net.ipv6.conf.default.stable_secret= > net.ipv6.conf.default.addr_gen_mode=2 > net.ipv6.conf.all.addr_gen_mode=2 > > > But I am getting different results on two different machines. One, where > it works even on a systemd renamed link, and one, where it is not. Still > trying to figure out, why that is. > > But the key should be to be able to set those on a per link base, what I > have not been able to do so far at all. > > > > > Am 22.05.20 um 12:21 schrieb Kevin P. Fleming: >> Do you have a udev 'persistent network device name' rules file in >> /etc/udev/rules.d? Many distributions install such a rules file by >> default, and this renames the interfaces to 'standard' names. >> >> On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote: >>> >>> Hello, >>> >>> I am trying to enable temporary and/or stable addresses for a link and >>> am most likely running into troubles with the device naming. However, I >>> do not change any network name myself, neither in udev nor as part or a >>> link file, it's just the standard system settings (from Arch, in case >>> that matters). >>> >>> my sysctl.conf (both ens3 and eth0 refer to the same interface): >>> >>> >>> net.ipv6.conf.ens3.addr_gen_mode = 2 >>> net.ipv6.conf.ens3.use_tempaddr = 2 >>> >>> net.ipv6.conf.eth0.addr_gen_mode = 2 >>> net.ipv6.conf.eth0.use_tempaddr = 2 >>> >>> >>> And the logs read: >>> >>> journalctl -b0 | grep -E 'sysctl|ens3|eth0' >>> 08:56:46 systemd[263]: systemd-sysctl.service: Executing: >>> /usr/lib/systemd/systemd-sysctl >>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to >>> 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory >>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to >>> 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory >>> 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 >>> 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead >>> -> plugged >>> 08:56:47 systemd[1]: >>> sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed >>> dead -> plugged >>> 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, >>> ens3 has been renamed to eth0. I wonder where this comes from. >>> 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, >>> eth0 has been renamed to ens3. >>> 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled >>> 08:56:51 systemd-networkd[459]: ens3: Link UP >>> 08:56:51 systemd-networkd[459]: ens3: Gained carrier >>> ... >>> >>> >>> As it appears to me, the eth0 settings from sysctl.conf have been >>> accepted - at least no errors are logged in this regard -, but are lost, >>> because the interface got renamed afterwards. The ens3 interface was not >>> yet known at time of invoking systemd-sysctl, and therefore we get the >>> errors. That in turn means, the settings are not being applied. >>> udev applies sysctl just once - when interface first appears. It is using final name (that can be different from initial kernel name). So if device appeared under eth0 and got name ens3 during event procesing, udev applies sysctl to ens3 and never to eth0. If udev applied settings to eth0 before rename, these settings would be preserved after rename. >>> To make things worse, in sysctl.conf I've additionally set: >>> >>> net.ipv6.conf.default.stable_secret= >>> net.ipv6.conf.default.addr_gen_mode=2 >>> net.ipv6.conf.all.addr_gen_mode=2 >>> >>> >>> Which results in all IP address having a stable privacy scope link, >>> _execpt_ of course ens3. The one that would be by far most important. >>> >>> What am I missing here? And insight is highly appreciated >>> >>> Thanks >>> >>> Ede >>> __
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Found the reason for this global issue. The not working machine had not been moved to SLAAC, as I've though it was, but had still been configured statically. Bummer. As a workaround I have set default values: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 But I am getting different results on two different machines. One, where it works even on a systemd renamed link, and one, where it is not. Still trying to figure out, why that is. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Hello, Thanks for replying. As I have written, I am using no custom .rules or .link file. /etc/udev/rules.d is empty and /etc/systemd/network only contains .network files. But I believe the problem would not change. As wether I rename an interface or 99-default.link as part of systemd-networkd does it, should make no difference. The problem is, that sysctl.conf is being executed before the interfaces get their eventual names. What would work is disabling interface renaming alltogether by adding net.ifnames=0 to the kernel, but those ethx names are not reliably persistent. So nothing is really won here. Unless you only have one interface, that is. Unless I have missed somthing, that's why I am asking, those settings would need to be moved from sysctl.conf to the [Network] section of a corresponding unit file alltogether, so that systemd has control over it. As a workaround I have set default values: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 But I am getting different results on two different machines. One, where it works even on a systemd renamed link, and one, where it is not. Still trying to figure out, why that is. But the key should be to be able to set those on a per link base, what I have not been able to do so far at all. Am 22.05.20 um 12:21 schrieb Kevin P. Fleming: Do you have a udev 'persistent network device name' rules file in /etc/udev/rules.d? Many distributions install such a rules file by default, and this renames the interfaces to 'standard' names. On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote: Hello, I am trying to enable temporary and/or stable addresses for a link and am most likely running into troubles with the device naming. However, I do not change any network name myself, neither in udev nor as part or a link file, it's just the standard system settings (from Arch, in case that matters). my sysctl.conf (both ens3 and eth0 refer to the same interface): net.ipv6.conf.ens3.addr_gen_mode = 2 net.ipv6.conf.ens3.use_tempaddr = 2 net.ipv6.conf.eth0.addr_gen_mode = 2 net.ipv6.conf.eth0.use_tempaddr = 2 And the logs read: journalctl -b0 | grep -E 'sysctl|ens3|eth0' 08:56:46 systemd[263]: systemd-sysctl.service: Executing: /usr/lib/systemd/systemd-sysctl 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead -> plugged 08:56:47 systemd[1]: sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed dead -> plugged 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, ens3 has been renamed to eth0. 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, eth0 has been renamed to ens3. 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled 08:56:51 systemd-networkd[459]: ens3: Link UP 08:56:51 systemd-networkd[459]: ens3: Gained carrier ... As it appears to me, the eth0 settings from sysctl.conf have been accepted - at least no errors are logged in this regard -, but are lost, because the interface got renamed afterwards. The ens3 interface was not yet known at time of invoking systemd-sysctl, and therefore we get the errors. That in turn means, the settings are not being applied. To make things worse, in sysctl.conf I've additionally set: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 Which results in all IP address having a stable privacy scope link, _execpt_ of course ens3. The one that would be by far most important. What am I missing here? And insight is highly appreciated Thanks Ede ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Do you have a udev 'persistent network device name' rules file in /etc/udev/rules.d? Many distributions install such a rules file by default, and this renames the interfaces to 'standard' names. On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote: > > Hello, > > I am trying to enable temporary and/or stable addresses for a link and > am most likely running into troubles with the device naming. However, I > do not change any network name myself, neither in udev nor as part or a > link file, it's just the standard system settings (from Arch, in case > that matters). > > my sysctl.conf (both ens3 and eth0 refer to the same interface): > > > net.ipv6.conf.ens3.addr_gen_mode = 2 > net.ipv6.conf.ens3.use_tempaddr = 2 > > net.ipv6.conf.eth0.addr_gen_mode = 2 > net.ipv6.conf.eth0.use_tempaddr = 2 > > > And the logs read: > > journalctl -b0 | grep -E 'sysctl|ens3|eth0' > 08:56:46 systemd[263]: systemd-sysctl.service: Executing: > /usr/lib/systemd/systemd-sysctl > 08:56:46 systemd-sysctl[263]: Couldn't write '2' to > 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory > 08:56:46 systemd-sysctl[263]: Couldn't write '2' to > 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory > 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 > 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead > -> plugged > 08:56:47 systemd[1]: > sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed > dead -> plugged > 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, > ens3 has been renamed to eth0. > 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, > eth0 has been renamed to ens3. > 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled > 08:56:51 systemd-networkd[459]: ens3: Link UP > 08:56:51 systemd-networkd[459]: ens3: Gained carrier > ... > > > As it appears to me, the eth0 settings from sysctl.conf have been > accepted - at least no errors are logged in this regard -, but are lost, > because the interface got renamed afterwards. The ens3 interface was not > yet known at time of invoking systemd-sysctl, and therefore we get the > errors. That in turn means, the settings are not being applied. > > To make things worse, in sysctl.conf I've additionally set: > > net.ipv6.conf.default.stable_secret= > net.ipv6.conf.default.addr_gen_mode=2 > net.ipv6.conf.all.addr_gen_mode=2 > > > Which results in all IP address having a stable privacy scope link, > _execpt_ of course ens3. The one that would be by far most important. > > What am I missing here? And insight is highly appreciated > > Thanks > > Ede > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Hello, I am trying to enable temporary and/or stable addresses for a link and am most likely running into troubles with the device naming. However, I do not change any network name myself, neither in udev nor as part or a link file, it's just the standard system settings (from Arch, in case that matters). my sysctl.conf (both ens3 and eth0 refer to the same interface): net.ipv6.conf.ens3.addr_gen_mode = 2 net.ipv6.conf.ens3.use_tempaddr = 2 net.ipv6.conf.eth0.addr_gen_mode = 2 net.ipv6.conf.eth0.use_tempaddr = 2 And the logs read: journalctl -b0 | grep -E 'sysctl|ens3|eth0' 08:56:46 systemd[263]: systemd-sysctl.service: Executing: /usr/lib/systemd/systemd-sysctl 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead -> plugged 08:56:47 systemd[1]: sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed dead -> plugged 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, ens3 has been renamed to eth0. 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, eth0 has been renamed to ens3. 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled 08:56:51 systemd-networkd[459]: ens3: Link UP 08:56:51 systemd-networkd[459]: ens3: Gained carrier ... As it appears to me, the eth0 settings from sysctl.conf have been accepted - at least no errors are logged in this regard -, but are lost, because the interface got renamed afterwards. The ens3 interface was not yet known at time of invoking systemd-sysctl, and therefore we get the errors. That in turn means, the settings are not being applied. To make things worse, in sysctl.conf I've additionally set: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 Which results in all IP address having a stable privacy scope link, _execpt_ of course ens3. The one that would be by far most important. What am I missing here? And insight is highly appreciated Thanks Ede ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
