[solved] cannot resolve hostname of one host in LAN

weltio · 2020-10-08 07:34:05

I cannot resolve the hostname (say: MACHINE1) of one of my machines in lan.

After connecting via ssh (over ip address) and restarting avahi-daemon.service it works again.

Why is that? (I have not tested whether it is enough to connect via ssh without restarting avahi)

That doesnt seem to be intended.

The resolution problem exists on all other machines in the network and only if they want to resolve MACHINE1.

Last edited by weltio (2020-11-05 18:33:08)

seth · 2020-10-08 08:04:36

Can you resolve MACHINE1.local ?
Conflict w/ systemd-resolved, https://wiki.archlinux.org/index.php/Avahi#Installation ?
https://wiki.archlinux.org/index.php/Av … ng_numbers ?

weltio · 2020-10-13 08:44:38

weltio wrote:

(I have not tested whether it is enough to connect via ssh without restarting avahi)

Now I tested and it is not enough. Avahi restart is mandatory

seth wrote:

Can you resolve MACHINE1.local ?

no

seth wrote:

Conflict w/ systemd-resolved, https://wiki.archlinux.org/index.php/Avahi#Installation ?

Mhm, that probably means that systemd-resolvd would work out of the box? It seems that it didnt which was the reason for installing avahi...
I removed avahi and started and enabled systemd-resolvd.
For now, it works - as it would have with an avahi restart.
I will test further.
Thanks for the hint!

seth wrote:

https://wiki.archlinux.org/index.php/Av … ng_numbers ?

I dont think that this is an issue (some time ago it had been working for several years without any problems )

weltio · 2020-10-20 08:21:15

weltio wrote:

Mhm, that probably means that systemd-resolvd would work out of the box? It seems that it didnt which was the reason for installing avahi...
I removed avahi and started and enabled systemd-resolvd.
For now, it works - as it would have with an avahi restart.
I will test further.
Thanks for the hint!

It doesn't work... (just came back from suspend and could not resolve the hostname)
Systemd-resolvd is running

dig MACHINE1 +short
dig MACHINE1.local +short
;; Warning: Client COOKIE mismatch

Any idea on that?

after restarting systemd-resolvd I can resolve again:

dig MACHINE1.local +short
;; Warning: Client COOKIE mismatch
dig MACHINE1 +short      
192.168.1.50

Last edited by weltio (2020-10-28 10:58:10)

seth · 2020-10-20 11:22:05

https://wiki.archlinux.org/index.php/Sy … cal_domain
What does "resolvectl status" say in either situation?

weltio · 2020-10-23 09:28:06

seth wrote:

https://wiki.archlinux.org/index.php/Sy … cal_domain
What does "resolvectl status" say in either situation?

In both cases:

resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

I added:

cat /etc/NetworkManager/conf.d/no-systemd-resolved.conf
[main]
systemd-resolved=false

and restartet NetworkManager but it didnt have an effect

It seems odd that I can resolve other hostnames without problems - e.g. MACHINE2 (which is running NetworkManager too - in contrast to MACHINE1)

Last edited by weltio (2020-10-23 09:34:06)

seth · 2020-10-23 14:11:11

Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

But resolved was supposed to be used here (and perhaps did work before a suspend)?

dbus-send --print-reply --dest=org.freedesktop.DBus  /org/freedesktop/DBus org.freedesktop.DBus.ListNames
echo $DBUS_SESSION_BUS_ADDRESS
loginctl session-status

Is the S3 trigger reproducible/reliable?

weltio · 2020-10-24 08:37:53

seth wrote:
Is the S3 trigger reproducible/reliable?
Indeed I use S3 but the problem probably occurs right after boot too. However I will test that soon again.

At least today it occured again - after S3; but that is not reliable. I would not even see a connection at this point of time

Last edited by weltio (2020-10-28 11:15:24)

seth · 2020-10-24 08:41:11

The host (where you hopefully tested resolvectl status)
If resolved is supposed to be used but cannot be contacted, that can explain why the resolution fails (or be just another symptom, but if restarting resolved "fixes" it, it's rather the cause)

weltio · 2020-10-24 09:18:35

seth wrote:

The host (where you hopefully tested resolvectl status)
If resolved is supposed to be used but cannot be contacted, that can explain why the resolution fails (or be just another symptom, but if restarting resolved "fixes" it, it's rather the cause)

Well, if "the host" means MACHINE1 (the not resolvable machine)
then the output of resolvectl is different:

resolvectl status
Global
       LLMNR setting: yes                 
MulticastDNS setting: yes                 
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
  Current DNS Server: 192.168.1.1       
         DNS Servers: 192.168.1.1       
Fallback DNS Servers: 1.1.1.1             
                      9.9.9.10            
                      8.8.8.8             
                      2606:4700:4700::1111
                      2620:fe::10         
                      2001:4860:4860::8888
          DNS Domain: peter.box           

Link 2 (eno1)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: no                   
       LLMNR setting: yes                  
MulticastDNS setting: no                   
  DNSOverTLS setting: no                   
      DNSSEC setting: no                   
    DNSSEC supported: no

MACHINE2's output is as described. But MACHINE2 is resolvable...

I actually thought the resolving part would be the router which is responsible for dns...

dig MACHINE1 @peter.box +short
192.168.1.100
# works only after restart of resolved on MACHINE1

seth · 2020-10-24 09:37:32

No, meant the system where you fail to resolve MACHINE1 from.
The resolution starts on the local system and invokes several mechanisms, dns bein one f them but not for avahi name resolution.

weltio · 2020-10-25 16:00:34

seth wrote:

Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
But resolved was supposed to be used here (and perhaps did work before a suspend)?
dbus-send --print-reply --dest=org.freedesktop.DBus  /org/freedesktop/DBus org.freedesktop.DBus.ListNames
echo $DBUS_SESSION_BUS_ADDRESS
loginctl session-status
Is the S3 trigger reproducible/reliable?

method return time=1603641121.098024 sender=org.freedesktop.DBus -> destination=:1.865 serial=3 reply_serial=2
   array [
      string "org.freedesktop.DBus"
      string "org.freedesktop.Notifications"
      string "org.kde.klipper"
      string "org.pulseaudio.Server"
      string ":1.82"
      string "org.kde.kalarm"
      string ":1.84"
      string "org.kde.GtkConfig"
      string "org.kde.DiscoverNotifier"
      string "org.kde.kmail2"
      string "org.kde.StatusNotifierHost-828"
      string "org.kde.plasmanetworkmanagement"
      string "local.org_kde_powerdevil"
      string ":1.816"
      string "org.kde.kglobalaccel"
      string "org.kde.keyboard"
      string ":1.10"
      string ":1.11"
      string ":1.12"
      string ":1.13"
      string ":1.0"
      string ":1.14"
      string ":1.15"
      string ":1.2"
      string ":1.16"
      string ":1.17"
      string "org.kde.Solid.PowerManagement.PolicyAgent"
      string ":1.19"
      string ":1.6"
      string "org.freedesktop.PowerManagement"
      string ":1.8"
      string ":1.9"
      string "org.kio5.kio_http_cache_cleaner"
      string ":1.20"
      string ":1.22"
      string ":1.25"
      string ":1.26"
      string ":1.28"
      string ":1.29"
      string "ca.desrt.dconf"
      string "org.kde.plasmashell"
      string "local.kleopatra"
      string "com.canonical.Unity"
      string ":1.30"
      string ":1.31"
      string ":1.32"
      string "org.kde.kuiserver"
      string ":1.33"
      string ":1.34"
      string ":1.35"
      string ":1.37"
      string ":1.38"
      string ":1.323"
      string ":1.39"
      string "org.gnome.zeitgeist.SimpleIndexer"
      string ":1.324"
      string "org.freedesktop.Telepathy.Client.Zeitgeist"
      string ":1.325"
      string "org.kde.kwalletmanager5"
      string ":1.326"
      string "org.kde.kappmenu"
      string ":1.327"
      string ":1.328"
      string ":1.329"
      string "org.freedesktop.systemd1"
      string ":1.41"
      string "org.a11y.Bus"
      string "org.kde.kscreen.osdService"
      string ":1.45"
      string ":1.46"
      string "org.freedesktop.PowerManagement.Inhibit"
      string ":1.330"
      string ":1.331"
      string ":1.332"
      string ":1.333"
      string ":1.334"
      string ":1.335"
      string "org.kde.kgpg"
      string ":1.336"
      string "org.kde.konsole-1029"
      string ":1.337"
      string "org.freedesktop.ScreenSaver"
      string ":1.338"
      string ":1.339"
      string "org.kde.kwalletd5"
      string "org.kde.kded5"
      string "org.kde.ActivityManager"
      string "org.gnome.zeitgeist.Engine"
      string ":1.52"
      string ":1.56"
      string ":1.340"
      string "org.kde.kdesvnd"
      string ":1.57"
      string ":1.341"
      string ":1.342"
      string ":1.59"
      string "org.gnome.zeitgeist.datahub"
      string ":1.343"
      string "org.kde.ksmserver"
      string ":1.344"
      string "org.kde.kcookiejar5"
      string ":1.345"
      string ":1.346"
      string ":1.347"
      string ":1.865"
      string ":1.348"
      string ":1.349"
      string "org.kde.kaccess"
      string "org.kde.konversation"
      string "org.kde.korgac"
      string "org.kde.pim.TransportManager"
      string "org.kde.KScreen"
      string ":1.60"
      string ":1.61"
      string "org.kde.klauncher5"
      string ":1.65"
      string "org.kde.kmail"
      string ":1.350"
      string ":1.593"
      string ":1.351"
      string ":1.594"
      string "org.kde.konsole-1044"
      string "org.kde.Solid.PowerManagement"
      string ":1.352"
      string ":1.595"
      string ":1.353"
      string ":1.354"
      string ":1.355"
      string "org.kde.plasma.browser_integration"
      string ":1.114"
      string "org.kde.screensaver"
      string "org.kde.KWin"
      string ":1.356"
      string ":1.115"
      string ":1.357"
      string ":1.358"
      string ":1.117"
      string ":1.359"
      string "org.freedesktop.ReserveDevice1.Audio0"
      string ":1.119"
      string "org.PulseAudio1"
      string "org.kde.polkit-kde-authentication-agent-1"
      string ":1.360"
      string ":1.361"
      string ":1.120"
      string "org.kde.StatusNotifierWatcher"
      string ":1.362"
      string ":1.363"
      string "org.kde.JobViewServer"
   ]
unix:path=/run/user/1000/bus
2 - user (1000)
           Since: Fri 2020-10-23 09:51:14 CEST; 2 days ago
          Leader: 665 (sddm-helper)
            Seat: seat0; vc1
         Display: :0
         Service: sddm; type x11; class user
         Desktop: KDE
           State: active
            Unit: session-2.scope
                  ├─   665 /usr/lib/sddm/sddm-helper --socket /tmp/sddm-authe57de8bc-a6fa-4ed9-b3ff-9a16ca6b0082 --id 1 --start /usr/bin/startplasma-x11 --user user
                  ├─   680 /usr/bin/kwalletd5 --pam-login 7 3
                  ├─   681 /usr/bin/startplasma-x11
                  ├─   699 ssh-agent -s
                  ├─   714 /usr/lib/kf5/start_kdeinit
                  ├─   715 kdeinit5: Running...
                  ├─   717 /usr/lib/kf5/klauncher --fd=9
                  ├─   739 /usr/bin/kded5
                  ├─   743 /usr/bin/kwin_x11
                  ├─   784 /usr/bin/ksmserver
                  ├─   823 /usr/lib/polkit-kde-authentication-agent-1
                  ├─   828 /usr/bin/plasmashell
                  ├─   830 /usr/bin/kaccess
                  ├─   833 /usr/bin/xembedsniproxy
                  ├─   846 /usr/bin/gmenudbusmenuproxy
                  ├─   854 /usr/lib/DiscoverNotifier
                  ├─  2140 /usr/lib/geoclue-2.0/demos/agent
                  ├─  2147 /usr/lib/org_kde_powerdevil
                  ├─  2155 /usr/bin/zeitgeist-datahub
                  ├─  2234 /usr/lib/kf5/kio_http_cache_cleaner
                  ├─  3370 /usr/bin/kalarm --tray
                  ├─  3476 file.so [kdeinit5] file local:/run/user/1000/klauncherEVAbUX.1.slave-socket local:/run/user/1000/kded5BMlRHc.4.slave-socket
                  ├─  3477 file.so [kdeinit5] file local:/run/user/1000/klauncherEVAbUX.1.slave-socket local:/run/user/1000/kded5SDpdBb.5.slave-socket
                  ├─377535 file.so [kdeinit5] file local:/run/user/1000/klauncherEVAbUX.1.slave-socket local:/run/user/1000/plasmashellqETqhi.73.slave-socket


Okt 25 16:51:29 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046
Okt 25 16:51:33 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046
Okt 25 16:51:38 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046
Okt 25 16:51:43 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046
Okt 25 16:51:48 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046
Okt 25 16:51:53 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046
Okt 25 16:51:57 MACHINE0 plasmashell[828]: qml: is ready to reload - lastReloaded: 1603638691046

I just confirmed that even after resuming from s3 I can still resolve MACHINE1 from multiple hosts. The problem is triggered by something else than s3.

But I attached a raspberry and as assumed I could resolve its hostname by 'dig raspberrypi' out of the box

Last edited by weltio (2020-10-25 16:01:47)

seth · 2020-10-25 16:30:31

Re-reading the thread, the problem is resolved (the mdns/avahi responder) on MACHINE1 and #10 says

Link 2 (eno1)
…
MulticastDNS setting: no                   
…

Does that change when restarting resolved?
More importantly, is the NIC name (eno1) the same all the time (before it breaks, after it broke, after you restarted resolved)?

weltio · 2020-10-28 10:59:59

seth wrote:

Re-reading the thread, the problem is resolved (the mdns/avahi responder) on MACHINE1 and #10 says
Link 2 (eno1)
…
MulticastDNS setting: no                   
…
Does that change when restarting resolved?
More importantly, is the NIC name (eno1) the same all the time (before it breaks, after it broke, after you restarted resolved)?

No the output of resolvectl status is the same as before its restart

Last edited by weltio (2020-10-28 11:00:15)

weltio · 2020-10-28 11:13:32

seth wrote:

No, meant the system where you fail to resolve MACHINE1 from.
The resolution starts on the local system and invokes several mechanisms, dns bein one f them but not for avahi name resolution.

In a working case the router answers the 'dig MACHINE1'

#tcpdump udp port 53
IP 192.168.1.2.52612 > 192.168.1.1.53: 50709+ [1au] A? MACHINE1. (44)
IP 192.168.1.1.53 > 192.168.1.2.52612: 50709* 1/1/1 A 192.168.1.50 (76)

weltio · 2020-10-28 11:16:00

seth wrote:
Is the S3 trigger reproducible/reliable?
Indeed I use S3 but the problem probably occurs right after boot too. However I will test that soon again.

At least today it occured again - after S3; but that is not reliable. I would not even see a connection at this point of time

seth · 2020-10-28 13:27:41

But that's not avahi (port 5353)
The name is resolved via DNS, probably because the system announces the name with the dhcp request?

On "MACHINE1" stop and disable avahi, systemd-networkd, systemd-resolved, Networkmanager - everything network related.
Post the resulting output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

to be sure.

Then start the dhcpcd service to get an IP and see whether
a) you can still dig the domain
b) the issue remains

weltio · 2020-10-29 16:49:10

seth wrote:

On "MACHINE1" stop and disable avahi, systemd-networkd, systemd-resolved, Networkmanager - everything network related.
Post the resulting output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
to be sure.

That could be a bit of problem, since MACHINE1 is only reachable via ssh. So if I cut the connection, there would not be a way back into except reboot which I would like to circumvent if possible

seth · 2020-10-29 17:02:06

#!/bin/sh
systemctl stop avahi
systemctl stop systemd-networkd
systemctl stop systemd-resolved
# other possibly enabled services, check the find command to see what's enabled
sleep 10 # wait a bit to allow everything to go down
systemctl start dhcpcd # first make sure dhcpcd is actually installed ;-)
sleep 15m # 15 minutes to check the state of the system
systemctl stop dhcpcd
sleep 10 # wait a bit to allow everything to go down
systemctl start systemd-networkd # assuming that was your network service
# … whatever else you figure you need to re-start

Save the above as script, make it executable and nohup it a root?
Iff dhcpcd would fail, you'd (hopefully) bring the system back online after 15 minutes.
If not, you'll have to press the reset button :-(

weltio · 2020-11-04 19:13:44

seth wrote:

But that's not avahi (port 5353)
The name is resolved via DNS, probably because the system announces the name with the dhcp request?
On "MACHINE1" stop and disable avahi, systemd-networkd, systemd-resolved, Networkmanager - everything network related.
Post the resulting output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
to be sure.
Then start the dhcpcd service to get an IP and see whether
a) you can still dig the domain
b) the issue remains

systemctl stop systemd-networkd 
systemctl stop dhcpcd.service
sleep 10
systemctl start dhcpcd.service
sleep 10m
systemctl stop dhcpcd.service
sleep 10
systemctl start systemd-networkd

dig MACHINE1 not possible before, during or after the above commands.

dbus-org.freedesktop.resolve1.service    | system
dhcpcd.service                           | multi-user.target.wants
dirmngr.socket                           | sockets.target.wants
getty@tty1.service                       | getty.target.wants
gpg-agent-browser.socket                 | sockets.target.wants
gpg-agent-extra.socket                   | sockets.target.wants
gpg-agent.socket                         | sockets.target.wants
gpg-agent-ssh.socket                     | sockets.target.wants
nfs-server.service                       | multi-user.target.wants
openntpd.service                         | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
sshd.service                             | multi-user.target.wants
systemd-resolved.service                 | multi-user.target.wants

If I systemctl restart systemd-resolved MACHINE1 is diggable again (which is effectively a resolved restart )

seth · 2020-11-04 21:55:51

Can you monitor the traffic on MACHINE1 (beginning w/ the restart of resolved)?
It's just a random guess, but maybe the router gets the domain via AVAHI and exports it via DNS?

Edit: maybe restart only the router when the resolution fails?

Last edited by seth (2020-11-04 21:56:39)

weltio · 2020-11-05 09:37:22

seth wrote:

Can you monitor the traffic on MACHINE1 (beginning w/ the restart of resolved)?
It's just a random guess, but maybe the router gets the domain via AVAHI and exports it via DNS?

yes
what happens is (exactly as you described it - it seems):

# MACHINE1==192.168.1.50

192.168.1.50 > mcast standard LLMNR query MACHINE1
192.168.1.50 > mcast standard LLMNR query MACHINE1
192.168.1.50 > mcast standard LLMNR query MACHINE1
peter.box > mcast standard LLMNR query MACHINE1
192.168.1.50 > mcast standard LLMNR query response 192.168.1.50

What would be the "normal" behavior?

seth wrote:

Edit: maybe restart only the router when the resolution fails?

Tested that before, didnt work

btw. resolving fails immediately after:

systemctl stop systemd-resolved systemd-networkd dhcpcd.service 
# here ping works
systemctl start dhcpcd.service
# here it aint no more

Last edited by weltio (2020-11-05 09:50:35)

seth · 2020-11-05 13:23:11

If your router has DNS I'd skip mdns/avahi and rely on dhcp for DDNS, uncomment the "hostname" line in dhcpcd.conf (if you're using dhcpcd) to send the hostname w/ the dhcp lease request.

Edit: and stop resolved.

Last edited by seth (2020-11-05 13:23:32)

weltio · 2020-11-05 18:32:49

seth wrote:

If your router has DNS I'd skip mdns/avahi and rely on dhcp for DDNS, uncomment the "hostname" line in dhcpcd.conf (if you're using dhcpcd) to send the hostname w/ the dhcp lease request.
Edit: and stop resolved.

Well that was easy
Probably NetworkManager would do the same which is the reason for the other MACHINE* to be resolvable?!

Thank you very much

(Will report if it against expectation wont work again in the future)

Arch Linux

#1 2020-10-08 07:34:05

[solved] cannot resolve hostname of one host in LAN

#2 2020-10-08 08:04:36

Re: [solved] cannot resolve hostname of one host in LAN

#3 2020-10-13 08:44:38

Re: [solved] cannot resolve hostname of one host in LAN

#4 2020-10-20 08:21:15

Re: [solved] cannot resolve hostname of one host in LAN

#5 2020-10-20 11:22:05

Re: [solved] cannot resolve hostname of one host in LAN

#6 2020-10-23 09:28:06

Re: [solved] cannot resolve hostname of one host in LAN

#7 2020-10-23 14:11:11

Re: [solved] cannot resolve hostname of one host in LAN

#8 2020-10-24 08:37:53

Re: [solved] cannot resolve hostname of one host in LAN

#9 2020-10-24 08:41:11

Re: [solved] cannot resolve hostname of one host in LAN

#10 2020-10-24 09:18:35

Re: [solved] cannot resolve hostname of one host in LAN

#11 2020-10-24 09:37:32

Re: [solved] cannot resolve hostname of one host in LAN

#12 2020-10-25 16:00:34

Re: [solved] cannot resolve hostname of one host in LAN

#13 2020-10-25 16:30:31

Re: [solved] cannot resolve hostname of one host in LAN

#14 2020-10-28 10:59:59

Re: [solved] cannot resolve hostname of one host in LAN

#15 2020-10-28 11:13:32

Re: [solved] cannot resolve hostname of one host in LAN

#16 2020-10-28 11:16:00

Re: [solved] cannot resolve hostname of one host in LAN

#17 2020-10-28 13:27:41

Re: [solved] cannot resolve hostname of one host in LAN

#18 2020-10-29 16:49:10

Re: [solved] cannot resolve hostname of one host in LAN

#19 2020-10-29 17:02:06

Re: [solved] cannot resolve hostname of one host in LAN

#20 2020-11-04 19:13:44

Re: [solved] cannot resolve hostname of one host in LAN

#21 2020-11-04 21:55:51

Re: [solved] cannot resolve hostname of one host in LAN

#22 2020-11-05 09:37:22

Re: [solved] cannot resolve hostname of one host in LAN

#23 2020-11-05 13:23:11

Re: [solved] cannot resolve hostname of one host in LAN

#24 2020-11-05 18:32:49

Re: [solved] cannot resolve hostname of one host in LAN

Board footer