-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Out of the blue, I get this in the warning log: <3.4> 2023-05-08T04:18:44.183546+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-08T04:18:49.645319+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-08T04:21:01.096723+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-08T04:21:09.760416+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-08T04:21:21.241287+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-08T04:21:29.788952+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface It repeats and repeats. In the messages log, there is more stuff: <3.6> 2023-05-08T04:21:09.760027+02:00 Telcontar avahi-daemon 1264 - - Files changed, reloading. <3.6> 2023-05-08T04:21:09.760195+02:00 Telcontar dnsmasq 23788 - - reading /etc/resolv.conf <3.6> 2023-05-08T04:21:09.760246+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain zen.spamhaus.org <3.6> 2023-05-08T04:21:09.760271+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain valinor <3.6> 2023-05-08T04:21:09.760296+02:00 Telcontar avahi-daemon 1264 - - No service file found in /etc/avahi/services. <3.6> 2023-05-08T04:21:09.760316+02:00 Telcontar dnsmasq 23788 - - using nameserver 80.58.61.250#53 <3.6> 2023-05-08T04:21:09.760337+02:00 Telcontar dnsmasq 23788 - - using nameserver 80.58.61.254#53 <3.6> 2023-05-08T04:21:09.760359+02:00 Telcontar dnsmasq 23788 - - using nameserver 1.1.1.1#53 <3.6> 2023-05-08T04:21:09.760377+02:00 Telcontar dnsmasq 23788 - - using nameserver 1.0.0.1#53 <3.6> 2023-05-08T04:21:09.760395+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain scar.opensuse.org <3.4> 2023-05-08T04:21:09.760416+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.6> 2023-05-08T04:21:09.760442+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 <3.6> 2023-05-08T04:21:09.760461+02:00 Telcontar dnsmasq 23788 - - using nameserver 2a02:9000::aaaa#53 <3.6> 2023-05-08T04:21:09.760482+02:00 Telcontar dnsmasq 23788 - - using only locally-known addresses for valinor <3.6> 2023-05-08T04:21:21.240605+02:00 Telcontar avahi-daemon 1264 - - Files changed, reloading. <3.6> 2023-05-08T04:21:21.240870+02:00 Telcontar dnsmasq 23788 - - reading /etc/resolv.conf <3.6> 2023-05-08T04:21:21.240956+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain zen.spamhaus.org <3.6> 2023-05-08T04:21:21.241003+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain valinor <3.6> 2023-05-08T04:21:21.241045+02:00 Telcontar dnsmasq 23788 - - using nameserver 80.58.61.250#53 <3.6> 2023-05-08T04:21:21.241086+02:00 Telcontar avahi-daemon 1264 - - No service file found in /etc/avahi/services. <3.6> 2023-05-08T04:21:21.241129+02:00 Telcontar dnsmasq 23788 - - using nameserver 80.58.61.254#53 <3.6> 2023-05-08T04:21:21.241170+02:00 Telcontar dnsmasq 23788 - - using nameserver 1.1.1.1#53 <3.6> 2023-05-08T04:21:21.241208+02:00 Telcontar dnsmasq 23788 - - using nameserver 1.0.0.1#53 <3.6> 2023-05-08T04:21:21.241246+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain scar.opensuse.org <3.4> 2023-05-08T04:21:21.241287+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.6> 2023-05-08T04:21:21.241333+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 <3.6> 2023-05-08T04:21:21.241369+02:00 Telcontar dnsmasq 23788 - - using only locally-known addresses for valinor <10.6> 2023-05-08T04:21:22.441402+02:00 Telcontar auth - - - gkr-pam: stashed password to try later in open session <3.6> 2023-05-08T04:21:24.021009+02:00 Telcontar dbus-daemon 6408 - - [session uid=1000 pid=6408] Activating via systemd: service name='org.freedesktop.Tracker3.Miner.Extract' unit='tracker-extract-3.service' requested by ':1.79' (uid=1000 pid=8713 comm="/usr/lib/tracker-miner-fs-3 ") <3.6> 2023-05-08T04:21:24.157150+02:00 Telcontar dbus-daemon 6408 - - [session uid=1000 pid=6408] Successfully activated service 'org.freedesktop.Tracker3.Miner.Extract' <3.6> 2023-05-08T04:21:27.905271+02:00 Telcontar dbus-daemon 6408 - - [session uid=1000 pid=6408] Activating service name='org.freedesktop.thumbnails.Thumbnailer1' requested by ':1.31' (uid=1000 pid=6665 comm="Thunar --sm-client-id 295296eba-ae66-485a-b5d5-5eb") <3.6> 2023-05-08T04:21:28.023852+02:00 Telcontar dbus-daemon 6408 - - [session uid=1000 pid=6408] Successfully activated service 'org.freedesktop.thumbnails.Thumbnailer1' <3.6> 2023-05-08T04:21:29.788388+02:00 Telcontar avahi-daemon 1264 - - Files changed, reloading. <3.6> 2023-05-08T04:21:29.788690+02:00 Telcontar dnsmasq 23788 - - reading /etc/resolv.conf <3.6> 2023-05-08T04:21:29.788741+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain zen.spamhaus.org <3.6> 2023-05-08T04:21:29.788769+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain valinor <3.6> 2023-05-08T04:21:29.788797+02:00 Telcontar dnsmasq 23788 - - using nameserver 80.58.61.250#53 <3.6> 2023-05-08T04:21:29.788824+02:00 Telcontar avahi-daemon 1264 - - No service file found in /etc/avahi/services. <3.6> 2023-05-08T04:21:29.788847+02:00 Telcontar dnsmasq 23788 - - using nameserver 80.58.61.254#53 <3.6> 2023-05-08T04:21:29.788874+02:00 Telcontar dnsmasq 23788 - - using nameserver 1.1.1.1#53 <3.6> 2023-05-08T04:21:29.788902+02:00 Telcontar dnsmasq 23788 - - using nameserver 1.0.0.1#53 <3.6> 2023-05-08T04:21:29.788926+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 for domain scar.opensuse.org <3.4> 2023-05-08T04:21:29.788952+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.6> 2023-05-08T04:21:29.788981+02:00 Telcontar dnsmasq 23788 - - using nameserver 192.168.1.16#53 <3.6> 2023-05-08T04:21:29.789006+02:00 Telcontar dnsmasq 23788 - - using nameserver 2a02:9000::aaaa#53 <3.6> 2023-05-08T04:21:29.789031+02:00 Telcontar dnsmasq 23788 - - using only locally-known addresses for valinor Why is this reloading and spamming the logs hapening, out of the blue? I'm certainly not changing /etc/resolv.conf. But something is: Telcontar:~ # l /etc/resolv.conf lrwxrwxrwx 1 root root 30 Nov 29 20:24 /etc/resolv.conf -> /var/run/netconfig/resolv.conf Telcontar:~ # l /var/run/netconfig/resolv.conf - -rw-r--r-- 1 root root 688 May 8 04:21 /var/run/netconfig/resolv.conf Telcontar:~ # date Mon May 8 04:24:55 CEST 2023 Telcontar:~ # Telcontar:~ # l /var/run/netconfig/resolv.conf - -rw-r--r-- 1 root root 661 May 8 04:26 /var/run/netconfig/resolv.conf Telcontar:~ # date Mon May 8 04:26:23 CEST 2023 Telcontar:~ # Ideas? - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZFheShwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVBQYAnAyQiQ18nCU9Hi1JPEXv wjD9V4uYAJ9Ooq69yrQkKkFwGf2AJp6JTbLGfw== =z6MC -----END PGP SIGNATURE-----
On 08.05.2023 05:28, Carlos E. R. wrote:
I'm certainly not changing /etc/resolv.conf. But something is:
You do not even say what you are using (wicked, NM, systemd-networkd or something entirely different) and expect someone guess what happens? Setup audit rules to monitor exec of netconfig and see what program invokes it.
On 2023-05-08 06:24, Andrei Borzenkov wrote:
On 08.05.2023 05:28, Carlos E. R. wrote:
I'm certainly not changing /etc/resolv.conf. But something is:
You do not even say what you are using (wicked, NM, systemd-networkd or something entirely different) and expect someone guess what happens?
Well, it was 4 AM, I was tired, and I hoped for ideas to be told what to look at. I was not going to think myself at that hour, too tired. I happened to look at it because the machine had failed to hibernate hours before when ordered. And I thought it was the same machine I had asked about dnsmasq recently, so the details would be remembered, but it isn't. Ok, so you want that info, just ask :-) No, this is Telcontar. Fixed configuration, desktop machine, so wicked and dnsmasq. Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ # That IPv6 address I do not want there, it should be inside dnsmasq. Now that I am awake, I will review what I did in the other thread on Laicolasse, when tea makes effect.
Setup audit rules to monitor exec of netconfig and see what program invokes it.
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
And I thought it was the same machine I had asked about dnsmasq recently, so the details would be remembered, but it isn't.
It's probably a little too much to expect us to remember the config of your machines :-)
Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ #
That IPv6 address I do not want there, it should be inside dnsmasq.
I guess you want nobody to touch your resolv.conf, but your ipv6 config still updates it. Isn't this one of the NETCONFIG* options in /etc/sysconfig/network/config ? -- Per Jessen, Zürich (19.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 11:20, Per Jessen wrote:
Carlos E. R. wrote:
And I thought it was the same machine I had asked about dnsmasq recently, so the details would be remembered, but it isn't.
It's probably a little too much to expect us to remember the config of your machines :-)
Hey, it was 4:30 AM. I wasn't thinking much.
Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ #
That IPv6 address I do not want there, it should be inside dnsmasq.
I guess you want nobody to touch your resolv.conf, but your ipv6 config still updates it. Isn't this one of the NETCONFIG* options in /etc/sysconfig/network/config ?
cer@Telcontar:~> grep NETCONFIG /etc/sysconfig/network/config NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime" NETCONFIG_DNS_POLICY='auto' NETCONFIG_DNS_FORWARDER='resolver' NETCONFIG_DNS_STATIC_SEARCHLIST='valinor' NETCONFIG_DNS_STATIC_SERVERS='127.0.0.1 192.168.1.16' NETCONFIG_NTP_POLICY="auto" NETCONFIG_NTP_STATIC_SERVERS="" NETCONFIG_NIS_POLICY='' NETCONFIG_NIS_SETDOMAINNAME='yes' # the NETCONFIG_NIS_STATIC_DOMAIN and NETCONFIG_NIS_STATIC_SERVERS # variables, e.g.: NETCONFIG_NIS_STATIC_DOMAIN_1="second". NETCONFIG_NIS_STATIC_DOMAIN='' NETCONFIG_NIS_STATIC_SERVERS='' NETCONFIG_DNS_FORWARDER_FALLBACK="yes" NETCONFIG_DNS_RANKING="auto" NETCONFIG_DNS_RESOLVER_OPTIONS="" NETCONFIG_DNS_RESOLVER_SORTLIST="" NETCONFIG_VERBOSE="no" NETCONFIG_FORCE_REPLACE="no" In Laicolasse (the machine in the other thread), I have: cer@Beta:~> grep NETCONFIG /Other/etc/sysconfig/network/config NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime" NETCONFIG_VERBOSE="no" NETCONFIG_FORCE_REPLACE="no" NETCONFIG_DNS_POLICY="STATIC" #NETCONFIG_DNS_POLICY="" #NETCONFIG_DNS_POLICY="auto" NETCONFIG_DNS_FORWARDER="dnsmasq" NETCONFIG_DNS_FORWARDER_FALLBACK="yes" NETCONFIG_DNS_STATIC_SEARCHLIST="valinor" # When the NETCONFIG_DNS_FORWARDER variable is set to "resolver", NETCONFIG_DNS_STATIC_SERVERS="127.0.0.1" NETCONFIG_DNS_RANKING="auto" NETCONFIG_DNS_RESOLVER_OPTIONS="" NETCONFIG_DNS_RESOLVER_SORTLIST="" NETCONFIG_NTP_POLICY="auto" NETCONFIG_NTP_STATIC_SERVERS="" NETCONFIG_NIS_POLICY="auto" NETCONFIG_NIS_SETDOMAINNAME="yes" # the NETCONFIG_NIS_STATIC_DOMAIN and NETCONFIG_NIS_STATIC_SERVERS # variables, e.g.: NETCONFIG_NIS_STATIC_DOMAIN_1="second". NETCONFIG_NIS_STATIC_DOMAIN="" NETCONFIG_NIS_STATIC_SERVERS="" cer@Beta:~> They are not in the same order, so comparison is not obvious. But I see these: NETCONFIG_DNS_FORWARDER='resolver' NETCONFIG_DNS_FORWARDER="dnsmasq" NETCONFIG_DNS_POLICY='auto' NETCONFIG_DNS_POLICY="STATIC" Now, where should dnsmasq get the external forwarders from... ah: laicolasse (NM): # Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #CER resolv-file=/run/NetworkManager/no-stub-resolv.conf Telcontar: # Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #resolv-file= Ok, I have to change that one. To what, using wicked? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-05-08 11:40, Carlos E. R. wrote:
On 2023-05-08 11:20, Per Jessen wrote:
Carlos E. R. wrote:
And I thought it was the same machine I had asked about dnsmasq recently, so the details would be remembered, but it isn't.
It's probably a little too much to expect us to remember the config of your machines :-)
Hey, it was 4:30 AM. I wasn't thinking much.
Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ #
That IPv6 address I do not want there, it should be inside dnsmasq.
I guess you want nobody to touch your resolv.conf, but your ipv6 config still updates it. Isn't this one of the NETCONFIG* options in /etc/sysconfig/network/config ?
cer@Telcontar:~> grep NETCONFIG /etc/sysconfig/network/config NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime" NETCONFIG_DNS_POLICY='auto' NETCONFIG_DNS_FORWARDER='resolver' NETCONFIG_DNS_STATIC_SEARCHLIST='valinor' NETCONFIG_DNS_STATIC_SERVERS='127.0.0.1 192.168.1.16' NETCONFIG_NTP_POLICY="auto" NETCONFIG_NTP_STATIC_SERVERS="" NETCONFIG_NIS_POLICY='' NETCONFIG_NIS_SETDOMAINNAME='yes' # the NETCONFIG_NIS_STATIC_DOMAIN and NETCONFIG_NIS_STATIC_SERVERS # variables, e.g.: NETCONFIG_NIS_STATIC_DOMAIN_1="second". NETCONFIG_NIS_STATIC_DOMAIN='' NETCONFIG_NIS_STATIC_SERVERS='' NETCONFIG_DNS_FORWARDER_FALLBACK="yes" NETCONFIG_DNS_RANKING="auto" NETCONFIG_DNS_RESOLVER_OPTIONS="" NETCONFIG_DNS_RESOLVER_SORTLIST="" NETCONFIG_VERBOSE="no" NETCONFIG_FORCE_REPLACE="no"
In Laicolasse (the machine in the other thread), I have:
cer@Beta:~> grep NETCONFIG /Other/etc/sysconfig/network/config NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime" NETCONFIG_VERBOSE="no" NETCONFIG_FORCE_REPLACE="no" NETCONFIG_DNS_POLICY="STATIC" #NETCONFIG_DNS_POLICY="" #NETCONFIG_DNS_POLICY="auto" NETCONFIG_DNS_FORWARDER="dnsmasq" NETCONFIG_DNS_FORWARDER_FALLBACK="yes" NETCONFIG_DNS_STATIC_SEARCHLIST="valinor" # When the NETCONFIG_DNS_FORWARDER variable is set to "resolver", NETCONFIG_DNS_STATIC_SERVERS="127.0.0.1" NETCONFIG_DNS_RANKING="auto" NETCONFIG_DNS_RESOLVER_OPTIONS="" NETCONFIG_DNS_RESOLVER_SORTLIST="" NETCONFIG_NTP_POLICY="auto" NETCONFIG_NTP_STATIC_SERVERS="" NETCONFIG_NIS_POLICY="auto" NETCONFIG_NIS_SETDOMAINNAME="yes" # the NETCONFIG_NIS_STATIC_DOMAIN and NETCONFIG_NIS_STATIC_SERVERS # variables, e.g.: NETCONFIG_NIS_STATIC_DOMAIN_1="second". NETCONFIG_NIS_STATIC_DOMAIN="" NETCONFIG_NIS_STATIC_SERVERS="" cer@Beta:~>
They are not in the same order, so comparison is not obvious. But I see these:
NETCONFIG_DNS_FORWARDER='resolver' NETCONFIG_DNS_FORWARDER="dnsmasq"
NETCONFIG_DNS_POLICY='auto' NETCONFIG_DNS_POLICY="STATIC"
I have set both machines to the same settings. NETCONFIG_DNS_POLICY='STATIC' NETCONFIG_DNS_FORWARDER='dnsmasq' NETCONFIG_NIS_POLICY='auto' Except that this machine, Telcontar, is on wicked and static IPv4 address, dynamic IPv6 address.
Telcontar:
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #resolv-file=
Ok, I have to change that one. To what, using wicked?
I need this information, but no idea where from. For the moment, I have the servers hardcoded in dnsmasq.conf. There is: /run/netconfig/resolv.conf, dated this instant, that now doesn't have the IPv6 address. I see "/run/netconfig/eth0/netconfig1" which has the IPv6 information, including the DNS. I must inspect the miniserver, too. It uses wicked as well, but bind instead of dnsmasq. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-05-08 12:35, Carlos E. R. wrote:
On 2023-05-08 11:40, Carlos E. R. wrote:
I must inspect the miniserver, too. It uses wicked as well, but bind instead of dnsmasq.
No, the file is not being written frequently: Isengard:~ # l /var/run/netconfig/resolv.conf -rw-r--r-- 1 root root 691 May 2 16:53 /var/run/netconfig/resolv.conf Yet it has similar information: search Valinor nameserver 127.0.0.1 nameserver 2a02:9000::aaaa nameserver 2a02:9000::bbbb which is also incorrect, should be 127.0.0.1 only. It is also using wicked. Edited /etc/sysconfig/network/config similarly to telcontar, except with bind references. And edited the forwarders in bind (static). -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
There is:
/run/netconfig/resolv.conf, dated this instant, that now doesn't have the IPv6 address.
Seems like the obvious one. It clearly had the all the information earlier. -- Per Jessen, Zürich (21.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 13:02, Per Jessen wrote:
Carlos E. R. wrote:
There is:
/run/netconfig/resolv.conf, dated this instant, that now doesn't have the IPv6 address.
Seems like the obvious one. It clearly had the all the information earlier.
Yes, my configuration caused the extra information to be removed. This solves the problem of the file having too frequent updates. The forwarders should be listed inside bind or dnsmasq only. But no idea of the root cause, why that many updates. With NM there is another file, more useful: resolv-file=/run/NetworkManager/no-stub-resolv.conf cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf # Generated by NetworkManager search Beta.valinor nameserver 80.58.61.254 nameserver 80.58.61.250 nameserver 2a02:9000::aaaa # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 2a02:9000::bbbb cer@Beta:~> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 08.05.2023 12:40, Carlos E. R. wrote: ...
They are not in the same order, so comparison is not obvious. But I see these:
NETCONFIG_DNS_FORWARDER='resolver' NETCONFIG_DNS_FORWARDER="dnsmasq"
NETCONFIG_DNS_POLICY='auto' NETCONFIG_DNS_POLICY="STATIC"
And we still do not know which lines come from which system ...
Now, where should dnsmasq get the external forwarders from... ah:
laicolasse (NM):
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #CER resolv-file=/run/NetworkManager/no-stub-resolv.conf
Telcontar:
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #resolv-file=
Ok, I have to change that one. To what, using wicked?
dnsmasq module writes into /run/dnsmasq-forwarders.conf. It is even documented in "man 8 netconfig" ... but of course real men do not read those manuals.
On 2023-05-08 14:30, Andrei Borzenkov wrote:
On 08.05.2023 12:40, Carlos E. R. wrote: ...
They are not in the same order, so comparison is not obvious. But I see these:
NETCONFIG_DNS_FORWARDER='resolver' NETCONFIG_DNS_FORWARDER="dnsmasq"
NETCONFIG_DNS_POLICY='auto' NETCONFIG_DNS_POLICY="STATIC"
And we still do not know which lines come from which system ...
Yes you do. They are in order, you removed the information: cer@Telcontar:~> grep NETCONFIG /etc/sysconfig/network/config cer@Beta:~> grep NETCONFIG /Other/etc/sysconfig/network/config I first posted the output of those commands (the commands with their respective outputs in a single paste sweep), and then a paragraph with the differences I noticed. So:
NETCONFIG_DNS_FORWARDER='resolver' <= Telcontar NETCONFIG_DNS_FORWARDER="dnsmasq" <= Laptop used in previous thread
NETCONFIG_DNS_POLICY='auto' <= Telcontar NETCONFIG_DNS_POLICY="STATIC" <= Laptop used in previous thread
It is obvious.
Now, where should dnsmasq get the external forwarders from... ah:
laicolasse (NM):
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #CER resolv-file=/run/NetworkManager/no-stub-resolv.conf
Telcontar:
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #resolv-file=
Ok, I have to change that one. To what, using wicked?
dnsmasq module writes into /run/dnsmasq-forwarders.conf. It is even documented in "man 8 netconfig" ... but of course real men do not read those manuals.
I did not know I had to read that man page in particular. And no, the information is not there: cer@Telcontar:~> cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders ### for use as dnsmasq --resolv-file, autogenerated by netconfig! # # Before you change this file manually, consider to define the # static DNS configuration using the following variables in the # /etc/sysconfig/network/config file: # NETCONFIG_DNS_STATIC_SEARCHLIST # NETCONFIG_DNS_STATIC_SERVERS # NETCONFIG_DNS_FORWARDER # or disable DNS configuration updates via netconfig by setting: # NETCONFIG_DNS_POLICY='' # # See also the netconfig(8) manual page and other documentation. # nameserver 192.168.1.16 cer@Telcontar:~> The telefónica DNS servers are missing. It should have: 192.168.1.1 or 80.58.61.250, server=80.58.61.254 and 2a02:9000::aaaa, 2a02:9000::bbbb Another machine (Beta) that runs NM, has the correct information: cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf # Generated by NetworkManager search Beta.valinor nameserver 80.58.61.254 nameserver 80.58.61.250 nameserver 2a02:9000::aaaa # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 2a02:9000::bbbb cer@Beta:~> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
dnsmasq module writes into /run/dnsmasq-forwarders.conf. It is even documented in "man 8 netconfig" ... but of course real men do not read those manuals.
I did not know I had to read that man page in particular.
And no, the information is not there:
cer@Telcontar:~> cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders ### for use as dnsmasq --resolv-file, autogenerated by netconfig! [snip] # nameserver 192.168.1.16
That is something to investigate - for comparison: office68:~ # cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders [snip] # nameserver 192.168.2.254 nameserver 2001:db8:4c68:1::1000 So it certainly works. (office68 uses NetworkManager). I'm just now trying the same thing on tw+wicked.
cer@Telcontar:~>
The telefónica DNS servers are missing.
It should have:
192.168.1.1 or 80.58.61.250, server=80.58.61.254 and 2a02:9000::aaaa, 2a02:9000::bbbb
Yup. I would also expect to see those four listed.
Another machine (Beta) that runs NM, has the correct information:
cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf
What about /run/dnsmasq-forwarders.conf ? -- Per Jessen, Zürich (17.3°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Carlos E. R. wrote:
And no, the information is not there:
cer@Telcontar:~> cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders ### for use as dnsmasq --resolv-file, autogenerated by netconfig! [snip] # nameserver 192.168.1.16
That is something to investigate - for comparison:
office68:~ # cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders [snip] # nameserver 192.168.2.254 nameserver 2001:db8:4c68:1::1000
So it certainly works. (office68 uses NetworkManager). I'm just now trying the same thing on tw+wicked.
Works on tw with wicked (office24) too. Works on Leap15.5 with wicked (janeway) too. In that environment, I have dhcpv4, dhcpv6 and radvd, sounds much like yours. -- Per Jessen, Zürich (17.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 16:03, Per Jessen wrote:
Carlos E. R. wrote:
dnsmasq module writes into /run/dnsmasq-forwarders.conf. It is even documented in "man 8 netconfig" ... but of course real men do not read those manuals.
I did not know I had to read that man page in particular.
And no, the information is not there:
cer@Telcontar:~> cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders ### for use as dnsmasq --resolv-file, autogenerated by netconfig! [snip] # nameserver 192.168.1.16
That is something to investigate - for comparison:
office68:~ # cat /run/dnsmasq-forwarders.conf ### /run/dnsmasq-forwarders.conf: global dns forwarders [snip] # nameserver 192.168.2.254 nameserver 2001:db8:4c68:1::1000
In the summary of the previous thread on dnsmasq, I wrote that these settings were needed: NETCONFIG_DNS_POLICY="STATIC" NETCONFIG_DNS_FORWARDER="dnsmasq" NETCONFIG_DNS_FORWARDER_FALLBACK="yes" NETCONFIG_DNS_STATIC_SEARCHLIST="your_domain" NETCONFIG_DNS_STATIC_SERVERS="127.0.0.1" <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/GNWE2ZQZ3VRAQJ4Q6CUFT3FX3BVRWOXV/> In Telcontar I have: Telcontar:~ # grep "NETCONFIG_DNS_STATIC_SEARCHLIST\|NETCONFIG_DNS_STATIC_SERVERS\|NETCONFIG_DNS_FORWARDER\|NETCONFIG_DNS_POLICY" /etc/sysconfig/network/config | egrep -v "^[[:space:]]*$|^#" NETCONFIG_DNS_POLICY='STATIC' NETCONFIG_DNS_FORWARDER='dnsmasq' NETCONFIG_DNS_STATIC_SEARCHLIST='valinor' NETCONFIG_DNS_STATIC_SERVERS='127.0.0.1 192.168.1.16' NETCONFIG_DNS_FORWARDER_FALLBACK="yes" Telcontar:~ # So that part is correct. My summary also says to put in /etc/dnsmasq.conf this: resolv-file=/run/NetworkManager/no-stub-resolv.conf But this machine is using wicked. Notice that /run/netconfig/resolv.conf and /run/NetworkManager/no-stub-resolv.conf are similar files but not the same. The former would take its values from /etc/sysconfig/network/config and be static (because NETCONFIG_DNS_POLICY='STATIC'), for use by other software and telling them to ask the local dnsmasq server, while the later contains the remote dns servers and be dynamic. With wicked, the remote DNS information is in /run/wicked/leaseinfo.eth0.auto.ipv6 and leaseinfo.eth0.static.ipv4, but not in a form that can be included in dnsmasq.conf, I think: Telcontar:~ # cat /run/wicked/leaseinfo.eth0.auto.ipv6 INTERFACE='eth0' TYPE='auto' FAMILY='ipv6' UUID='b5c83...' IPADDR='2a02:.../64' PREFIXLEN='64' IPADDR_1='fd81:.../64' PREFIXLEN_1='64' DNSSERVERS='2a02:9000::aaaa 2a02:9000::bbbb' I hope this clarifies what information can be found where. That file is constantly being written! Telcontar:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 262 May 8 20:03 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 262 May 8 20:04 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # This is the cause of the current problem that started this thread. It happens also on the miniserver: Isengard:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 264 May 8 20:06 /run/wicked/leaseinfo.eth0.auto.ipv6 Isengard:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 264 May 8 20:07 /run/wicked/leaseinfo.eth0.auto.ipv6 Isengard:~ # But not this file: Isengard:~ # l /etc/resolv.conf lrwxrwxrwx 1 root root 30 Mar 5 23:22 /etc/resolv.conf -> /var/run/netconfig/resolv.conf Isengard:~ # Isengard:~ # l /var/run/netconfig/resolv.conf -rw-r--r-- 1 root root 622 May 8 12:54 /var/run/netconfig/resolv.conf Isengard:~ # same in Telcontar: Telcontar:~ # l /etc/resolv.conf /var/run/netconfig/resolv.conf lrwxrwxrwx 1 root root 30 Nov 29 20:24 /etc/resolv.conf -> /var/run/netconfig/resolv.conf -rw-r--r-- 1 root root 661 May 8 12:26 /var/run/netconfig/resolv.conf Telcontar:~ # This is because now on both machines the contents are static (because NETCONFIG_DNS_POLICY='STATIC'). nameserver 127.0.0.1 Now, why is /run/wicked/leaseinfo.eth0.auto.ipv6 being written every minute, I have no idea. Maybe my router is the culprit again. No idea now how to find out.
So it certainly works. (office68 uses NetworkManager). I'm just now trying the same thing on tw+wicked.
cer@Telcontar:~>
The telefónica DNS servers are missing.
It should have:
192.168.1.1 or 80.58.61.250, server=80.58.61.254 and 2a02:9000::aaaa, 2a02:9000::bbbb
Yup. I would also expect to see those four listed.
Maybe it is just a difference between wicked and NM.
Another machine (Beta) that runs NM, has the correct information:
cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf
What about /run/dnsmasq-forwarders.conf ?
The Beta machine doesn't have dnsmasq. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
With wicked, the remote DNS information is in /run/wicked/leaseinfo.eth0.auto.ipv6 and leaseinfo.eth0.static.ipv4, but not in a form that can be included in dnsmasq.conf, I think:
But if you change NETCONFIG_DNS_POLICY to 'auto', you can use /run/dnsmasq-forwarders.conf, right? At least that is what I saw working this afternoon.
/run/wicked/leaseinfo.eth0.auto.ipv6 is constantly being written!
Telcontar:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 262 May 8 20:03 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 262 May 8 20:04 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ #
This is the cause of the current problem that started this thread.
As I suggested in my first reply this morning "Sounds like a lease being renewed.".
Now, why is /run/wicked/leaseinfo.eth0.auto.ipv6 being written every minute, I have no idea. Maybe my router is the culprit again.
It is definitely your router.
No idea now how to find out.
Old fashioned debugging. Follow the logic and look for when it breaks. If a lease is being renewed, it is because it has expired. When it expires very quickly, that suggests it was issued with a very short lifetime. You ought to be able to see that in the log, I posted some typical messages earlier today. I get those on TW and leap15.5, but not on leap15.3 - maybe it is a wicked option that needs tweaking. Alternatively, run a tcpdump on the interface, only looking for ip6 traffic. Wireshark will probably break it down nicely for you. My hunch - your router is issuing ipv6 leases with 60second lifetime. Dunno why.
Maybe it is just a difference between wicked and NM.
I think the key difference is in NETCONFIG_DNS_POLICY.
cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf
What about /run/dnsmasq-forwarders.conf ?
The Beta machine doesn't have dnsmasq.
So install it. That's what I did earlier, to test. -- Per Jessen, Zürich (17.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
lifetime. You ought to be able to see that in the log, I posted some typical messages earlier today. I get those on TW and leap15.5, but not on leap15.3 - maybe it is a wicked option that needs tweaking.
Ignore that - on the leap15.3 system where I see no wicked messages ... I am using NM. Duh. Sorry about the red herring. I checked a couple of other systems, Leap 15.1 &B TW - I see the wicked log messages. -- Per Jessen, Zürich (16.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 20:46, Per Jessen wrote:
Carlos E. R. wrote:
With wicked, the remote DNS information is in /run/wicked/leaseinfo.eth0.auto.ipv6 and leaseinfo.eth0.static.ipv4, but not in a form that can be included in dnsmasq.conf, I think:
But if you change NETCONFIG_DNS_POLICY to 'auto', you can use /run/dnsmasq-forwarders.conf, right? At least that is what I saw working this afternoon.
The file then changes to: nameserver 192.168.1.16 nameserver 2a02:9000::aaaa nameserver 2a02:9000::bbbb which is indeed the contents I need. I will have to check if the file remains static. [... writing after writing other paragraphs in this post] No, it is not. Telcontar:~ # l /run/dnsmasq-forwarders.conf -rw-r--r-- 1 root root 634 May 8 20:54 /run/dnsmasq-forwarders.conf Telcontar:~ # l /run/dnsmasq-forwarders.conf -rw-r--r-- 1 root root 634 May 8 20:54 /run/dnsmasq-forwarders.conf Telcontar:~ # l /run/dnsmasq-forwarders.conf -rw-r--r-- 1 root root 634 May 8 20:54 /run/dnsmasq-forwarders.conf Telcontar:~ # Telcontar:~ # l /run/dnsmasq-forwarders.conf -rw-r--r-- 1 root root 634 May 8 21:04 /run/dnsmasq-forwarders.conf Telcontar:~ # Thus, I can not use NETCONFIG_DNS_POLICY="auto".
/run/wicked/leaseinfo.eth0.auto.ipv6 is constantly being written!
Telcontar:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 262 May 8 20:03 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # l /run/wicked/leaseinfo.eth0.auto.ipv6 -rw-r--r-- 1 root root 262 May 8 20:04 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ #
This is the cause of the current problem that started this thread.
As I suggested in my first reply this morning "Sounds like a lease being renewed.".
But why every minute or so?
Now, why is /run/wicked/leaseinfo.eth0.auto.ipv6 being written every minute, I have no idea. Maybe my router is the culprit again.
It is definitely your router.
Ok, what command or file would tell the timeout? Yes, I'm googling, no success. See later below.
No idea now how to find out.
Old fashioned debugging. Follow the logic and look for when it breaks.
If a lease is being renewed, it is because it has expired. When it expires very quickly, that suggests it was issued with a very short lifetime. You ought to be able to see that in the log, I posted some typical messages earlier today. I get those on TW and leap15.5, but not on leap15.3 - maybe it is a wicked option that needs tweaking.
But those messages, if they are the ones I remember, do not happen in my machine.
Alternatively, run a tcpdump on the interface, only looking for ip6 traffic. Wireshark will probably break it down nicely for you.
My hunch - your router is issuing ipv6 leases with 60second lifetime. Dunno why.
It would suffice for now to prove it. There must be some command that prints the timeout of the lease. If I look on /var/lib/dhcp, the *lease files are dated year 2013. Telcontar:~ # l /var/lib/dhcp/dhclient.leases -rw-r--r-- 1 root root 0 Aug 12 2012 /var/lib/dhcp/dhclient.leases Telcontar:~ # So I hesitate to issue a dhcpclient command to find out the timeout of the lease and break something else.
Maybe it is just a difference between wicked and NM.
I think the key difference is in NETCONFIG_DNS_POLICY.
No, the file /run/NetworkManager/no-stub-resolv.conf has a different structure and purpose than /run/wicked/leaseinfo.eth0.auto.ipv6
cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf
What about /run/dnsmasq-forwarders.conf ?
The Beta machine doesn't have dnsmasq.
So install it. That's what I did earlier, to test.
It would be easier to boot the Laicolasse partition, but that would break another unrelated test that I'm doing. I try to keep the Beta partition simple. Configuring dnsmasq would be a further complication. On 2023-05-08 21:03, Per Jessen wrote:
Per Jessen wrote:
lifetime. You ought to be able to see that in the log, I posted some typical messages earlier today. I get those on TW and leap15.5, but not on leap15.3 - maybe it is a wicked option that needs tweaking.
Ignore that - on the leap15.3 system where I see no wicked messages ... I am using NM. Duh. Sorry about the red herring.
I checked a couple of other systems, Leap 15.1 &B TW - I see the wicked log messages.
There are only two messages today from wicked, nothing about a lease changing:
Telcontar:~ # journalctl -b | grep -i wicked
Apr 14 23:42:13 Telcontar systemd[1]: Starting wicked AutoIPv4 supplicant service...
...
May 06 11:56:47 Telcontar wickedd[1571]: route ipv4 0.0.0.0/0 via 192.168.1.1 dev eth0#2 type unicast table main scope universe protocol boot covered by a ipv4:static lease May 06 19:16:55 Telcontar wickedd[1571]: route ipv4 0.0.0.0/0 via 192.168.1.1 dev eth0#2 type unicast table main scope universe protocol boot covered by a ipv4:static lease May 07 12:20:11 Telcontar wickedd[1571]: route ipv4 0.0.0.0/0 via 192.168.1.1 dev eth0#2 type unicast table main scope universe protocol boot covered by a ipv4:static lease May 08 10:40:21 Telcontar wickedd[1571]: route ipv4 0.0.0.0/0 via 192.168.1.1 dev eth0#2 type unicast table main scope universe protocol boot covered by a ipv4:static lease May 08 19:24:26 Telcontar wickedd[1571]: route ipv4 0.0.0.0/0 via 192.168.1.1 dev eth0#2 type unicast table main scope universe protocol boot covered by a ipv4:static lease
I have started Ethereal, and run it for a minute or two, till I noticed the file /run/wicked/leaseinfo.eth0.auto.ipv6 changing. There are no dhcpv6 packets. Then I did a filter on IPv6 packets. There aren't many. Most are ICMP. I'll mail that direct to you if you want to have a look. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-05-08 21:32, Carlos E. R. wrote:
On 2023-05-08 20:46, Per Jessen wrote:
Carlos E. R. wrote:
...
I have started Ethereal, and run it for a minute or two, till I noticed the file /run/wicked/leaseinfo.eth0.auto.ipv6 changing.
There are no dhcpv6 packets.
Then I did a filter on IPv6 packets. There aren't many. Most are ICMP. I'll mail that direct to you if you want to have a look.
Here goes.
9 21:23:27.596936667 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 19 21:23:30.009606005 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 20 21:23:30.112980336 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 45 21:23:31.073785662 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 181 21:23:39.807778390 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 185 21:23:39.964928263 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 197 21:23:40.349876898 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 272 21:23:49.772851049 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 273 21:23:50.105146183 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 285 21:23:51.020973692 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 341 21:23:57.923743446 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 342 21:23:58.094205638 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 343 21:23:58.261571382 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 344 21:23:58.619493534 fe80::5a5f:fa3f:829f:ced2 ff02::2 ICMPv6 62 Router Solicitation 417 21:24:01.273675215 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 418 21:24:01.473152828 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 419 21:24:02.209717143 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 440 21:24:05.123015081 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 441 21:24:05.469223015 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 442 21:24:05.829152899 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 453 21:24:08.546627577 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 457 21:24:08.845175317 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 484 21:24:09.509821692 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 541 21:24:17.422291327 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 546 21:24:17.748916019 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 547 21:24:18.145705127 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 644 21:24:24.000476627 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 645 21:24:24.201087029 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 646 21:24:24.240788778 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 652 21:24:26.627823025 2a02:9140:1180:0:2d8:61ff:fea1:5abd ff02::fb MDNS 216 Standard query 0x0000 SRV _domain._udp.local, "QM" question PTR _smb._tcp.local, "QM" question PTR _nfs._tcp.local, "QM" question PTR _afpovertcp._tcp.local, "QM" question PTR _sftp-ssh._tcp.local, "QM" question PTR _webdavs._tcp.local, "QM" question PTR _webdav._tcp.local, "QM" question PTR _ftp._tcp.local, "QM" question PTR _nmea-0183._tcp.local, "QM" question 653 21:24:26.655771227 2a02:9140:1180:0:bbe6:d24f:4049:2602 ff02::fb MDNS 294 Standard query response 0x0000 PTR ISENGARD._smb._tcp.local TXT, cache flush SRV, cache flush 0 0 445 Isengard.local AAAA, cache flush fc00::16 AAAA, cache flush 2a02:9140:1180:0:4ecc:6aff:fe61:50a1 AAAA, cache flush fd81:8fe5:f937:0:4ecc:6aff:fe61:50a1 AAAA, cache flush 2a02:9140:1180:0:8b52:ed56:12b6:fe6b AAAA, cache flush fd81:8fe5:f937:0:f72f:f284:7877:79cb 655 21:24:26.723317918 2a02:9140:1180:0:2d8:61ff:fea1:5abd ff02::fb MDNS 268 Standard query response 0x0000 PTR TELCONTAR._smb._tcp.local TXT, cache flush SRV, cache flush 0 0 445 Telcontar.local AAAA, cache flush 2a02:9140:1180:0:2d8:61ff:fea1:5abd AAAA, cache flush fd81:8fe5:f937:0:2d8:61ff:fea1:5abd AAAA, cache flush fd81:8fe5:f937:0:9b75:9a18:545c:e06b AAAA, cache flush 2a02:9140:1180:0:83b3:e3f:9dc9:dfa8 816 21:24:31.506532087 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 817 21:24:31.552904287 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 818 21:24:32.001007998 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 972 21:24:38.576554488 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 973 21:24:38.620999065 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 984 21:24:38.741345894 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1152 21:24:47.005408573 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1153 21:24:47.244906300 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1154 21:24:47.316784838 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1275 21:24:56.559742907 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1276 21:24:56.773038255 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1279 21:24:57.156922895 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1395 21:25:03.617302055 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1396 21:25:03.837167082 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1401 21:25:04.417000132 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1402 21:25:07.167612751 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1416 21:25:07.517276240 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1444 21:25:07.885011536 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1497 21:25:13.235892209 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1498 21:25:13.332797873 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1499 21:25:13.393308503 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1540 21:25:17.518992692 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1549 21:25:17.660852203 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1550 21:25:18.081344344 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1618 21:25:27.208731049 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 1625 21:25:27.489017071 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1626 21:25:27.644851672 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2 1723 21:25:32.708165204 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
I have started Ethereal, and run it for a minute or two, till I noticed the file /run/wicked/leaseinfo.eth0.auto.ipv6 changing.
There are no dhcpv6 packets.
Then I did a filter on IPv6 packets. There aren't many. Most are ICMP. I'll mail that direct to you if you want to have a look.
Here goes.
Did you read it yourself? I don't really read Ethereal, but even then I can still see an RA being sent every minute. Problem identified. -- Per Jessen, Zürich (15.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 23:28, Per Jessen wrote:
Carlos E. R. wrote:
I have started Ethereal, and run it for a minute or two, till I noticed the file /run/wicked/leaseinfo.eth0.auto.ipv6 changing.
There are no dhcpv6 packets.
Then I did a filter on IPv6 packets. There aren't many. Most are ICMP. I'll mail that direct to you if you want to have a look.
Here goes.
Did you read it yourself? I don't really read Ethereal, but even then I can still see an RA being sent every minute.
Problem identified.
Yes, I did read it myself. I grep for the word "RA" and don't find it. You are assuming I know how to read ethereal output. No, I don't, I can only read parts of it. Ok, you mean "Router Advertisement". There is one about every 10 seconds. I don't know what "Router Advertisement" means, but now that you mention it, I will look further.
No Time source dest proto length Info 19 21:23:30.009606005 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 20 21:23:30.112980336 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2
I assume that "destination ff02::1" is the router. So the router is telling the router? cer@Isengard:~> ip addr | grep ":16" inet6 fc00::16/64 scope global cer@Isengard:~> I can not find "ff02::16", but "fc00::16", and is the miniserver, not this machine. [...] I can not read what that packet capture means. But I see that inside it contains DNS information. [...] Ok, can I tell the ISP / Beta people anything? This moment I don't know what to tell them. Or why bother. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-08 23:28, Per Jessen wrote:
Carlos E. R. wrote:
I have started Ethereal, and run it for a minute or two, till I noticed the file /run/wicked/leaseinfo.eth0.auto.ipv6 changing.
There are no dhcpv6 packets.
Then I did a filter on IPv6 packets. There aren't many. Most are ICMP. I'll mail that direct to you if you want to have a look.
Here goes.
Did you read it yourself? I don't really read Ethereal, but even then I can still see an RA being sent every minute.
Problem identified.
Yes, I did read it myself.
I grep for the word "RA" and don't find it. You are assuming I know how to read ethereal output.
As you were using the tool, yes, I did think you had some familiarity with it. (I don't use it).
No Time source dest proto length Info 19 21:23:30.009606005 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 20 21:23:30.112980336 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2
I assume that "destination ff02::1" is the router.
ff02::1 is a multicast address meaning "All Nodes". Fyi, ff00::/8 are all multicast addresses. The Ethereal output even explains it in plain text "Router Advertisement from cc:ed:dc:05:80:d4". I think I remember cc:ed:dc:05:80:d4 being your router. (cc:ed:dc = Mitrastar). So, it is your router informing everyone on the network about the router address. iow, a Router Advertisement.
I can not read what that packet capture means.
Nor can I :-) I see your router sending very frequent RAs. I have no idea what those "Multicast Listener Report" are for, but ff02::16 is for "all MLDv2 capable routers".
Ok, can I tell the ISP / Beta people anything? This moment I don't know what to tell them. Or why bother.
Given how responsive they are, it might not be worth it, but you could ask why your router is sending an RA every 10seconds. Normally, an RA is sent in response to a router solicitation (ff02::2) or at regular intervals. The default for radvd is every 200seconds, for instance. However - I don't think an RA should cause your /etc/resolv.conf to be updated, unless the DNS also changes. -- Per Jessen, Zürich (15.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-09 08:30, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-08 23:28, Per Jessen wrote:
Carlos E. R. wrote:
I have started Ethereal, and run it for a minute or two, till I noticed the file /run/wicked/leaseinfo.eth0.auto.ipv6 changing.
There are no dhcpv6 packets.
Then I did a filter on IPv6 packets. There aren't many. Most are ICMP. I'll mail that direct to you if you want to have a look.
Here goes.
Did you read it yourself? I don't really read Ethereal, but even then I can still see an RA being sent every minute.
Problem identified.
Yes, I did read it myself.
I grep for the word "RA" and don't find it. You are assuming I know how to read ethereal output.
As you were using the tool, yes, I did think you had some familiarity with it. (I don't use it).
I have some familiarity with it, none with tcpdump. I understand some of the conversations, but not these. You instantly noticed these RA. If you'd like me to repeat the capture with tcpdump, I need to know the exact concoction.
No Time source dest proto length Info 19 21:23:30.009606005 fe80::ceed:dcff:fe05:80d4 ff02::1 ICMPv6 206 Router Advertisement from cc:ed:dc:05:80:d4 20 21:23:30.112980336 fe80::5a5f:fa3f:829f:ced2 ff02::16 ICMPv6 190 Multicast Listener Report Message v2
I assume that "destination ff02::1" is the router.
ff02::1 is a multicast address meaning "All Nodes". Fyi, ff00::/8 are all multicast addresses. The Ethereal output even explains it in plain text "Router Advertisement from cc:ed:dc:05:80:d4". I think I remember cc:ed:dc:05:80:d4 being your router. (cc:ed:dc = Mitrastar).
Ok, so the address is not an address, but it signals what it is.
So, it is your router informing everyone on the network about the router address. iow, a Router Advertisement.
I can not read what that packet capture means.
Nor can I :-) I see your router sending very frequent RAs. I have no idea what those "Multicast Listener Report" are for, but ff02::16 is for "all MLDv2 capable routers".
Ok, but then those two packages are not dhcp informing that the DNS has changed? Or are they?
Ok, can I tell the ISP / Beta people anything? This moment I don't know what to tell them. Or why bother.
Given how responsive they are, it might not be worth it, but you could ask why your router is sending an RA every 10seconds.
Normally, an RA is sent in response to a router solicitation (ff02::2) or at regular intervals. The default for radvd is every 200seconds, for instance.
However - I don't think an RA should cause your /etc/resolv.conf to be updated, unless the DNS also changes.
No, the address doesn't change. So, it is normal for a router to send RA every 200 seconds? Then it is not the router fault (yet), there is something else. Maybe Linux overreacting. Shouldn't Linux see that the address is the same, and do nothing? My ISP people are weird. They did something to my router, so that the firewall is now working. No idea if firmware update or configuration change, but they did something. And they never said a word. Wait, I just looked and there was a post yesterday: "we have reiterated this case." Dunno what it means, don't ask the translator. My guess, there is someone tending to the forum and sending information to the technicians, but getting no answer from them; nevertheless, the technicians do things. So the forum guy can't say anything because he knows nothing, only that he forwarded the information. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-09 08:30, Per Jessen wrote:
ff02::1 is a multicast address meaning "All Nodes". Fyi, ff00::/8 are all multicast addresses. The Ethereal output even explains it in plain text "Router Advertisement from cc:ed:dc:05:80:d4". I think I remember cc:ed:dc:05:80:d4 being your router. (cc:ed:dc = Mitrastar).
Ok, so the address is not an address, but it signals what it is.
It is an address, a multicast address. Much like a broadcast or multicast IPv4 address. There are other multicast addresses that are dedicated for specific purposes, e.g. ff05::101 for ntp.
However - I don't think an RA should cause your /etc/resolv.conf to be updated, unless the DNS also changes.
No, the address doesn't change.
So, it is normal for a router to send RA every 200 seconds?
Yes, that is quite typical I would say. It is the default in radvd.
Then it is not the router fault (yet), there is something else. Maybe Linux overreacting.
Your router is sending an RA every 10 seconds though - that is not normal, but not necessarily a problem.
Shouldn't Linux see that the address is the same, and do nothing?
That seems reasonable, but as we don't know the exact contents of the RA, it's not easy to say. My /etc/resolv.conf files only change when the machine is rebooted. The DNS servers (RDNSS) and the search list (DNSSL) may be supplied in the RA, and they may have a lifetime specified. (RFC8106). Wild guessing - when your /etc/resolv.conf changes every minute, perhaps it is because the lifetime is set incorrectly. You could try running a tcpdump : tcpdump -s0 -wcapturefile -n -i interface icmp6 Look at the capturefile with wireshark, see what it says about the RA contents. I'm doing the same just now, I just don't get very many RAs :-) -- Per Jessen, Zürich (21.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Carlos E. R. wrote:
Shouldn't Linux see that the address is the same, and do nothing?
That seems reasonable, but as we don't know the exact contents of the RA, it's not easy to say. My /etc/resolv.conf files only change when the machine is rebooted.
The DNS servers (RDNSS) and the search list (DNSSL) may be supplied in the RA, and they may have a lifetime specified. (RFC8106).
I have captured some of mine - they show 600seconds lifetime for the DNS options, but the resolv.conf is not updated, so maybe wicked does indeed look at the contents to see if an update is required. https://paste.opensuse.org/pastes/7d9e75f506a3 https://paste.opensuse.org/pastes/a1b0bf038c37 -- Per Jessen, Zürich (23.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-05-09 a las 14:36 +0200, Per Jessen escribió:
Per Jessen wrote:
Carlos E. R. wrote:
Shouldn't Linux see that the address is the same, and do nothing?
That seems reasonable, but as we don't know the exact contents of the RA, it's not easy to say. My /etc/resolv.conf files only change when the machine is rebooted.
The DNS servers (RDNSS) and the search list (DNSSL) may be supplied in the RA, and they may have a lifetime specified. (RFC8106).
I have captured some of mine - they show 600seconds lifetime for the DNS options, but the resolv.conf is not updated, so maybe wicked does indeed look at the contents to see if an update is required.
Ah, I see the lifetime "30". I should have noticed that myself. I did not sleep much...
https://paste.opensuse.org/pastes/7d9e75f506a3 https://paste.opensuse.org/pastes/a1b0bf038c37
That's cheating, you got help from a feline expert. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZFpBqxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVUy8An04KrwH0dD4xDh9BKzel 2eYq4waMAJ44sgZ7TCu2Z+5r3Lh63aBBTfatLg== =4oGm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-05-09 a las 14:12 +0200, Per Jessen escribió:
Carlos E. R. wrote:
On 2023-05-09 08:30, Per Jessen wrote:
ff02::1 is a multicast address meaning "All Nodes". Fyi, ff00::/8 are all multicast addresses. The Ethereal output even explains it in plain text "Router Advertisement from cc:ed:dc:05:80:d4". I think I remember cc:ed:dc:05:80:d4 being your router. (cc:ed:dc = Mitrastar).
Ok, so the address is not an address, but it signals what it is.
It is an address, a multicast address. Much like a broadcast or multicast IPv4 address. There are other multicast addresses that are dedicated for specific purposes, e.g. ff05::101 for ntp.
Ok.
However - I don't think an RA should cause your /etc/resolv.conf to be updated, unless the DNS also changes.
No, the address doesn't change.
So, it is normal for a router to send RA every 200 seconds?
Yes, that is quite typical I would say. It is the default in radvd.
Then it is not the router fault (yet), there is something else. Maybe Linux overreacting.
Your router is sending an RA every 10 seconds though - that is not normal, but not necessarily a problem.
Ah. 10 seconds. But Linux reacts about every minute or two. Wait, I don't really know, the timestamp of the file doesn't show seconds. Telcontar:~ # ls -l --full-time /run/wicked/leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 14:33:31.340692040 +0200 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # ls -l --full-time /run/wicked/leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 14:33:31.340692040 +0200 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # ls -l --full-time /run/wicked/leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 14:33:36.480692009 +0200 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # ls -l --full-time /run/wicked/leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 14:33:41.604691979 +0200 /run/wicked/leaseinfo.eth0.auto.ipv6 Telcontar:~ # Bingo! :-(
Shouldn't Linux see that the address is the same, and do nothing?
That seems reasonable, but as we don't know the exact contents of the RA, it's not easy to say. My /etc/resolv.conf files only change when the machine is rebooted.
The DNS servers (RDNSS) and the search list (DNSSL) may be supplied in the RA, and they may have a lifetime specified. (RFC8106).
Wild guessing - when your /etc/resolv.conf changes every minute, perhaps it is because the lifetime is set incorrectly.
You could try running a tcpdump :
tcpdump -s0 -wcapturefile -n -i interface icmp6
I captured 5 packets, 3 RA. Yes, the packet contains information about the IPv6 DNS servers, route and prefix. I can mail you the 896 bytes of the capture, if you wish.
Look at the capturefile with wireshark, see what it says about the RA contents. I'm doing the same just now, I just don't get very many RAs :-)
- -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZFpAchwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV0VUAoIyEnG1EP0fDeXJnJyCp cRxPNTrYAJ4zBf+k24tyWUc7jscJVCBhca8AIw== =KiwT -----END PGP SIGNATURE-----
On 09.05.2023 15:12, Per Jessen wrote:
You could try running a tcpdump :
tcpdump -s0 -wcapturefile -n -i interface icmp6
tshark -i wlp2s0 -Y icmpv6.type==134 -V icmp6 will dump full content of RA and RA only in readable form suitable for posting :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-05-09 a las 15:46 +0300, Andrei Borzenkov escribió:
On 09.05.2023 15:12, Per Jessen wrote:
You could try running a tcpdump :
tcpdump -s0 -wcapturefile -n -i interface icmp6
tshark -i wlp2s0 -Y icmpv6.type==134 -V icmp6
will dump full content of RA and RA only in readable form suitable for posting :)
Thanks. Telcontar:~ # tshark -i eth0 -Y icmpv6.type==134 -V icmp6 > tshark_capture Running as user "root" and group "root". This could be dangerous. Capturing on 'eth0' ** (tshark:25609) 14:57:14.589158 [Main MESSAGE] -- Capture started. ** (tshark:25609) 14:57:14.589229 [Main MESSAGE] -- File: "/tmp/wireshark_eth07WWD41.pcapng" 3 ^C Telcontar:~ # l /tmp/wireshark_eth07WWD41.pcapng ls: cannot access '/tmp/wireshark_eth07WWD41.pcapng': No such file or directory Telcontar:~ # susepaste -n "Carlos E R" -t "capture tshark" -e 40320 tshark_capture Pasted as: https://susepaste.org/35e4671eb5dc https://paste.opensuse.org/35e4671eb5dc Link is also in your clipboard. Telcontar:~ # - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZFpEKhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV1WUAnjZGaW8QIJCH0mnwetSj R3yqqE7dAJ4iyikLtqICMuvTsZQQVoxUI3tFPg== =Hd3T -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Telcontar:~ # tshark -i eth0 -Y icmpv6.type==134 -V icmp6 > tshark_capture Running as user "root" and group "root". This could be dangerous. Capturing on 'eth0' ** (tshark:25609) 14:57:14.589158 [Main MESSAGE] -- Capture started. ** (tshark:25609) 14:57:14.589229 [Main MESSAGE] -- File: "/tmp/wireshark_eth07WWD41.pcapng" 3 ^C Telcontar:~ # l /tmp/wireshark_eth07WWD41.pcapng ls: cannot access '/tmp/wireshark_eth07WWD41.pcapng': No such file or directory Telcontar:~ # susepaste -n "Carlos E R" -t "capture tshark" -e 40320 tshark_capture Pasted as: https://susepaste.org/35e4671eb5dc https://paste.opensuse.org/35e4671eb5dc
So your router is spitting out unsolicited RAs just four seconds apart :-) Certainly unusual, but I don't think it's a problem. 30 second lifetime for the DNS servers certainly seems very short, but your /run/netconfig/resolv.conf is being updated on every RA, right? Your initial post showed 5-8-11 seconds between dnsmasq reloads. I'm running out of ideas. I don't see (m)any unsolicited RAs on my system, maybe I'll have to run a trace for much longer. Wild guessing - is there any reason to think wicked would treat an unsolicited RA differently to one sent in response to a Router Solicitation? -- Per Jessen, Zürich (23.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 09.05.2023 16:01, Carlos E. R. wrote:
El 2023-05-09 a las 15:46 +0300, Andrei Borzenkov escribió:
On 09.05.2023 15:12, Per Jessen wrote:
You could try running a tcpdump :
tcpdump -s0 -wcapturefile -n -i interface icmp6
tshark -i wlp2s0 -Y icmpv6.type==134 -V icmp6
will dump full content of RA and RA only in readable form suitable for posting :)
Thanks.
Telcontar:~ # tshark -i eth0 -Y icmpv6.type==134 -V icmp6 > tshark_capture Running as user "root" and group "root". This could be dangerous. Capturing on 'eth0' ** (tshark:25609) 14:57:14.589158 [Main MESSAGE] -- Capture started. ** (tshark:25609) 14:57:14.589229 [Main MESSAGE] -- File: "/tmp/wireshark_eth07WWD41.pcapng" 3 ^C Telcontar:~ # l /tmp/wireshark_eth07WWD41.pcapng ls: cannot access '/tmp/wireshark_eth07WWD41.pcapng': No such file or directory Telcontar:~ # susepaste -n "Carlos E R" -t "capture tshark" -e 40320 tshark_capture Pasted as: https://susepaste.org/35e4671eb5dc https://paste.opensuse.org/35e4671eb5dc Link is also in your clipboard. Telcontar:~ #
RA are broadcast every 5 seconds. It is indeed too aggressive but it still is compliant with standard (which sets 3 seconds as minimal interval between unsolicited RA). So router still behaves correctly. Leasinfo timestamp matches RA. Indeed, wicked stores leasinfo every time it changes and it also calls netconfig every time lease changed. But - netconfig checks whether information was changed and only rewrites resolv.conf if there was any change. Three consecutive RA all have the same content. So it does not explain why resolv.conf is considered to be changed so often. You posted some log lines in one of the first messages and looking at them the list of DNS servers differs between each two consecutive logs from dnsmasq. To confirm it you may edit /etc/netconfig.d/dns-resolver to store each version of resolv.conf with timestamp and compare them. But RA frequency alone does not seem to be a root cause here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-05-09 at 16:49 +0300, Andrei Borzenkov wrote:
On 09.05.2023 16:01, Carlos E. R. wrote:
El 2023-05-09 a las 15:46 +0300, Andrei Borzenkov escribió:
On 09.05.2023 15:12, Per Jessen wrote:
tshark_capture Pasted as: https://susepaste.org/35e4671eb5dc https://paste.opensuse.org/35e4671eb5dc Link is also in your clipboard. Telcontar:~ #
RA are broadcast every 5 seconds. It is indeed too aggressive but it still is compliant with standard (which sets 3 seconds as minimal interval between unsolicited RA). So router still behaves correctly.
Leasinfo timestamp matches RA. Indeed, wicked stores leasinfo every time it changes and it also calls netconfig every time lease changed. But - netconfig checks whether information was changed and only rewrites resolv.conf if there was any change. Three consecutive RA all have the same content. So it does not explain why resolv.conf is considered to be changed so often.
You posted some log lines in one of the first messages and looking at them the list of DNS servers differs between each two consecutive logs from dnsmasq. To confirm it you may edit /etc/netconfig.d/dns-resolver to store each version of resolv.conf with timestamp and compare them.
But RA frequency alone does not seem to be a root cause here.
Well... it is not hapening now. I edited "/etc/netconfig.d/dns-resolver": function write_resolv_conf() ... TMP_FILE=`netconfig_mktemp "$ROOT$DESTFILE" 0644 0755` || return 3 if ! dump_resolv_conf "$@" >> "$TMP_FILE" ; then rm -f -- "$TMP_FILE" ; return 3 fi if cmp -s -- "$TMP_FILE" "$ROOT$DESTFILE" ; then rm -f -- "$TMP_FILE" # unchanged elif mv -f -- "$TMP_FILE" "$ROOT$DESTFILE" ; then changed=1 #CER MYDATE=`date --rfc-3339=ns` cp "$ROOT$DESTFILE" "$ROOT$DESTFILE$MYDATE" else rm -f -- "$TMP_FILE" ; return 3 fi Then edited /etc/sysconfig/network/config: NETCONFIG_DNS_POLICY='auto' The script did run: cer@Telcontar:~> l /run/netconfig/ total 12 drwxr-xr-x 4 root root 160 May 9 16:12 ./ drwxr-xr-x 57 root root 1660 May 9 16:12 ../ - -rw-r--r-- 1 root root 0 Apr 14 23:42 chrony.servers drwxr-xr-x 2 root root 80 May 9 16:12 eth0/ drwxr-xr-x 2 root root 80 Apr 14 23:42 lo/ - -rw-r--r-- 1 root root 688 May 9 16:08 resolv.conf - -rw-r--r-- 1 root root 688 May 9 16:08 resolv.conf2023-05-09 16:08:09.631366486+02:00 - -rw-r--r-- 1 root root 577 May 8 12:26 yp.conf cer@Telcontar:~> But resolv.conf is not changing now. This one is changing: er@Telcontar:/run/wicked> l --full-time leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 16:16:02.904582968 +0200 leaseinfo.eth0.auto.ipv6 cer@Telcontar:/run/wicked> l --full-time leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 16:16:07.644583085 +0200 leaseinfo.eth0.auto.ipv6 cer@Telcontar:/run/wicked> l --full-time leaseinfo.eth0.auto.ipv6 - -rw-r--r-- 1 root root 262 2023-05-09 16:16:07.644583085 +0200 leaseinfo.eth0.auto.ipv6 cer@Telcontar:/run/wicked> dnsmasq is being reloaded: <3.4> 2023-05-09T16:08:09.631819+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:14:31.623939+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:14:39.430471+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:15:00.937698+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:15:09.208161+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface I'm tired, it is 16:18 and I have not eaten. I can't think. Ok, now it is hapening: cer@Telcontar:/run/wicked> l /run/netconfig/ total 28 drwxr-xr-x 4 root root 240 May 9 16:20 ./ drwxr-xr-x 57 root root 1660 May 9 16:20 ../ - -rw-r--r-- 1 root root 0 Apr 14 23:42 chrony.servers drwxr-xr-x 2 root root 80 May 9 16:20 eth0/ drwxr-xr-x 2 root root 80 Apr 14 23:42 lo/ - -rw-r--r-- 1 root root 688 May 9 16:15 resolv.conf - -rw-r--r-- 1 root root 688 May 9 16:08 resolv.conf2023-05-09 16:08:09.631366486+02:00 - -rw-r--r-- 1 root root 661 May 9 16:14 resolv.conf2023-05-09 16:14:31.623802700+02:00 - -rw-r--r-- 1 root root 688 May 9 16:14 resolv.conf2023-05-09 16:14:39.429802740+02:00 - -rw-r--r-- 1 root root 661 May 9 16:15 resolv.conf2023-05-09 16:15:00.937682868+02:00 - -rw-r--r-- 1 root root 688 May 9 16:15 resolv.conf2023-05-09 16:15:09.207084556+02:00 - -rw-r--r-- 1 root root 577 May 8 12:26 yp.conf cer@Telcontar:/run/wicked> The contents do change: run/netconfig/resolv.conf2023-05-09 16:08:09.631366486+02:00 ... ### Call "netconfig update -f" to force adjusting of /etc/resolv.conf. search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa /run/netconfig/resolv.conf2023-05-09 16:14:31.623802700+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 /run/netconfig/resolv.conf2023-05-09 16:14:39.429802740+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa /run/netconfig/resolv.conf2023-05-09 16:15:00.937682868+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 /run/netconfig/resolv.conf2023-05-09 16:15:09.207084556+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Ok, going back to static, and for my lunch, or my blood presure will rocket up. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZFpa/Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVjNsAnR8erKsSDoDgo3rF8ziQ 1yxp4RqWAJ9FcuS73cotnCEust0JUHDfSSRUDQ== =GqnC -----END PGP SIGNATURE-----
Carlos E. R. wrote:
dnsmasq is being reloaded:
<3.4> 2023-05-09T16:08:09.631819+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:14:31.623939+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:14:39.430471+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:15:00.937698+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface <3.4> 2023-05-09T16:15:09.208161+02:00 Telcontar dnsmasq 23788 - - ignoring nameserver 127.0.0.1 - local interface
Ok, now it is hapening:
cer@Telcontar:/run/wicked> l /run/netconfig/ total 28 drwxr-xr-x 4 root root 240 May 9 16:20 ./ drwxr-xr-x 57 root root 1660 May 9 16:20 ../ - -rw-r--r-- 1 root root 0 Apr 14 23:42 chrony.servers drwxr-xr-x 2 root root 80 May 9 16:20 eth0/ drwxr-xr-x 2 root root 80 Apr 14 23:42 lo/ - -rw-r--r-- 1 root root 688 May 9 16:15 resolv.conf - -rw-r--r-- 1 root root 688 May 9 16:08 resolv.conf2023-05-09 16:08:09.631366486+02:00 - -rw-r--r-- 1 root root 661 May 9 16:14 resolv.conf2023-05-09 16:14:31.623802700+02:00 - -rw-r--r-- 1 root root 688 May 9 16:14 resolv.conf2023-05-09 16:14:39.429802740+02:00 - -rw-r--r-- 1 root root 661 May 9 16:15 resolv.conf2023-05-09 16:15:00.937682868+02:00 - -rw-r--r-- 1 root root 688 May 9 16:15 resolv.conf2023-05-09 16:15:09.207084556+02:00 - -rw-r--r-- 1 root root 577 May 8 12:26 yp.conf cer@Telcontar:/run/wicked>
The contents do change:
So, it alternates with and without 2a02:9000::aaaa - that is certainly odd, but I also have to wonder why 2a02:9000::bbbb isn't included. I guess the latter could be a bug, dunno. I'll try it out with my radvd. -- Per Jessen, Zürich (21.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
So, /etc/resolv.conf alternates with and without 2a02:9000::aaaa - that is certainly odd, but I also have to wonder why 2a02:9000::bbbb isn't included. I guess the latter could be a bug, dunno. I'll try it out with my radvd.
FWIW, I had no trouble dishing out multiple ipv6 nameservers and having them written to /etc/resolv.conf. I tried multiple nameserver with the same config RDNSS { } as well as multiple RDNSS statements. It only made a difference in how they were sent. -- Per Jessen, Zürich (19.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 09.05.2023 17:57, Per Jessen wrote:
So, it alternates with and without 2a02:9000::aaaa - that is certainly odd, but I also have to wonder why 2a02:9000::bbbb isn't included.
netconfig explicitly restricts name server list to three entries (which was long standing glibc limit, not sure whether it still applies).
On 2023-05-09 17:51, Andrei Borzenkov wrote:
On 09.05.2023 17:57, Per Jessen wrote:
So, it alternates with and without 2a02:9000::aaaa - that is certainly odd, but I also have to wonder why 2a02:9000::bbbb isn't included.
netconfig explicitly restricts name server list to three entries (which was long standing glibc limit, not sure whether it still applies).
Have you seen this comment in the file? cer@Laicolasse:~> cat /run/NetworkManager/no-stub-resolv.conf # Generated by NetworkManager search Laicolasse.valinor nameserver 80.58.61.254 nameserver 80.58.61.250 nameserver 2a02:9000::aaaa # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 2a02:9000::bbbb cer@Laicolasse:~> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 09.05.2023 17:38, Carlos E. R. wrote: ...
/run/netconfig/resolv.conf2023-05-09 16:14:31.623802700+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16
/run/netconfig/resolv.conf2023-05-09 16:14:39.429802740+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa
/run/netconfig/resolv.conf2023-05-09 16:15:00.937682868+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16
/run/netconfig/resolv.conf2023-05-09 16:15:09.207084556+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa
At least this explains why resolv.conf is being changed. It sounds like there are two sequences of events with 30 seconds interval. Well, we need to see the information netconfig had at this point. In the directory /run/netconfig there should be subdirectory for each interface; each subdirectory will have multiple files, one for each "service" that modified interface configuration. These should be preserved as well. Actually I would simply save the whole /run/netconfig (which also captures generated resolv.conf).
On 2023-05-09 18:09, Andrei Borzenkov wrote:
On 09.05.2023 17:38, Carlos E. R. wrote: ...
/run/netconfig/resolv.conf2023-05-09 16:14:31.623802700+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16
/run/netconfig/resolv.conf2023-05-09 16:14:39.429802740+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa
/run/netconfig/resolv.conf2023-05-09 16:15:00.937682868+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16
/run/netconfig/resolv.conf2023-05-09 16:15:09.207084556+02:00 search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa
At least this explains why resolv.conf is being changed. It sounds like there are two sequences of events with 30 seconds interval.
Well, we need to see the information netconfig had at this point. In the directory /run/netconfig there should be subdirectory for each interface; each subdirectory will have multiple files, one for each "service" that modified interface configuration. These should be preserved as well. Actually I would simply save the whole /run/netconfig (which also captures generated resolv.conf).
Ok, will run a zip command from the script. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-05-09 at 20:33 +0200, Carlos E. R. wrote:
On 2023-05-09 18:09, Andrei Borzenkov wrote:
On 09.05.2023 17:38, Carlos E. R. wrote: ...
Well, we need to see the information netconfig had at this point. In the directory /run/netconfig there should be subdirectory for each interface; each subdirectory will have multiple files, one for each "service" that modified interface configuration. These should be preserved as well. Actually I would simply save the whole /run/netconfig (which also captures generated resolv.conf).
Ok, will run a zip command from the script.
function write_resolv_conf() ... TMP_FILE=`netconfig_mktemp "$ROOT$DESTFILE" 0644 0755` || return 3 if ! dump_resolv_conf "$@" >> "$TMP_FILE" ; then rm -f -- "$TMP_FILE" ; return 3 fi if cmp -s -- "$TMP_FILE" "$ROOT$DESTFILE" ; then rm -f -- "$TMP_FILE" # unchanged elif mv -f -- "$TMP_FILE" "$ROOT$DESTFILE" ; then changed=1 #CER MYDATE=`date --rfc-3339=ns` #cp "$ROOT$DESTFILE" "$ROOT$DESTFILE$MYDATE" zip -r "/run/netconfig_$MYDATE.zip" /run/netconfig/* else rm -f -- "$TMP_FILE" ; return 3 fi And it is working. cer@Telcontar:/run/netconfig> l ../netconfig*zip ; date - -rw-r--r-- 1 root root 9946 May 9 20:40 ../netconfig_2023-05-09 20:40:31.734684686+02:00.zip - -rw-r--r-- 1 root root 9958 May 9 20:40 ../netconfig_2023-05-09 20:40:35.871011216+02:00.zip - -rw-r--r-- 1 root root 9958 May 9 20:39 ../netconfig_2023-05-09.zip 2023-05-09T20:43:05 CEST cer@Telcontar:/run/netconfig> I guess I should wait a bit more. [...] No change. cer@Telcontar:/run/netconfig> l /var/run/netconfig/resolv.conf - -rw-r--r-- 1 root root 679 May 9 20:40 /var/run/netconfig/resolv.conf cer@Telcontar:/run/netconfig> Ah! now it changes. It is 20:59. Saw that before, it stays fixed for some minutes, then it starts moving. cer@Telcontar:/run/netconfig> l ../netconfig*zip ; date - -rw-r--r-- 1 root root 9946 May 9 20:40 ../netconfig_2023-05-09 20:40:31.734684686+02:00.zip - -rw-r--r-- 1 root root 9958 May 9 20:40 ../netconfig_2023-05-09 20:40:35.871011216+02:00.zip - -rw-r--r-- 1 root root 9922 May 9 20:58 ../netconfig_2023-05-09 20:58:39.654239685+02:00.zip - -rw-r--r-- 1 root root 9958 May 9 20:58 ../netconfig_2023-05-09 20:58:42.863897679+02:00.zip - -rw-r--r-- 1 root root 9946 May 9 21:00 ../netconfig_2023-05-09 21:00:21.583604616+02:00.zip - -rw-r--r-- 1 root root 9958 May 9 20:39 ../netconfig_2023-05-09.zip <- error in scripting 2023-05-09T21:00:25 CEST cer@Telcontar:/run/netconfig> Ok, now what? (1) Archive: ./../netconfig_2023-05-09 20:40:31.734684686+02:00.zip Length Method Size Cmpr Date Time CRC-32 Name - -------- ------ ------- ---- ---------- ----- -------- ---- 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/chrony.servers 0 Stored 0 0% 2023-05-09 20:40 00000000 run/netconfig/eth0/ 310 Defl:N 213 31% 2023-05-09 20:40 a36b258f run/netconfig/eth0/netconfig1 269 Defl:N 193 28% 2023-05-08 19:24 b045d1dc run/netconfig/eth0/netconfig0 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/lo/ 207 Defl:N 163 21% 2023-04-14 23:42 42d7ff03 run/netconfig/lo/netconfig1 165 Defl:N 142 14% 2023-04-14 23:42 8e56ce4d run/netconfig/lo/netconfig0 652 Defl:N 368 44% 2023-05-09 20:40 961ac61b run/netconfig/resolv.conf 688 Defl:N 389 44% 2023-05-09 16:08 4d539003 run/netconfig/resolv.conf2023-05-09 16:08:09.631366486+02:00 661 Defl:N 375 43% 2023-05-09 16:14 7fc9a77b run/netconfig/resolv.conf2023-05-09 16:14:31.623802700+02:00 688 Defl:N 389 44% 2023-05-09 16:14 4d539003 run/netconfig/resolv.conf2023-05-09 16:14:39.429802740+02:00 661 Defl:N 375 43% 2023-05-09 16:15 7fc9a77b run/netconfig/resolv.conf2023-05-09 16:15:00.937682868+02:00 688 Defl:N 389 44% 2023-05-09 16:15 4d539003 run/netconfig/resolv.conf2023-05-09 16:15:09.207084556+02:00 661 Defl:N 375 43% 2023-05-09 16:26 7fc9a77b run/netconfig/resolv.conf2023-05-09 16:26:15.359762315+02:00 688 Defl:N 389 44% 2023-05-09 20:10 4d539003 run/netconfig/resolv.conf2023-05-09 20:10:43.765956235+02:00 661 Defl:N 375 43% 2023-05-09 20:13 7fc9a77b run/netconfig/resolv.conf2023-05-09 20:13:07.799690641+02:00 688 Defl:N 389 44% 2023-05-09 20:13 4d539003 run/netconfig/resolv.conf2023-05-09 20:13:15.368812648+02:00 661 Defl:N 375 43% 2023-05-09 20:14 7fc9a77b run/netconfig/resolv.conf2023-05-09 20:14:54.169234399+02:00 652 Defl:N 368 44% 2023-05-09 20:15 961ac61b run/netconfig/resolv.conf2023-05-09 20:15:56.487356072+02:00 577 Defl:N 333 42% 2023-05-08 12:26 b5da4559 run/netconfig/yp.conf - -------- ------- --- ------- 9577 5600 42% 20 files . (2) Archive: ./../netconfig_2023-05-09 20:40:35.871011216+02:00.zip Length Method Size Cmpr Date Time CRC-32 Name - -------- ------ ------- ---- ---------- ----- -------- ---- 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/chrony.servers 0 Stored 0 0% 2023-05-09 20:40 00000000 run/netconfig/eth0/ 310 Defl:N 213 31% 2023-05-09 20:40 a36b258f run/netconfig/eth0/netconfig1 269 Defl:N 193 28% 2023-05-08 19:24 b045d1dc run/netconfig/eth0/netconfig0 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/lo/ 207 Defl:N 163 21% 2023-04-14 23:42 42d7ff03 run/netconfig/lo/netconfig1 165 Defl:N 142 14% 2023-04-14 23:42 8e56ce4d run/netconfig/lo/netconfig0 679 Defl:N 380 44% 2023-05-09 20:40 426d8ff2 run/netconfig/resolv.conf 688 Defl:N 389 44% 2023-05-09 16:08 4d539003 run/netconfig/resolv.conf2023-05-09 16:08:09.631366486+02:00 ... 577 Defl:N 333 42% 2023-05-08 12:26 b5da4559 run/netconfig/yp.conf - -------- ------- --- ------- 9604 5612 42% 20 files (3) Archive: ./../netconfig_2023-05-09 20:58:39.654239685+02:00.zip Length Method Size Cmpr Date Time CRC-32 Name - -------- ------ ------- ---- ---------- ----- -------- ---- 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/chrony.servers 0 Stored 0 0% 2023-05-09 20:58 00000000 run/netconfig/eth0/ 265 Defl:N 189 29% 2023-05-09 20:58 99525efd run/netconfig/eth0/netconfig1 269 Defl:N 193 28% 2023-05-08 19:24 b045d1dc run/netconfig/eth0/netconfig0 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/lo/ 207 Defl:N 163 21% 2023-04-14 23:42 42d7ff03 run/netconfig/lo/netconfig1 165 Defl:N 142 14% 2023-04-14 23:42 8e56ce4d run/netconfig/lo/netconfig0 652 Defl:N 368 44% 2023-05-09 20:58 961ac61b run/netconfig/resolv.conf 688 Defl:N 389 44% 2023-05-09 16:08 4d539003 run/netconfig/resolv.conf2023-05-09 16:08:09.631366486+02:00 ... 577 Defl:N 333 42% 2023-05-08 12:26 b5da4559 run/netconfig/yp.conf - -------- ------- --- ------- 9532 5576 42% 20 files (4) Archive: ./../netconfig_2023-05-09 20:58:42.863897679+02:00.zip Length Method Size Cmpr Date Time CRC-32 Name - -------- ------ ------- ---- ---------- ----- -------- ---- 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/chrony.servers 0 Stored 0 0% 2023-05-09 20:58 00000000 run/netconfig/eth0/ 310 Defl:N 213 31% 2023-05-09 20:58 a36b258f run/netconfig/eth0/netconfig1 269 Defl:N 193 28% 2023-05-08 19:24 b045d1dc run/netconfig/eth0/netconfig0 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/lo/ 207 Defl:N 163 21% 2023-04-14 23:42 42d7ff03 run/netconfig/lo/netconfig1 165 Defl:N 142 14% 2023-04-14 23:42 8e56ce4d run/netconfig/lo/netconfig0 679 Defl:N 380 44% 2023-05-09 20:58 426d8ff2 run/netconfig/resolv.conf 688 Defl:N 389 44% 2023-05-09 16:08 4d539003 run/netconfig/resolv.conf2023-05-09 16:08:09.631366486+02:00 577 Defl:N 333 42% 2023-05-08 12:26 b5da4559 run/netconfig/yp.conf - -------- ------- --- ------- 9604 5612 42% 20 files (5) Archive: ./../netconfig_2023-05-09 21:00:21.583604616+02:00.zip Length Method Size Cmpr Date Time CRC-32 Name - -------- ------ ------- ---- ---------- ----- -------- ---- 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/chrony.servers 0 Stored 0 0% 2023-05-09 21:00 00000000 run/netconfig/eth0/ 310 Defl:N 213 31% 2023-05-09 21:00 a36b258f run/netconfig/eth0/netconfig1 269 Defl:N 193 28% 2023-05-08 19:24 b045d1dc run/netconfig/eth0/netconfig0 0 Stored 0 0% 2023-04-14 23:42 00000000 run/netconfig/lo/ 207 Defl:N 163 21% 2023-04-14 23:42 42d7ff03 run/netconfig/lo/netconfig1 165 Defl:N 142 14% 2023-04-14 23:42 8e56ce4d run/netconfig/lo/netconfig0 652 Defl:N 368 44% 2023-05-09 21:00 961ac61b run/netconfig/resolv.conf 688 Defl:N 389 44% 2023-05-09 16:08 4d539003 run/netconfig/resolv.conf2023-05-09 16:08:09.631366486+02:00 577 Defl:N 333 42% 2023-05-08 12:26 b5da4559 run/netconfig/yp.conf - -------- ------- --- ------- 9577 5600 42% 20 files I suppose you want to compare the run/netconfig/eth0/netconfig0 or run/netconfig/eth0/netconfig1 files? On "1" and "2" they are identical. Between 2 and 3 there is a change. cer@Telcontar:~/tmp/Andrei/run-3/netconfig/eth0> diff --side-by-side --ignore-space-change /home/cer/tmp/Andrei/run-2/netconfig/eth0/netconfig1 /home/cer/tmp/Andrei/run-3/netconfig/eth0/netconfig1 CREATETIME='1530692' CREATETIME='1530692' SERVICE='wicked-auto-ipv6' SERVICE='wicked-auto-ipv6' INTERFACE='eth0' INTERFACE='eth0' TYPE='auto' TYPE='auto' FAMILY='ipv6' FAMILY='ipv6' UUID='b5c83964-a6ff-0700-2306-000024000000' UUID='b5c83964-a6ff-0700-2306-000024000000' IPADDR='2a02:..../64' IPADDR='2a02:.../64' PREFIXLEN='64' PREFIXLEN='64' IPADDR_1='fd81:.../64' IPADDR_1='fd81:.../64' PREFIXLEN_1='64' PREFIXLEN_1='64' DNSSERVERS='2a02:9000::aaaa 2a02:9000::bbbb' < cer@Telcontar:~/tmp/Andrei/run-3/netconfig/eth0> So, version 3 doesn't have dns entries. version 4 gets them again: DNSSERVERS='2a02:9000::aaaa 2a02:9000::bbbb' Version 5 is identical (in those two files). Version 5 has resolv.conf: search valinor nameserver 127.0.0.1 nameserver ::1 while version 4 has: search valinor nameserver 127.0.0.1 nameserver ::1 nameserver 2a02:9000::aaaa If you want the zip files to inspect them yourself, just ask. Well, whatever the cause, I can not use the automatically generated dynamic resolv.conf file. If you think there is something I can tell the ISP, I will, but they will probably say nothing back. - -- Cheers, ~ Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZFqdvxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVWfQAn1SGPlTIJgPMB7E+FO0r GeiU3AViAJ9jMBo3jcE8yWN9ejpt0ZHagBSfzw== =O3Ic -----END PGP SIGNATURE-----
On Tue, May 9, 2023 at 10:24 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
If you want the zip files to inspect them yourself, just ask.
No, I do not think they will add anything. The only hypothesis I have is - wicked expires RDNSS entries after 30 seconds and then adds back with the next RA. Looking at code, it seems to update the expiration timer when RA is received so it may be a bug (the fact that it is irregular also hints that it is probably not intentional). Wicked debug log may give some hints. You may consider a bug report.
On 2023-05-10 10:07, Andrei Borzenkov wrote:
On Tue, May 9, 2023 at 10:24 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
If you want the zip files to inspect them yourself, just ask.
No, I do not think they will add anything. The only hypothesis I have is - wicked expires RDNSS entries after 30 seconds and then adds back with the next RA. Looking at code, it seems to update the expiration timer when RA is received so it may be a bug (the fact that it is irregular also hints that it is probably not intentional). Wicked debug log may give some hints.
You may consider a bug report.
Ok, will do. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Thus, I can not use NETCONFIG_DNS_POLICY="auto".
Thus you have concluded wrongly. Using 'auto' does what is expected, it updates your /etc/resolv.conf when the information changes.
As I suggested in my first reply this morning "Sounds like a lease being renewed.".
But why every minute or so?
When the "renewal" time of <something> is reduced, it is usually for debugging purposes. To quickly repeat whichever issue it is, instead of having to wait for the next renewal in 24 hours or a week.
No idea now how to find out.
Old fashioned debugging. Follow the logic and look for when it breaks.
If a lease is being renewed, it is because it has expired. When it expires very quickly, that suggests it was issued with a very short lifetime. You ought to be able to see that in the log, I posted some typical messages earlier today. I get those on TW and leap15.5, but not on leap15.3 - maybe it is a wicked option that needs tweaking.
But those messages, if they are the ones I remember, do not happen in my machine.
If you are running wicked, they should.
What about /run/dnsmasq-forwarders.conf ?
The Beta machine doesn't have dnsmasq.
So install it. That's what I did earlier, to test.
It would be easier to boot the Laicolasse partition, but that would break another unrelated test that I'm doing.
What can be easier than "zypper in dnsmasq" ?
I try to keep the Beta partition simple. Configuring dnsmasq would be a further complication.
I did not say "configure it", I said _install_ it. When you are done debugging, maybe you could just delete it again. -- Per Jessen, Zürich (16.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 23:24, Per Jessen wrote:
Carlos E. R. wrote:
Thus, I can not use NETCONFIG_DNS_POLICY="auto".
Thus you have concluded wrongly. Using 'auto' does what is expected, it updates your /etc/resolv.conf when the information changes.
But I don't want it to contain that information. I need /etc/resolv.conf to point only at my local or LAN DNS servers, not the remote ones. It is static information. Ie: 127.0.0.1 Only that line is required. Maybe add "::1" now. AND, I can not use a file that changes every minute, even if I wanted what it contains! I have to use a hack, write my own file, and use that one instead, with the same contents. Or what I do, which is write "server=..." lines in dnsmasq.conf
As I suggested in my first reply this morning "Sounds like a lease being renewed.".
But why every minute or so?
When the "renewal" time of <something> is reduced, it is usually for debugging purposes. To quickly repeat whichever issue it is, instead of having to wait for the next renewal in 24 hours or a week.
Not my doing... Maybe the ISP has done that. It is their router.
No idea now how to find out.
Old fashioned debugging. Follow the logic and look for when it breaks.
If a lease is being renewed, it is because it has expired. When it expires very quickly, that suggests it was issued with a very short lifetime. You ought to be able to see that in the log, I posted some typical messages earlier today. I get those on TW and leap15.5, but not on leap15.3 - maybe it is a wicked option that needs tweaking.
But those messages, if they are the ones I remember, do not happen in my machine.
If you are running wicked, they should.
Tell me what string to search for, and I will. I have not found them. In the previous message in the thread I posted the TWO messages from wicked. Only two messages today. Ok, yesterday now.
What about /run/dnsmasq-forwarders.conf ?
The Beta machine doesn't have dnsmasq.
So install it. That's what I did earlier, to test.
It would be easier to boot the Laicolasse partition, but that would break another unrelated test that I'm doing.
What can be easier than "zypper in dnsmasq" ?
And configure a few files. No, thanks. I want that machine simple.
I try to keep the Beta partition simple. Configuring dnsmasq would be a further complication.
I did not say "configure it", I said _install_ it. When you are done debugging, maybe you could just delete it again.
It has to be configured or it will not work. If you insist, I will reboot the laptop to the "stable" partition that has dnsmasq. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-08 23:24, Per Jessen wrote:
Carlos E. R. wrote:
Thus, I can not use NETCONFIG_DNS_POLICY="auto".
Thus you have concluded wrongly. Using 'auto' does what is expected, it updates your /etc/resolv.conf when the information changes.
But I don't want it to contain that information.
Here the pertinent question is probably - why not?
I need /etc/resolv.conf to point only at my local or LAN DNS servers, not the remote ones.
Why?
AND, I can not use a file that changes every minute, even if I wanted what it contains!
Well, although it is of course too much, it would still work.
But those messages, if they are the ones I remember, do not happen in my machine.
If you are running wicked, they should.
Tell me what string to search for, and I will.
Ummm, "wicked" :-) https://paste.opensuse.org/pastes/f5714a73b9ca Of course, maybe the difference is that I am running dhcpv6, I don't really know.
What about /run/dnsmasq-forwarders.conf ?
The Beta machine doesn't have dnsmasq.
So install it. That's what I did earlier, to test.
It would be easier to boot the Laicolasse partition, but that would break another unrelated test that I'm doing.
What can be easier than "zypper in dnsmasq" ?
And configure a few files. No, thanks. I want that machine simple.
I try to keep the Beta partition simple. Configuring dnsmasq would be a further complication.
I did not say "configure it", I said _install_ it. When you are done debugging, maybe you could just delete it again.
It has to be configured or it will not work.
I have to wonder, when you always know better, why do you ask here? -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 08.05.2023 16:32, Carlos E. R. wrote:
The telefónica DNS servers are missing.
It should have:
192.168.1.1 or 80.58.61.250, server=80.58.61.254
No, it should not. You told netconfig to use STATIC policy so why the hell do you expect it to put there dynamic information from your DHCP server? The whole endless threads long became ridiculous. You are not looking for help to understand how to configure your systems, you are looking for someone to manage your systems for you so you do not need to understand the tools used on these systems.
Another machine (Beta) that runs NM, has the correct information:
cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf # Generated by NetworkManager
How is it relevant to what netconfig is doing? If you are satisfied with how NetworkManager happened to work in your case, use NetworkManager. Why are you asking questions about wicked?
On 2023-05-08 16:03, Andrei Borzenkov wrote:
On 08.05.2023 16:32, Carlos E. R. wrote:
The telefónica DNS servers are missing.
It should have:
192.168.1.1 or 80.58.61.250, server=80.58.61.254
No, it should not. You told netconfig to use STATIC policy so why the hell do you expect it to put there dynamic information from your DHCP server?
The whole endless threads long became ridiculous. You are not looking for help to understand how to configure your systems, you are looking for someone to manage your systems for you so you do not need to understand the tools used on these systems.
Another machine (Beta) that runs NM, has the correct information: > cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf # Generated by NetworkManager
How is it relevant to what netconfig is doing? If you are satisfied with how NetworkManager happened to work in your case, use NetworkManager. Why are you asking questions about wicked?
Not going to answer with that tone of yours :-/ -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [05-08-23 14:21]:
On 2023-05-08 16:03, Andrei Borzenkov wrote:
On 08.05.2023 16:32, Carlos E. R. wrote:
The telefónica DNS servers are missing.
It should have:
192.168.1.1 or 80.58.61.250, server=80.58.61.254
No, it should not. You told netconfig to use STATIC policy so why the hell do you expect it to put there dynamic information from your DHCP server?
The whole endless threads long became ridiculous. You are not looking for help to understand how to configure your systems, you are looking for someone to manage your systems for you so you do not need to understand the tools used on these systems.
Another machine (Beta) that runs NM, has the correct information: > cer@Beta:~> cat /run/NetworkManager/no-stub-resolv.conf # Generated by NetworkManager
How is it relevant to what netconfig is doing? If you are satisfied with how NetworkManager happened to work in your case, use NetworkManager. Why are you asking questions about wicked?
Not going to answer with that tone of yours :-/
ever heard of private mail? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-05-08 03:40, Carlos E. R. wrote:
Telcontar:
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #resolv-file=
Ok, I have to change that one. To what, using wicked?
YaST, Network configuration --> Hostname/DNS and change "Modify DNS configuration" to manually.
On 2023-05-08 22:54, Darryl Gregorash wrote:
On 2023-05-08 03:40, Carlos E. R. wrote:
Telcontar:
# Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf #resolv-file=
Ok, I have to change that one. To what, using wicked?
YaST, Network configuration --> Hostname/DNS and change "Modify DNS configuration" to manually.
Er... No, it is a file name that has to be written there. If using NM, the file should be (even when using NETCONFIG_DNS_POLICY='STATIC', can not verify this moment (the machine where I found this out is not running this instant)): resolv-file=/run/NetworkManager/no-stub-resolv.conf In the case of wicked, I have found no equivalent file. Candidates: /run/dnsmasq-forwarders.conf Telcontar:~ # egrep -v "^[[:space:]]*$|^#" /run/dnsmasq-forwarders.conf nameserver 192.168.1.16 Telcontar:~ # /run/netconfig/resolv.conf Telcontar:~ # egrep -v "^[[:space:]]*$|^#" /run/netconfig/resolv.conf search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 Telcontar:~ # /run/wicked/leaseinfo.eth0.auto.ipv6 different format, not usable. The goal is to have a "static" resolv.conf file containing: search valinor nameserver 127.0.0.1 nameserver 192.168.1.16 And a forwarder file (dynamic) that contains: nameserver 80.58.61.250 nameserver 80.58.61.254 nameserver 2a02:9000::aaaa nameserver 2a02:9000::bbbb I have not found that forwarder file that I want, but I have written by hand equivalent entries in "/etc/dnsmasq.conf", so I can consider the issue solved. The remaining issue is to find the root cause of having the "/run/wicked/leaseinfo.eth0.auto.ipv6" being updated more or less every minute. On two computers. The theory is that the culprit is the router, but so far I have not found evidence of that. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Why is this reloading and spamming the logs hapening, out of the blue? I'm certainly not changing /etc/resolv.conf. But something is:
Sounds like a lease being renewed. For a more educated guess, like Andrei said, it would be good to know which network manager you're using. If a lease is being renewed, you _might_ also find indications in the log. This is from my TW system "office24" : 2023-05-07T00:57:07+02:00 office24 wickedd-dhcp6[656]: eth0: Committing DHCPv6 lease with: 2023-05-07T00:57:07+02:00 office24 wickedd-dhcp6[656]: eth0 +ia-na.address 2001:db8:4c68:1:ff99::95ba/0, pref-lft 43200, valid-lft 86400 2023-05-07T01:57:07+02:00 office24 wickedd-dhcp6[656]: eth0: Committing DHCPv6 lease with: 2023-05-07T01:57:07+02:00 office24 wickedd-dhcp6[656]: eth0 +ia-na.address 2001:db8:4c68:1:ff99::95ba/0, pref-lft 43200, valid-lft 86400 2023-05-07T02:57:07+02:00 office24 wickedd-dhcp6[656]: eth0: Committing DHCPv6 lease with: 2023-05-07T02:57:07+02:00 office24 wickedd-dhcp6[656]: eth0 +ia-na.address 2001:db8:4c68:1:ff99::95ba/0, pref-lft 43200, valid-lft 86400 2023-05-07T10:52:10+02:00 office24 wickedd-dhcp4[643]: eth0: Committed DHCPv4 lease with address 192.168.3.24 (lease time 86400, renew in 43200 sec, rebind in 75600 sec) 2023-05-07T22:52:10+02:00 office24 wickedd-dhcp4[643]: eth0: Committed DHCPv4 lease with address 192.168.3.24 (lease time 86400, renew in 43200 sec, rebind in 75600 sec) This doesn't actually cause /run/netconfig/resolv.conf to be updated, but maybe it does on yours. -- Per Jessen, Zürich (15.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 10:27, Per Jessen wrote:
Carlos E. R. wrote:
Why is this reloading and spamming the logs hapening, out of the blue? I'm certainly not changing /etc/resolv.conf. But something is:
Sounds like a lease being renewed. For a more educated guess, like Andrei said, it would be good to know which network manager you're using. If a lease is being renewed, you _might_ also find indications in the log.
This is from my TW system "office24" :
2023-05-07T00:57:07+02:00 office24 wickedd-dhcp6[656]: eth0: Committing DHCPv6 lease with: 2023-05-07T00:57:07+02:00 office24 wickedd-dhcp6[656]: eth0 +ia-na.address 2001:db8:4c68:1:ff99::95ba/0, pref-lft 43200, valid-lft 86400 2023-05-07T01:57:07+02:00 office24 wickedd-dhcp6[656]: eth0: Committing DHCPv6 lease with: 2023-05-07T01:57:07+02:00 office24 wickedd-dhcp6[656]: eth0 +ia-na.address 2001:db8:4c68:1:ff99::95ba/0, pref-lft 43200, valid-lft 86400 2023-05-07T02:57:07+02:00 office24 wickedd-dhcp6[656]: eth0: Committing DHCPv6 lease with: 2023-05-07T02:57:07+02:00 office24 wickedd-dhcp6[656]: eth0 +ia-na.address 2001:db8:4c68:1:ff99::95ba/0, pref-lft 43200, valid-lft 86400
2023-05-07T10:52:10+02:00 office24 wickedd-dhcp4[643]: eth0: Committed DHCPv4 lease with address 192.168.3.24 (lease time 86400, renew in 43200 sec, rebind in 75600 sec) 2023-05-07T22:52:10+02:00 office24 wickedd-dhcp4[643]: eth0: Committed DHCPv4 lease with address 192.168.3.24 (lease time 86400, renew in 43200 sec, rebind in 75600 sec)
This doesn't actually cause /run/netconfig/resolv.conf to be updated, but maybe it does on yours.
Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ # It is using wicked and fixed address, but IPv6 comes via dhcp or whatever. I don't see in syslog or journal messages about the lease.
Telcontar:~ # journalctl -b | grep DHCPv6 Apr 14 23:42:13 Telcontar systemd[1]: Starting wicked DHCPv6 supplicant service... Apr 14 23:42:13 Telcontar systemd[1]: Started wicked DHCPv6 supplicant service. Apr 14 23:42:18 Telcontar dnsmasq[2219]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile May 08 04:17:58 Telcontar dnsmasq[23788]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Telcontar:~ #
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ #
It is using wicked and fixed address, but IPv6 comes via dhcp or whatever.
SLAAC - seeing as that IPV6 nameserver is the only non-static entry in your resolv.conf, I'll venture a guess and say your IPv6 config is being updated or renewed, which causes your resolv.conf to be updated too. -- Per Jessen, Zürich (19.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-08 11:28, Per Jessen wrote:
Carlos E. R. wrote:
Telcontar:~ # cat /etc/resolv.conf ... nameserver 127.0.0.1 nameserver 192.168.1.16 nameserver 2a02:9000::aaaa Telcontar:~ #
It is using wicked and fixed address, but IPv6 comes via dhcp or whatever.
SLAAC - seeing as that IPV6 nameserver is the only non-static entry in your resolv.conf, I'll venture a guess and say your IPv6 config is being updated or renewed, which causes your resolv.conf to be updated too.
cer@Telcontar:~> journalctl -b | grep -i SLAAC cer@Telcontar:~> The router does DHCPv6 and RADVD. There is also MLD Snooping -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
Darryl Gregorash -
Patrick Shanahan -
Per Jessen