Re: F30->F31 systemd-networkd no IPv6 autoconfiguration

[Anthony Joseph Messina <amessina@xxxxxxxxxxxx>]

On Saturday, November 9, 2019 1:49:04 PM CST Thomas Haller wrote:
> On Fri, 2019-11-08 at 20:30 -0600, Anthony Joseph Messina wrote:
> > Thank you for responding Ryan.  AFAIK, I don't have both systemd-
> > networkd and
> > NetworkManager "running" or enabled. In fact, I have had
> > NetworkManager
> > disabled on these systems for some time (back through F27, I
> > believe).  Post
> > upgrade (or fresh install) I ensure that NetworkManager is not re-
> > enabled, and
> > that systemd-networkd is enabled.
> > 
> > Unforuntately, trying to remove
> > NetworkManager completely seems like a heavy hammer based on the `dnf
> > remove`
> > output below.
> 
> Seems dnf wants to also unstall packages that were installed due to
> NetworkManager. For exapmle, "libndp" obvoiusly has no dependency on
> NetworkManager (but the other way around). You probable should use the
> right argument to dnf to not remove unrelated packages.
> 
> > Also, these identical systemd-networkd configurations do work on F30,
> > just not
> > on systems upgraded to F31.
> > 
> > The only recent change I notice in F31, is that NetworkManager is
> > initialized
> > during early boot even when the service is disabled and masked.
> 
> NM indeed may now run in early boot. That has no relation to whether
> you enable the systemd service ("enabling" a service in systemd anyway
> only means to hook it up accroding to the [Install] section, and that
> does not cover what runs in initrd).
> 
> I would suspect that NetworkManager sets the interface to disable ipv6
> address generation (e.g. `ip -d link` would report "addrgenmode none").
> It probably shouldn't do so, if there is not configuration for the
> device. This is probably a bug.

Thank you.  You are correct.  On the system(s) that systemd-networkd fails to set the link-local, the following is observed.  Link eno1, below.  Do you mean a bug in NetworkManager?  If so I'll check further in that direction.

$ ip -d link
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 promiscuity 0 minmtu 0 maxmtu 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether f4:4d:30:6f:60:21 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9000 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

I do not know what triggered this after a dnf systemd upgrade of these systems from F30->F31.  I've never customized dracut/grub params or configs on these systems.

> Another question is what causes NM to run in initrd in the first place.
> Usually that would be caused by setting "rd.neednet=1" on the kernel
> command line. But dracut may also artificially add such a command line,
> according to its configuration. You probably don't want to setup
> networking in initrd in the first place. That is, check your dracut
> configuration...
> 
> 
> best,
> Thomas
> 
> > This is the early boot NetworkManager output:
> > <info>  [1573262139.2398] NetworkManager (version 1.20.4-1.fc31) is
> > starting... (for the first time)
> > <info>  [1573262139.2399] Read config:
> > /etc/NetworkManager/NetworkManager.conf
> > <info>  [1573262139.2416] auth[0x55b3f3c8b4a0]: create auth-manager:
> > D-Bus
> > connection not available. Polkit is disabled and all requests are
> > authenticated.
> > <info>  [1573262139.2426] manager[0x55b3f3c94060]: monitoring kernel
> > firmware
> > directory '/lib/firmware'.
> > <info>  [1573262139.2427] hostname: hostname: hostnamed not used as
> > proxy
> > creation failed with: Could not connect: No such file or directory
> > <info>  [1573262139.2428] hostname: hostname changed from (none) to
> > "linux-
> > ws1.messinet.com"
> > <info>  [1573262139.2430] dns-mgr[0x55b3f3c8f210]: init:
> > dns=default,systemd-
> > resolved rc-manager=symlink
> > <info>  [1573262139.2447] Loaded device plugin: NMTeamFactory
> > (/usr/lib64/
> > NetworkManager/1.20.4-1.fc31/libnm-device-plugin-team.so)
> > <info>  [1573262139.2448] manager: rfkill: Wi-Fi enabled by radio
> > killswitch;
> > enabled by state file
> > <info>  [1573262139.2448] manager: rfkill: WWAN enabled by radio
> > killswitch;
> > enabled by state file
> > <info>  [1573262139.2448] manager: Networking is enabled by state
> > file
> > <info>  [1573262139.2448] dhcp-init: Using DHCP client 'internal'
> > <info>  [1573262139.2453] settings: Loaded settings plugin: ifcfg-rh
> > ("/usr/
> > lib64/NetworkManager/1.20.4-1.fc31/libnm-settings-plugin-ifcfg-
> > rh.so")
> > <info>  [1573262139.2454] settings: Loaded settings plugin: keyfile
> > (internal)
> > <info>  [1573262139.2459] device (lo): carrier: link connected
> > <info>  [1573262139.2460] manager: (lo): new Generic device
> > (/org/freedesktop/
> > NetworkManager/Devices/1)
> > <info>  [1573262139.2464] manager: (eno1): new Ethernet device (/org/
> > freedesktop/NetworkManager/Devices/2)
> > <info>  [1573262139.2466] device (eno1): state change: unmanaged ->
> > unavailable (reason 'managed', sys-iface-state: 'external')
> > <warn>  [1573262139.4343] sleep-monitor-sd: failed to acquire D-Bus
> > proxy:
> > Could not connect: No such file or directory
> > <warn>  [1573262139.4343] firewall: could not connect to system D-Bus
> > (Could
> > not connect: No such file or directory)
> > <warn>  [1573262139.4344] ifcfg-rh: dbus: couldn't initialize system
> > bus:
> > Could not connect: No such file or directory
> > 

<trim>

> > On Friday, November 8, 2019 8:14:54 PM CST Ryan Gonzalez wrote:
> > > Having two networking systems running at once can cause all sorts
> > > of
> > > problems, not sure if this is the issue here or why NM is still
> > > starting
> > > but you can try using 'systemctl mask' on it to completely prevent
> > > it from
> > > running.
> > > 
> > > On Fri, Nov 8, 2019, 7:37 PM Anthony Joseph Messina <
> > > amessina@xxxxxxxxxxxx>
> > > wrote: I apologize if this isn't the right place to post this
> > > request for
> > > assistance.  I've attempted the Fedora User's list with no luck and
> > > would
> > > prefer to ask before filing a bug.
> > > 
> > > After a successful "dnf systemd upgrade" F30->F31, I'm finding that
> > > a few of
> > > my machines which use systemd-networkd instead of NetworkManager
> > > are no
> > > longer autoconfiguring IPv6 addresses.  I also noticed that even
> > > though
> > > NetworkManager is disabled, it is initiated in early boot, which
> > > I'm not
> > > sure is related.
> > > 
> > > It appears as though the system isn't assigning the link-local
> > > address and
> > > therefore can't communicate via IPv6.  If anyone has any pointers
> > > on where
> > > to begin, I'd appreciate it.  Thanks.  -A
> > > 
> > > Both systems below use the following
> > > /etc/systemd/network/10-wired-dhcp.network:
> > > 
> > > [Match]
> > > Name=en*
> > > 
> > > [Network]
> > > DHCP=yes
> > > IPv6PrivacyExtensions=yes
> > > 
> > > 
> > > Both systems are running:
> > > kernel-5.3.8-300.fc31.x86_64
> > > systemd-243-4.gitef67743.fc31.x86_64
> > > NetworkManager-1.20.4-1.fc31.x86_64
> > > 
> > > 
> > > A system that IS working with systemd-networkd displays the
> > > following debug
> > > output:
> > > 
> > > eno1: New device has no master, continuing without
> > > eno1: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
> > > eno1: Link 2 added
> > > eno1: udev initialized link
> > > eno1: State changed: pending -> initialized
> > > eno1: Saved original MTU: 1500
> > > eno1: Remembering foreign address: fe80::f64d:30ff:fe6e:2cf5/64
> > > (valid
> > > forever) eno1: Gained IPv6LL
> > > eno1: Remembering route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc:
> > > n/a,
> > > scope: global, table: local, proto: boot, type: unicast eno1:
> > > Remembering
> > > route: dst: fe80::f64d:30ff:fe6e:2cf5/128, src: n/a, gw: n/a,
> > > prefsrc: n/a,
> > > scope: global, table: local, proto: kernel, type: local eno1:
> > > Remembering
> > > route: dst: fe80::/64, src: n/a, gw: n/a, prefsrc: n/a, scope:
> > > global,
> > > table: main, proto: kernel, type: unicast eno1: Remembering updated
> > > address: fe80::f64d:30ff:fe6e:2cf5/64 (valid forever) eno1:
> > > Updating
> > > remembered route: dst: fe80::f64d:30ff:fe6e:2cf5/128, src: n/a, gw:
> > > n/a,
> > > prefsrc: n/a, scope: global, table: local, proto: kernel, type:
> > > local eno1:
> > > Link state is up-to-date
> > > eno1: found matching network '/etc/systemd/network/10-wired-
> > > dhcp.network'
> > > Setting '/proc/sys/net/ipv6/conf/eno1/disable_ipv6' to '0'
> > > eno1: IPv6 successfully enabled
> > > Setting '/proc/sys/net/ipv6/conf/eno1/proxy_ndp' to '0'
> > > Setting '/proc/sys/net/ipv6/conf/eno1/use_tempaddr' to '2'
> > > Setting '/proc/sys/net/ipv6/conf/eno1/accept_ra' to '0'
> > > eno1: Started LLDP.
> > > eno1: Setting address genmode for link
> > > eno1: Acquiring DHCPv4 lease
> > > eno1: Discovering IPv6 routers
> > > eno1: State changed: initialized -> configuring
> > > eno1: Acquiring DHCPv6 lease on NDisc request
> > > 
> > > 
> > > Another system that IS NOT working displays the following debug
> > > output (note
> > > the missing Remembering foreign address and Gained IPv6LL lines):
> > > 
> > > eno1: New device has no master, continuing without
> > > eno1: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
> > > eno1: Link 2 added
> > > eno1: udev initialized link
> > > eno1: State changed: pending -> initialized
> > > eno1: Saved original MTU: 1500
> > > eno1: Remembering route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc:
> > > n/a,
> > > scope: global, table: local, proto: boot, type: unicast eno1: Link
> > > state is
> > > up-to-date
> > > eno1: found matching network '/etc/systemd/network/10-wired-
> > > dhcp.network'
> > > eno1: IPv6 successfully enabled
> > > eno1: Started LLDP.
> > > eno1: Setting address genmode for link
> > > eno1: Acquiring DHCPv4 lease
> > > eno1: State changed: initialized -> configuring



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel