0

In general, I'm currently replacing all networking stuff with the builtin systemd facilities. NetworkManager, dnsmasq, dhcpcd, avahi-daemon -- all gone, and things seem to be mostly working.

Except that local hostnames aren't resolved from my Desktop box anymore:

C:\Users\Christian>ping fritzwlan
Ping request could not find host fritzwlan. Please check the name and try again.

Now, I can see the queries on the server:

root@gatekeeper:/home/stieber# tcpdump -i lan -p udp
...
15:27:18.381225 IP Desktop.mdns > mdns.mcast.net.mdns: 0 A (QM)? fritzwlan.local. (33)
15:27:18.381506 IP Desktop.mdns > mdns.mcast.net.mdns: 0 AAAA (QM)? fritzwlan.local. (33)
15:27:18.469278 IP gatekeeper.mdns > mdns.mcast.net.mdns: 0 PTR (QM)? 255.255.1.10.in-addr.arpa. (43)
15:27:18.804129 IP Desktop.61938 > 224.0.0.252.5355: UDP, length 27
15:27:18.804129 IP Desktop.61316 > 224.0.0.252.5355: UDP, length 27
15:27:19.131294 IP Desktop.netbios-ns > 10.1.255.255.netbios-ns: UDP, length 50
15:27:19.383976 IP Desktop.mdns > mdns.mcast.net.mdns: 0 AAAA (QM)? fritzwlan.local. (33)
15:27:19.384990 IP Desktop.mdns > mdns.mcast.net.mdns: 0 A (QM)? fritzwlan.local. (33)
15:27:19.385926 IP Desktop.mdns > mdns.mcast.net.mdns: 0 AAAA (QM)? fritzwlan.local. (33)
15:27:19.610547 IP gatekeeper.mdns > mdns.mcast.net.mdns: 0 PTR (QM)? 255.255.1.10.in-addr.arpa. (43)

/var/log/syslog doesn't show anything.

As far as I can tell, the systemd-resolved should have multicast enabled:

root@gatekeeper:/home/stieber# resolvectl status
Global
          Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
   resolv.conf mode: stub
Fallback DNS Servers 8.8.8.8 1.1.1.1

Link 2 (lan)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wan)
...

and

root@gatekeeper:/home/stieber# resolvectl mdns
Global: yes
Link 2 (lan): yes
...
root@gatekeeper:/home/stieber# resolvectl llmnr
Global: yes
Link 2 (lan): yes
...

The config-file also says its fully enabled, and not just resolve:

root@gatekeeper:/home/stieber# cat /etc/systemd/resolved.conf
...
# lots of comments removed
...
[Resolve]
FallbackDNS=8.8.8.8 1.1.1.1
DNSStubListenerExtra=10.1.1.1:53
DNSStubListenerExtra=127.0.0.1:53
LLMNR=true
MulticastDNS=true

It's not the most terrible problem ever, especially since external hosts resolve just fine, so "the internet" works.

On the server itself, it resolves just fine:

root@gatekeeper:/home/stieber# dig fritzwlan

; <<>> DiG 9.18.24-1-Raspbian <<>> fritzwlan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47502
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;fritzwlan.                     IN      A

;; ANSWER SECTION:
fritzwlan.              0       IN      A       10.1.1.2

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun May 05 15:44:02 CEST 2024
;; MSG SIZE  rcvd: 54

Multicast is also enabled on the interface:

[Match]
Name=lan

[Link]
Multicast=true

[Network]
Address=10.1.1.1/16
DHCPServer=yes
MulticastDNS=true
LLMNR=true

[DHCPServer]
...

Based on comments:

root@gatekeeper:/home/stieber# ss -lpn 'sport = :5353 or sport = :5355'
Netid             State              Recv-Q             Send-Q                         Local Address:Port                          Peer Address:Port             Process
udp               UNCONN             0                  0                                    0.0.0.0:5353                               0.0.0.0:*                 users:(("systemd-resolve",pid=1626,fd=15))
udp               UNCONN             0                  0                                    0.0.0.0:5355                               0.0.0.0:*                 users:(("systemd-resolve",pid=1626,fd=11))
udp               UNCONN             0                  0                                          *:5353                                     *:*                 users:(("systemd-resolve",pid=1626,fd=16))
udp               UNCONN             0                  0                                          *:5355                                     *:*                 users:(("systemd-resolve",pid=1626,fd=13))
tcp               LISTEN             0                  4096                                 0.0.0.0:5355                               0.0.0.0:*                 users:(("systemd-resolve",pid=1626,fd=12))
tcp               LISTEN             0                  4096                                    [::]:5355                                  [::]:*                 users:(("systemd-resolve",pid=1626,fd=14))

So it seems the thing is listening on these ports. No idea how the "multicast" plays into this, though.

Same with firewall: towards "LAN", it should be completely open:

root@gatekeeper:/home/stieber# nft list ruleset
        chain output-rejects {
                oifname "wan" tcp dport { 25, 110, 143 } reject
        }

        chain output {
                type filter hook output priority 100; policy accept;
                jump output-rejects
        }
...
table inet filter {
...
        chain input {
                type filter hook input priority filter; policy drop;
                ct state invalid drop
                icmp type echo-request limit rate over 2/second drop
                ip protocol icmp accept
                iif { "lo", "lan" } accept
...

But, I must admit, I don't know yet how multicast factors into this...


So, right now, I'm rather confused as to where to look... any ideas?

6
  • firewall settings?
    – Tom Yan
    Commented May 5 at 20:10
  • Did you confirm that something's listening on 5353/UDP?
    – Spiff
    Commented May 5 at 23:18
  • @TomYan good idea; I'll have to look into whether multicast needs some special handling. Nft is almost completely open towards the "LAN". @Spiff I added an ss output suggesting that not just something but actually systemd-resolved does. Commented May 6 at 0:37
  • I think it's best to share full output of nft list ruleset (and maybe also iptables-save). Btw, I just notice that in the dig output, the name was resolved to 10.1.1.2, while you .network file configure the interface with 10.1.1.1. Did you change the IP in the middle?
    – Tom Yan
    Commented May 6 at 17:32
  • And your shell prompt seems to indicate that the hostname is gatekeeper?
    – Tom Yan
    Commented May 6 at 17:39

0

You must log in to answer this question.

Browse other questions tagged .