As the configuration of the hosts is identical I assumed that. But it’s a good idea to check resolv.conf. Both have:
**erlangen:~ #** ll /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Nov 25 20:56 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
**erlangen:~ #** cat /etc/resolv.conf
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.178.1
nameserver fd00::xxxx:xxxx:xxxx:xxxx
search fritz.box
**erlangen:~ #**
I even powered off host erlangen and removed it from the 7490, but to no avail:
**erlangen:~ #** journalctl -b -u systemd-networkd -u systemd-resolved.service --no-pager
Nov 27 06:47:04 erlangen systemd[1]: Starting Network Configuration...
Nov 27 06:47:04 erlangen systemd-networkd[657]: lo: Link UP
Nov 27 06:47:04 erlangen systemd-networkd[657]: lo: Gained carrier
Nov 27 06:47:04 erlangen systemd-networkd[657]: Enumeration completed
Nov 27 06:47:04 erlangen systemd[1]: Started Network Configuration.
Nov 27 06:47:05 erlangen systemd-networkd[657]: eth0: Interface name change detected, renamed to enp42s0.
Nov 27 06:47:05 erlangen systemd-networkd[657]: enp42s0: Configuring with /etc/systemd/network/wired.network.
Nov 27 06:47:05 erlangen systemd-networkd[657]: enp42s0: Link UP
Nov 27 06:47:06 erlangen systemd[1]: Starting Network Name Resolution...
Nov 27 06:47:06 erlangen systemd-resolved[909]: Positive Trust Anchors:
Nov 27 06:47:06 erlangen systemd-resolved[909]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Nov 27 06:47:06 erlangen systemd-resolved[909]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Nov 27 06:47:06 erlangen systemd-resolved[909]: Using system hostname 'erlangen'.
Nov 27 06:47:06 erlangen systemd[1]: Started Network Name Resolution.
Nov 27 06:47:08 erlangen systemd-networkd[657]: enp42s0: Gained carrier
Nov 27 06:47:10 erlangen systemd-networkd[657]: enp42s0: Gained IPv6LL
Nov 27 06:47:12 erlangen systemd-networkd[657]: enp42s0: DHCPv4 address 192.168.178.20/24, gateway 192.168.178.1 acquired from 192.168.178.1
**erlangen:~ #**
**erlangen:~ #** tracepath -4 erlangen
1: erlangen.fritz.box 0.037ms reached
Resume: pmtu 65535 hops 1 back 1
**erlangen:~ #** tracepath -6 erlangen
tracepath: erlangen: No address associated with hostname
**erlangen:~ #**
**@karlmistelberger:
**
Here with a 1&1 AVM FRITZ!Box 7490 and FRITZ!OS: 07.29:
# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether ??:??:??:??:??:?? brd ff:ff:ff:ff:ff:ff
altname enp5s0
inet 192.168.178.48/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:???:????:????:????:???:????:????/64 scope global temporary dynamic
valid_lft 6684sec preferred_lft 3084sec
inet6 2001:???:????:????:???:????:????:????/64 scope global dynamic mngtmpaddr
valid_lft 6684sec preferred_lft 3084sec
inet6 fe80::???:????:????:????/64 scope link
valid_lft forever preferred_lft forever
#
When using “traceroute” & Co. it helps to use the fully qualified host name – for the case of the current FRITZ!Box routers, the LAN domain name is “fritz.box” –
# traceroute6 xxx.fritz.box
traceroute to xxx.fritz.box (2001:???:????:????:???:????:????:????), 30 hops max, 80 byte packets
1 xxx.fritz.box (2001:???:????:????:???:????:????:????) 0.081 ms 0.024 ms 0.022 ms
#
In ‘/etc/sysconfig/network/dhcp’ the only thing I’ve changed is:
For “traceroute” I’ve now noticed that, in some cases the “traceroute6” fails for specific devices despite the FRITZ!Box indicating that, they’ve been assigned an IPv6 address –
The IPv4 “traceroute” however, works just fine.
And, often, “traceroute” can determine the “hostname” is in fact “hostname.fritz.box” …
**6700K:~ #** networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback **carrier ** unmanaged
2 enp0s31f6 ether **routable ****configured**
3 wlp3s0 wlan **routable ** unmanaged
3 links listed.
**6700K:~ #** networkctl status
**●** State: **routable **
Online state: **online **
Address: 192.168.178.20 on enp0s31f6
192.168.178.23 on wlp3s0
2001:............................ on enp0s31f6
2001:............................ on wlp3s0
fe80:............................ on enp0s31f6
fe80:............................ on wlp3s0
Gateway: 192.168.178.1 on enp0s31f6
192.168.178.1 on wlp3s0
fe80:.................. on enp0s31f6
DNS: 192.168.178.1
Search Domains: fritz.box
NTP: 192.168.178.1
Nov 30 06:34:39 6700K systemd-networkd[2637]: enp0s31f6: Gained IPv6LL
Nov 30 06:34:39 6700K systemd-networkd[2637]: Enumeration completed
Nov 30 06:34:39 6700K systemd[1]: Started Network Configuration.
Nov 30 06:34:39 6700K systemd-networkd[2637]: enp0s31f6: Configuring with /etc/systemd/network/ether.network.
Nov 30 06:34:40 6700K systemd-networkd[2637]: enp0s31f6: DHCPv4 address 192.168.178.20/24, gateway 192.168.178.1 acquired from 192.168.178.1
Nov 30 06:41:39 6700K systemd-networkd[2637]: enp0s31f6: Lost carrier
Nov 30 06:41:39 6700K systemd-networkd[2637]: enp0s31f6: DHCP lease lost
Nov 30 06:41:39 6700K systemd-networkd[2637]: enp0s31f6: DHCPv6 lease lost
Nov 30 06:42:00 6700K systemd-networkd[2637]: enp0s31f6: Gained carrier
Nov 30 06:42:06 6700K systemd-networkd[2637]: enp0s31f6: DHCPv4 address 192.168.178.20/24, gateway 192.168.178.1 acquired from 192.168.178.1
**6700K:~ #** systemd-resolve 6700k
6700k: **2001:..............................**-- link: enp0s31f6
**192.168.178.23**-- link: enp0s31f6
**192.168.178.20**-- link: enp0s31f6
(6700k.fritz.box)
-- Information acquired via protocol DNS in 2.1ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
**6700K:~ #**
DNS of 6700k works as expected.
**erlangen:~ #** networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback **carrier ** unmanaged
2 enp42s0 ether **routable ****configured**
2 links listed.
**erlangen:~ #** networkctl status
**●** State: **routable **
Online state: **online **
Address: 192.168.178.24 on enp42s0
2001:............................ on enp42s0
fe80:............................ on enp42s0
Gateway: 192.168.178.1 on enp42s0
fe80:............................. on enp42s0
DNS: 192.168.178.1
NTP: 192.168.178.1
Nov 30 06:58:02 erlangen systemd-networkd[656]: lo: Link UP
Nov 30 06:58:02 erlangen systemd-networkd[656]: lo: Gained carrier
Nov 30 06:58:02 erlangen systemd-networkd[656]: Enumeration completed
Nov 30 06:58:02 erlangen systemd[1]: Started Network Configuration.
Nov 30 06:58:03 erlangen systemd-networkd[656]: eth0: Interface name change detected, renamed to enp42s0.
Nov 30 06:58:03 erlangen systemd-networkd[656]: enp42s0: Configuring with /etc/systemd/network/wired.network.
Nov 30 06:58:03 erlangen systemd-networkd[656]: enp42s0: Link UP
Nov 30 06:58:06 erlangen systemd-networkd[656]: enp42s0: Gained carrier
Nov 30 06:58:08 erlangen systemd-networkd[656]: enp42s0: Gained IPv6LL
Nov 30 06:58:11 erlangen systemd-networkd[656]: enp42s0: DHCPv4 address 192.168.178.24/24, gateway 192.168.178.1 acquired from 192.168.178.1
**erlangen:~ #** systemd-resolve erlangen
erlangen: **192.168.178.24**-- link: enp42s0
**2001:........................**-- link: enp42s0
**fe80:........................**-- link: enp42s0
-- Information acquired via protocol DNS in 920us.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: yes
** -- Data from: synthetic**
**erlangen:~ #**
I have no clue what “Data from: synthetic” refers to.
Ipv6 of erlangen works: ping6 2001:… succeeds.
DNS of erlangen fails:
**erlangen:~ #** ping6 erlangen
ping6: erlangen: Address family for hostname not supported
**erlangen:~ #**
Found Domains= was missing. Added the line and restarted to no avail:
**erlangen:~ #** systemd-resolve erlangen
erlangen: **192.168.178.24**-- link: enp42s0
(erlangen.fritz.box)
-- Information acquired via protocol DNS in 3.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
**erlangen:~ #** ping6 erlangen
ping6: erlangen: Address family for hostname not supported
**erlangen:~ #**
Accessed erlangen from 6700k using “ssh 2001:…” and tinkered with /etc/systemd/network/wired.network. Undid the changes by restoring the saved file. Restarted systemd-networkd.service. ssh would hang, but:
**erlangen:~ #** ping6 -c1 erlangen
PING erlangen(erlangen.fritz.box (2001:.......................) 56 data bytes
64 bytes from erlangen.fritz.box (2001:.......................): icmp_seq=1 ttl=64 time=0.018 ms
--- erlangen ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.018/0.018/0.018/0.000 ms
**erlangen:~ #**
**erlangen:~ #** systemd-resolve erlangen
erlangen: 2001:.......................-- link: enp42s0
**192.168.178.25**-- link: enp42s0
(erlangen.fritz.box)
-- Information acquired via protocol DNS in 914us.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: cache
**erlangen:~ #**
Had a closer look at Fedora. Booting into it caused DNS issues in the past. Found /etc/resolv.conf linked to /run/systemd/resolve/stub-resolv.conf. Replacing it by a link to /run/systemd/resolve/resolv.conf caused the Fritz!Box to reuse the address leased to Fedora when booting into another system. Obviously stub-resolv confused the DNS of Fritz!Box.
Host fedora (Fedora 36 + NetworkManager + systemd-resolved) also works as smooth as Tumbleweed.
I can repeatedly boot into any of the systems, no matter what permutation of the hosts. The Fritz!Box leases and releases the addresses of the hosts as expected and without further ado. Ping times are down to a minimum.
The point is, with an AVM FRITZ!Box it usually pays to force a static DNS Server address pointing to the FRITZ!Box – the thing is after all, the connection to the ISP and further into the Internet.
If, via DHCP, another DNS Server is present on the private LAN/WLAN being served by the FRITZ!Box, DNS confusion may well occur for a variety of obscure reasons …
The above tinkering with the 7490 made me compare the price–performance ratio to a new 7530 AX. I RMAed the refurbished 7490 and bought a new 7530 AX.
I used the time and cleaned up the menu “Fritz!Box 7360 > Home Network > Network”. Without holding hands, chaos breaks out. I checked if after switching off the devices they move from “Active connections” to “Unused connections”. Furthermore, I checked if they can actually be removed and if there is an automatic connection when they are switched on. This was not always the case in the past.
The two desktops with the 6700K and the 5600X have corresponding individual fixed hostnames and flexible addresses depending on the operating system booted into. Permanently connected devices like smart TV, radio, printer and others have fixed addresses. For the Linux systems with NetworkManager I checked that they also use resolv.conf and not stub-resolv.conf.
The 7360 does fine with this configuration. I don’t bet an Euro on the 7530. Maybe she can think of something new.
I saved the settings of the 7360 and restored in the 7530 AX, which arrived two hours ago. Everything is fine now for the time being.
