From mstuff at read.org.nz Tue Jul 1 14:48:21 2025 From: mstuff at read.org.nz (Morgan Read) Date: Tue, 1 Jul 2025 15:48:21 +0100 Subject: NM, dnsmasq & systemd-resolved... Message-ID: <7c186af7-dcf0-4b32-8109-fb761f766ce1@read.org.nz> Hello NM List, I am running dnsmasq under NM. I have recently attempted a configuration of NM, dnsmasq and resolved to have them 'play nice' together because systemd-resolved is required (perhaps desired) by Tailscale. I have restricted dnsmasq to the local lan device (bridge0) with address 192.168.1.40. The upstream route to the Internet is on wan device (bond0) with address 192.168.9.2. I have systemd-resolved running in its primary linked mode: ``` [admin at server ~]$ ls -lh /etc/resolv.conf lrwxrwxrwx. 1 root root 37 Jun 23 21:38 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf ``` I believe (hope/ wish) I have done what is necessary to succeed. I may have succeeded, but the output of dnsmasq running under NM leads me to suspect otherwise: ``` CGroup: /system.slice/NetworkManager.service ??374497 /usr/sbin/NetworkManager --no-daemon ??374545 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/NetworkManager/dnsmasq.pid --listen-address=127.0.0.1 --cache-size=400 --clear-on-reload --conf-file=/dev/null --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d ``` The part of the reported dnsmasq config I take offence to is `--listen-address=127.0.0.1` and my question is, where on earth is this coming from? The output of: ``` find -L /etc/NetworkManager/ /etc/systemd/resolved.conf /etc/systemd/resolved.conf.d/ /etc/resolv.conf -type f -printf '---next-file->>>: %p\n\n' -exec cat {} \; -printf '\n' > /tmp/output.txt ``` Is attached. Are there any other files that I should included (and so, perhaps, a quick lead to an answer to my primary question)? Links to discussions relevant to this post, most recent first: https://issues.redhat.com/browse/RHEL-61202?focusedId=27455987&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27455987 https://forums.rockylinux.org/t/network-nightmare-nah-not-really/13244 Many thanks for your time, M -- Morgan Read Grande Bretagne -------------- next part -------------- ---next-file->>>: /etc/NetworkManager/conf.d/dhcp-client.conf ### Added by root 01.10.2023 [main] #dhcp=dhclient dhcp=internal ---next-file->>>: /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf [main] dns=dnsmasq ---next-file->>>: /etc/NetworkManager/conf.d/00-use-dnsmasq.conf # /etc/NetworkManager/conf.d/00-use-dnsmasq.conf # # This enabled the dnsmasq plugin. ### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ ### https://fedoramagazine.org/using-the-networkmanagers-dnsmasq-plugin/ ### See also https://access.redhat.com/solutions/2189401#nm-helper [main] dns=dnsmasq ---next-file->>>: /etc/NetworkManager/conf.d/rc-manager-symlink.conf ### symlink: If /etc/resolv.conf is instead a symlink, NetworkManager will leave it alone. Unless the symlink points to ### the internal file /run/NetworkManager/resolv.conf, in which case the symlink will be updated to emit an inotify notification. [main] rc-manager=symlink ### Additionally, send the connection DNS configuration to systemd-resolved. Defaults to "true". ### Note that this setting has no effect if the main dns plugin is already systemd-resolved. It is complementary to the dns ### setting to configure systemd-resolved alongside the main plugin. ### If systemd-resolved is enabled, either via this setting or the main DNS plugin, the connectivity check resolves the hostname ### per-device. systemd-resolved=true ---next-file->>>: /etc/NetworkManager/dnsmasq.d/02-DHCP-office-lan.conf # /etc/NetworkManager/dnsmasq.d/02-DHCP-office-lan.conf # This file sets up DHCP for the private local net domain office.lan ### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ # The domain the DHCP part of dnsmasq is responsible for: domain=office.lan,192.168.1.0/24,local # interfaces to listen on interface=bridge0 # general DHCP stuff (options, see RFC 2132) # 1: subnet masq # 3: default router # 6: DNS server # 12: hostname # 15: DNS domain (unneeded with option 'domain') # 28: broadcast address dhcp-authoritative dhcp-option=1,255.255.255.0 dhcp-option=3,192.168.1.40 dhcp-option=6,192.168.1.40 # Assign fixed IP addresses based on MAC address dhcp-host=B4:B5:2F:??:??:??,ILOCZJ2320B32,192.168.1.41,6h dhcp-host=DC:39:6F:??:??:??,fritzbox,192.168.1.30,6h dhcp-host=00:00:74:??:??:??,printer,192.168.1.120,6h dhcp-host=C2:0A:7A:??:??:??,mymachine,192.168.1.140,6h dhcp-host=B0:25:AA:??:??:??,mymachine,192.168.1.141,6h dhcp-host=F4:4D:AD:??:??:??,mymachine,192.168.1.142,6h dhcp-host=5C:E0:C5:??:??:??,myoldmachine,192.168.1.150,6h dhcp-host=60:B7:6E:??:??:??,myphone,192.168.1.160,6h dhcp-host=B0:72:BF:??:??:??,myphone-gs7,192.168.1.161,6h # Assign dynamically IP addresses to interface to listen on # Range for distributed addresses, tagged for further references dhcp-range=tag:enp2s0,10.10.10.150,10.10.10.200,24h dhcp-range=192.168.1.50,192.168.1.250,6h ---next-file->>>: /etc/NetworkManager/dnsmasq.d/01-DNS-office-lan.conf # /etc/NetworkManager/dnsmasq.d/01-DNS-office-lan.conf # This file sets up DNS for the private local net domain office.lan ### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ ### https://fedoramagazine.org/using-the-networkmanagers-dnsmasq-plugin/ ### Setup for working with `systemd-resolved` on interface `lo`. # This option forces dnsmasq to really bind only the interfaces it is listening on, otherwise also dnsmasq binds the wildcard addre> bind-interfaces # Do not listen on the specified interface. except-interface=lo # Listen on the given IP address. If no `interface` option is given, but `listen-address` is, dnsmasq will not automatically liste> listen-address=192.168.1.40 # Don't read /etc/resolv.conf. Get upstream servers only from the command line or the dnsmasq configuration file. no-resolv # Don't read the hostnames in /etc/hosts. no-hosts # File where to find the list of IP - hostname mapping addn-hosts=/etc/dnsmasq.hosts #addn-hosts=/etc/hosts ### Commented out for working with `systemd-resolved`. domain-needed bogus-priv # Automatically add to simple names in a hosts-file. expand-hosts # Interfaces to listen on #interface=lo ### Commented out for working with `systemd-resolved`. interface=bridge0 # In case of a bridge don't use the attached server virtual ethernet interface # The below defines a Wildcard DNS Entry. #address=/.localnet/10.10.10.zzz # Tells dnsmasq that a domain is local # It may answer queries from /etc/hosts or DHCP but should never forward queries # `local` is a synonym for `server` to make configuration files clearer local=/office.lan/192.168.1.40 ### A declaration with no interfaces or address simply specifies the primary external nameserver. ### https://discussion.fedoraproject.org/t/dnsmasq-times-out-querying-upstream-dns-for-local-lookup/130870/52 #auth-server=office.lan ### Commented out following close reading of `man` entry - it appears to require a 'globally accessible IP address' and an 'external DNS server', see under 'AUTHORITATIVE CONFIGURATION' # Specifies DNS domains for the DHCP server. domain=office.lan # Upstream public net DNS server (max.three) server=1.1.1.1 server=1.0.0.1 # Don't poll /etc/resolv.conf for changes no-poll # For debugging purposes, log each DNS query as it passes through dnsmasq. log-queries # As per @vgaetera suggestion here https://discussion.fedoraproject.org/t/dnsmasq-times-out-querying-upstream-dns-for-local-lookup/130870/25 #filter-AAAA ---next-file->>>: /etc/NetworkManager/dnsmasq.d/crc.conf server=/apps-crc.testing/192.168.130.11 server=/crc.testing/192.168.130.11 ---next-file->>>: /etc/NetworkManager/dnsmasq.d/libvirt-office-lan.conf ### References: ### https://liquidat.wordpress.com/2017/03/03/howto-automated-dns-resolution-for-kvmlibvirt-guests-with-a-local-domain/ ### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ # /etc/NetworkManager/dnsmasq.d/libvirt-office-lan.conf # This file directs dnsmasq to forward any request to resolve # names under the .libvirt.office.lan domain to 192.168.122.1, the # local libvirt DNS server default address. server=/libvirt.office.lan/192.168.122.1 ---next-file->>>: /etc/NetworkManager/system-connections/enp3s4f1.nmconnection [connection] id=enp3s4f1 uuid=6a20f88c-0b92-4a21-97ee-2557efe59101 type=ethernet controller=bond0 interface-name=enp3s4f1 port-type=bond timestamp=1726425072 zone=public [ethernet] ---next-file->>>: /etc/NetworkManager/system-connections/enp3s4f0.nmconnection [connection] id=enp3s4f0 uuid=c63886e1-9cc7-3542-afba-6d52927be35f type=ethernet autoconnect-priority=-999 controller=bond0 interface-name=enp3s4f0 port-type=bond timestamp=1726425072 zone=public [ethernet] ---next-file->>>: /etc/NetworkManager/system-connections/bond0.nmconnection [connection] id=bond0-wan uuid=46d68e2e-e9bf-4f63-8fef-2b05441ec73f type=bond autoconnect-ports=1 interface-name=bond0 timestamp=1750627295 [ethernet] cloned-mac-address=B4:B5:2F:5B:17:8E [bond] arp_interval=100 arp_ip_target=192.168.9.1 downdelay=0 miimon=100 mode=balance-rr updelay=0 [ipv4] address1=192.168.9.2/24 dns=192.168.1.40;1.1.1.1;1.0.0.1; gateway=192.168.9.1 method=manual [ipv6] addr-gen-mode=default method=auto [proxy] ---next-file->>>: /etc/NetworkManager/system-connections/bridge0-port0.nmconnection [connection] id=bridge0-port0 uuid=ad5f615e-7398-4740-a852-492b04a7b9be type=ethernet controller=bridge0 interface-name=ens6f0 port-type=bridge timestamp=1727007828 zone=internal [ethernet] [bridge-port] ---next-file->>>: /etc/NetworkManager/system-connections/bridge0-port1.nmconnection [connection] id=bridge0-port1 uuid=04f25206-74d9-493a-a564-705fea93c6e6 type=ethernet controller=bridge0 interface-name=ens6f1 port-type=bridge timestamp=1727007828 zone=internal [ethernet] [bridge-port] ---next-file->>>: /etc/NetworkManager/system-connections/bridge0-port2.nmconnection [connection] id=bridge0-port2 uuid=e2614e1b-7725-42eb-b127-026e253f9657 type=ethernet controller=bridge0 interface-name=ens6f2 port-type=bridge timestamp=1727007828 zone=internal [ethernet] [bridge-port] ---next-file->>>: /etc/NetworkManager/system-connections/bridge0-port3.nmconnection [connection] id=bridge0-port3 uuid=41e40344-986b-4c16-baf7-6d023ef03045 type=ethernet controller=bridge0 interface-name=ens6f3 port-type=bridge timestamp=1727007828 zone=internal [ethernet] [bridge-port] ---next-file->>>: /etc/NetworkManager/system-connections/bridge0.nmconnection [connection] id=bridge0-lan uuid=9b722122-7aa4-43bf-81b7-115cc6df3c6d type=bridge autoconnect-ports=1 interface-name=bridge0 timestamp=1750621893 zone=internal [ethernet] [bridge] [ipv4] address1=192.168.1.40/24 method=manual [ipv6] addr-gen-mode=default method=auto [proxy] ---next-file->>>: /etc/NetworkManager/NetworkManager.conf # Configuration file for NetworkManager. # # See "man 5 NetworkManager.conf" for details. # # The directories /usr/lib/NetworkManager/conf.d/ and /run/NetworkManager/conf.d/ # can contain additional .conf snippets installed by packages. These files are # read before NetworkManager.conf and have thus lowest priority. # The directory /etc/NetworkManager/conf.d/ can contain additional .conf # snippets. Those snippets are merged last and overwrite the settings from this main # file. # # The files within one conf.d/ directory are read in asciibetical order. # # You can prevent loading a file /usr/lib/NetworkManager/conf.d/NAME.conf # by having a file NAME.conf in either /run/NetworkManager/conf.d/ or /etc/NetworkManager/conf.d/. # Likewise, snippets from /run can be prevented from loading by placing # a file with the same name in /etc/NetworkManager/conf.d/. # # If two files define the same key, the one that is read afterwards will overwrite # the previous one. [main] #plugins=keyfile,ifcfg-rh [logging] # When debugging NetworkManager, enabling debug logging is of great help. # # Logfiles contain no passwords and little sensitive information. But please # check before posting the file online. You can also personally hand over the # logfile to a NM developer to treat it confidential. Meet us on #nm on Libera.Chat. # # You can also change the log-level at runtime via # $ nmcli general logging level TRACE domains ALL # However, usually it's cleaner to enable debug logging # in the configuration and restart NetworkManager so that # debug logging is enabled from the start. # # You will find the logfiles in syslog, for example via # $ journalctl -u NetworkManager # # Please post full logfiles for bug reports without pre-filtering or truncation. # Also, for debugging the entire `journalctl` output can be interesting. Don't # limit unnecessarily with `journalctl -u`. Exceptions are if you are worried # about private data. Check before posting logfiles! # # Note that debug logging of NetworkManager can be quite verbose. Some messages # might be rate-limited by the logging daemon (see RateLimitIntervalSec, RateLimitBurst # in man journald.conf). Please disable rate-limiting before collecting debug logs! # #level=TRACE #domains=ALL ---next-file->>>: /etc/systemd/resolved.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it under the # terms of the GNU Lesser General Public License as published by the Free # Software Foundation; either version 2.1 of the License, or (at your option) # any later version. # # Entries in this file show the compile time defaults. Local configuration # should be created by either modifying this file, or by creating "drop-ins" in # the resolved.conf.d/ subdirectory. The latter is generally recommended. # Defaults can be restored by simply deleting this file and all drop-ins. # # Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config. # # See resolved.conf(5) for details. [Resolve] # Some examples of DNS servers which may be used for DNS= and FallbackDNS=: # Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com # Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google # Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net #DNS= #FallbackDNS= #Domains= #DNSSEC=no #DNSOverTLS=no #MulticastDNS=no #LLMNR=resolve #Cache=yes #CacheFromLocalhost=no #DNSStubListener=yes #DNSStubListenerExtra= #ReadEtcHosts=yes #ResolveUnicastSingleLabel=no ---next-file->>>: /etc/resolv.conf # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 trust-ad search . -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Tue Jul 1 15:09:58 2025 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 1 Jul 2025 17:09:58 +0200 Subject: NM, dnsmasq & systemd-resolved... In-Reply-To: <7c186af7-dcf0-4b32-8109-fb761f766ce1@read.org.nz> References: <7c186af7-dcf0-4b32-8109-fb761f766ce1@read.org.nz> Message-ID: <20250701170958.7f4a6a5a@zbook> On 01.07.2025 15:48 Morgan Read wrote: > The part of the reported dnsmasq config I take offence to is > `--listen-address=127.0.0.1` and my question is, where on earth is > this coming from? Maybe NM starts dnsmasq. Does your config look like that? m at zbook:~$ grep -i dns /etc/NetworkManager/NetworkManager.conf dns=dnsmasq m at zbook:~$ -- kind regards Marco Send spam to abfall1751377701 at stinkedores.dorfdsl.de From mstuff at read.org.nz Tue Jul 1 20:08:43 2025 From: mstuff at read.org.nz (Morgan Read) Date: Tue, 1 Jul 2025 21:08:43 +0100 Subject: NM, dnsmasq & systemd-resolved... In-Reply-To: <7c186af7-dcf0-4b32-8109-fb761f766ce1@read.org.nz> References: <7c186af7-dcf0-4b32-8109-fb761f766ce1@read.org.nz> Message-ID: On 01/07/2025 3:48 pm, Morgan Read wrote: >> The part of the reported dnsmasq config I take offence to is >> `--listen-address=127.0.0.1` and my question is, where on earth is >> this coming from? > > Maybe NM starts dnsmasq. Absolutely, with my original post I include: > ---next-file->>>: /etc/NetworkManager/conf.d/00-use-dnsmasq.conf > > # /etc/NetworkManager/conf.d/00-use-dnsmasq.conf # > # This enabled the dnsmasq plugin. > ### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ > ### https://fedoramagazine.org/using-the-networkmanagers-dnsmasq-plugin/ > ### See also https://access.redhat.com/solutions/2189401#nm-helper > > [main] > dns=dnsmasq But, there's no `--listen-address=127.0.0.1` anywhere in there. Many thanks M -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christian.schaubschlaeger at gmx.at Thu Jul 10 07:31:58 2025 From: christian.schaubschlaeger at gmx.at (=?UTF-8?Q?Christian_Schaubschl=C3=A4ger?=) Date: Thu, 10 Jul 2025 09:31:58 +0200 Subject: Problem with acd on upgrade to 1.52 Message-ID: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Hi list, I just upgraded from NetworkManager-1.48 to 1.52.1. Unfortunately this had the effect, that my wired interface, which is configured for using dhcp, does not get an IP address any more. From the networkmanager logs I can see that a dhcp request is sent and successfully answered, but then networkmanager gets stuck with this: Jul 10 09:08:34 lfs-sn NetworkManager[1043]: [1752138514.1285] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) Jul 10 09:08:35 lfs-sn NetworkManager[1043]: [1752138515.6305] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) Has anyone any clue what's wrong here? Thanks and best regarads, Christian From bgalvani at redhat.com Thu Jul 10 08:02:39 2025 From: bgalvani at redhat.com (Beniamino Galvani) Date: Thu, 10 Jul 2025 10:02:39 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: On Thu, Jul 10, 2025 at 09:31:58AM +0200, Christian Schaubschl?ger wrote: > Hi list, > > I just upgraded from NetworkManager-1.48 to 1.52.1. Unfortunately this had the effect, that my wired interface, which is configured for using dhcp, does not get an IP address any more. From the networkmanager logs I can see that a dhcp request is sent and successfully answered, but then networkmanager gets stuck with this: > > Jul 10 09:08:34 lfs-sn NetworkManager[1043]: [1752138514.1285] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > Jul 10 09:08:35 lfs-sn NetworkManager[1043]: [1752138515.6305] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > > Has anyone any clue what's wrong here? Can you share the full activation log at trace level? Thanks, Beniamino -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ihuguet at redhat.com Thu Jul 10 08:08:19 2025 From: ihuguet at redhat.com (=?UTF-8?B?w43DsWlnbyBIdWd1ZXQ=?=) Date: Thu, 10 Jul 2025 10:08:19 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: If it's stuck there, the failure should be at function _l3_acd_nacd_instance_ensure. Can you check if the interface has the NOARP flag with `ip link show `? On Thu, Jul 10, 2025 at 9:37?AM Christian Schaubschl?ger wrote: > > Hi list, > > I just upgraded from NetworkManager-1.48 to 1.52.1. Unfortunately this had the effect, that my wired interface, which is configured for using dhcp, does not get an IP address any more. From the networkmanager logs I can see that a dhcp request is sent and successfully answered, but then networkmanager gets stuck with this: > > Jul 10 09:08:34 lfs-sn NetworkManager[1043]: [1752138514.1285] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > Jul 10 09:08:35 lfs-sn NetworkManager[1043]: [1752138515.6305] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > > Has anyone any clue what's wrong here? > > Thanks and best regarads, > Christian > -- ??igo Huguet From christian.schaubschlaeger at gmx.at Thu Jul 10 10:55:23 2025 From: christian.schaubschlaeger at gmx.at (=?UTF-8?Q?Christian_Schaubschl=C3=A4ger?=) Date: Thu, 10 Jul 2025 12:55:23 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: Hi, thanks for the quick response earlier. I think my reply with the full log attached got blocked...? so here's another try: http://datenaustausch.s3.eu-west-1.amazonaws.com/Logs/daemon-list.log Meanwhile I found out, that the error message below is also there when I use NM-1.48... so the problem might be unrelated to that particular error message... But maybe you can find a hint in the logfile. And another thing: I get the same problem when i configure NM to use dhcpcd instead of the internal dhcp client. And I also checked the NOARP flag: it's not set on the network interface. Interestingly, when I set it via a script in /etc/NetworkManger/dispatcher.d/, then the network setup succeeds! Only DNS does not work when NOARP is set...? Thanks and best regards, Christian Am 10.07.25 um 10:02 schrieb Beniamino Galvani: > On Thu, Jul 10, 2025 at 09:31:58AM +0200, Christian Schaubschl?ger wrote: >> Hi list, >> >> I just upgraded from NetworkManager-1.48 to 1.52.1. Unfortunately this had the effect, that my wired interface, which is configured for using dhcp, does not get an IP address any more. From the networkmanager logs I can see that a dhcp request is sent and successfully answered, but then networkmanager gets stuck with this: >> >> Jul 10 09:08:34 lfs-sn NetworkManager[1043]: [1752138514.1285] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) >> Jul 10 09:08:35 lfs-sn NetworkManager[1043]: [1752138515.6305] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) >> >> Has anyone any clue what's wrong here? > Can you share the full activation log at trace level? > > Thanks, > Beniamino From ihuguet at redhat.com Fri Jul 11 05:22:04 2025 From: ihuguet at redhat.com (=?UTF-8?B?w43DsWlnbyBIdWd1ZXQ=?=) Date: Fri, 11 Jul 2025 07:22:04 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: Jul 10 09:09:00 lfs-sn NetworkManager[1043]: [1752138540.3382] caught SIGTERM, shutting down normally. NetworkManager is receiving an external signal to shut down. On Thu, Jul 10, 2025 at 12:55?PM Christian Schaubschl?ger wrote: > > Hi, > > thanks for the quick response earlier. I think my reply with the full log attached got blocked... > so here's another try: > > http://datenaustausch.s3.eu-west-1.amazonaws.com/Logs/daemon-list.log > > Meanwhile I found out, that the error message below is also there when I use NM-1.48... so the problem might be unrelated to that particular error message... > But maybe you can find a hint in the logfile. > > And another thing: I get the same problem when i configure NM to use dhcpcd instead of the internal dhcp client. > > And I also checked the NOARP flag: it's not set on the network interface. Interestingly, when I set it via a script in /etc/NetworkManger/dispatcher.d/, then the network setup succeeds! Only DNS does not work when NOARP is set... > > Thanks and best regards, > Christian > > > Am 10.07.25 um 10:02 schrieb Beniamino Galvani: > > On Thu, Jul 10, 2025 at 09:31:58AM +0200, Christian Schaubschl?ger wrote: > >> Hi list, > >> > >> I just upgraded from NetworkManager-1.48 to 1.52.1. Unfortunately this had the effect, that my wired interface, which is configured for using dhcp, does not get an IP address any more. From the networkmanager logs I can see that a dhcp request is sent and successfully answered, but then networkmanager gets stuck with this: > >> > >> Jul 10 09:08:34 lfs-sn NetworkManager[1043]: [1752138514.1285] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > >> Jul 10 09:08:35 lfs-sn NetworkManager[1043]: [1752138515.6305] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > >> > >> Has anyone any clue what's wrong here? > > Can you share the full activation log at trace level? > > > > Thanks, > > Beniamino > -- ??igo Huguet From bgalvani at redhat.com Fri Jul 11 07:42:56 2025 From: bgalvani at redhat.com (Beniamino Galvani) Date: Fri, 11 Jul 2025 09:42:56 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: On Thu, Jul 10, 2025 at 12:55:23PM +0200, Christian Schaubschl?ger wrote: > Hi, > > thanks for the quick response earlier. I think my reply with the full log attached got blocked...? > so here's another try: > > http://datenaustausch.s3.eu-west-1.amazonaws.com/Logs/daemon-list.log > > Meanwhile I found out, that the error message below is also there when I use NM-1.48... so the problem might be unrelated to that particular error message... > But maybe you can find a hint in the logfile. > > And another thing: I get the same problem when i configure NM to use dhcpcd instead of the internal dhcp client. > > And I also checked the NOARP flag: it's not set on the network interface. Interestingly, when I set it via a script in /etc/NetworkManger/dispatcher.d/, then the network setup succeeds! Only DNS does not work when NOARP is set...? Hi, I see two problems in the log. First, the creation of the ACD probe fails. This shouldn't happen. Perhaps are you building NM with eBPF support? If so, it's possible that the process doesn't have the necessary capabilities to use the eBPF program. Anyway, the logging needs to be improved to indicate the exact cause for the failure. Second, there is a mechanism that retries the ACD probe creation and gives up after some seconds. Apparently this is not working and NM never recovers, as the log shows: Jul 10 09:08:23 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) Jul 10 09:08:25 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) Jul 10 09:08:29 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) ... Jul 10 09:08:34 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) I will investigate this and prepare a patch. In the meantime, you can try disabling ACD for the connection: nmcli connection modify "Wired connection 1" ipv4.dad-timeout 0 Beniamino > Thanks and best regards, > Christian > > > Am 10.07.25 um 10:02 schrieb Beniamino Galvani: > > On Thu, Jul 10, 2025 at 09:31:58AM +0200, Christian Schaubschl?ger wrote: > >> Hi list, > >> > >> I just upgraded from NetworkManager-1.48 to 1.52.1. Unfortunately this had the effect, that my wired interface, which is configured for using dhcp, does not get an IP address any more. From the networkmanager logs I can see that a dhcp request is sent and successfully answered, but then networkmanager gets stuck with this: > >> > >> Jul 10 09:08:34 lfs-sn NetworkManager[1043]: [1752138514.1285] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > >> Jul 10 09:08:35 lfs-sn NetworkManager[1043]: [1752138515.6305] l3cfg[751860e9573ab19e,ifindex=4]: acd[192.168.0.54, probing]: probing currently? stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > >> > >> Has anyone any clue what's wrong here? > > Can you share the full activation log at trace level? > > > > Thanks, > > Beniamino > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From christian.schaubschlaeger at gmx.at Fri Jul 11 08:11:09 2025 From: christian.schaubschlaeger at gmx.at (=?UTF-8?Q?Christian_Schaubschl=C3=A4ger?=) Date: Fri, 11 Jul 2025 10:11:09 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: Hi, thanks for the analysis! > First, the creation of the ACD probe fails. This shouldn't > happen. Perhaps are you building NM with eBPF support? If so, it's > possible that the process doesn't have the necessary capabilities to > use the eBPF program. Anyway, the logging needs to be improved to > indicate the exact cause for the failure. Yes, I did compile it with eBPF support (though not entirely intentional ;-) And I just checked my kernel: I do not have CONFIG_BPF_SYSCALL enabled. Maybe that's the problem? However, I compiled 1.48 also with eBPF support, and I don't see the problem there... > Second, there is a mechanism that retries the ACD probe creation and > gives up after some seconds. Apparently this is not working and NM > never recovers, as the log shows: > > Jul 10 09:08:23 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > Jul 10 09:08:25 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > Jul 10 09:08:29 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > ... > Jul 10 09:08:34 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) When NM is in the above state and I do ip link set dev eth0 arp off it immediately resumes and the client gets an ip address: http://datenaustausch.s3.eu-west-1.amazonaws.com/Logs/daemon-noarp-resume.txt (logs are from today from a different subnet). > I will investigate this and prepare a patch. In the meantime, you can > try disabling ACD for the connection: > > nmcli connection modify "Wired connection 1" ipv4.dad-timeout 0 Can I disable ACD in general via configuration? Thanks, Christian From bgalvani at redhat.com Fri Jul 11 09:00:34 2025 From: bgalvani at redhat.com (Beniamino Galvani) Date: Fri, 11 Jul 2025 11:00:34 +0200 Subject: Problem with acd on upgrade to 1.52 In-Reply-To: References: <63a02e88-b1dd-4ff3-b99d-e557de389f1e@gmx.at> Message-ID: On Fri, Jul 11, 2025 at 10:11:09AM +0200, Christian Schaubschl?ger wrote: > Hi, > > thanks for the analysis! > > > First, the creation of the ACD probe fails. This shouldn't > > happen. Perhaps are you building NM with eBPF support? If so, it's > > possible that the process doesn't have the necessary capabilities to > > use the eBPF program. Anyway, the logging needs to be improved to > > indicate the exact cause for the failure. > > Yes, I did compile it with eBPF support (though not entirely intentional ;-) > And I just checked my kernel: I do not have CONFIG_BPF_SYSCALL enabled. Maybe that's the problem? > > However, I compiled 1.48 also with eBPF support, and I don't see the problem there... I don't know, maybe the timeout mechanism changed. > > Second, there is a mechanism that retries the ACD probe creation and > > gives up after some seconds. Apparently this is not working and NM > > never recovers, as the log shows: > > > > Jul 10 09:08:23 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > > Jul 10 09:08:25 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > > Jul 10 09:08:29 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > > ... > > Jul 10 09:08:34 acd[192.168.0.54, probing]: probing currently stillnot possible (timeout 200 msec; failure to create nacd instance, retry probing on timeout) > > When NM is in the above state and I do > > ip link set dev eth0 arp off > > it immediately resumes and the client gets an ip address: > > http://datenaustausch.s3.eu-west-1.amazonaws.com/Logs/daemon-noarp-resume.txt > > (logs are from today from a different subnet). Yes, if you disable ARP, the probe creation gets skipped. But ARP is necessary to contact other hosts, I guess ;) > > I will investigate this and prepare a patch. In the meantime, you can > > try disabling ACD for the connection: > > > > nmcli connection modify "Wired connection 1" ipv4.dad-timeout 0 > Can I disable ACD in general via configuration? cat << EOF > /etc/NetworkManager/conf.d/20-ipv4-dad.conf [connection-dad-default] ipv4.dad-timeout=0 EOF Beniamino -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: