Moin, auf meinem Hauptsystem (Debian Bookworm) funktioniert avahi nicht mehr. Genauer: ein Scann des Netzwerkes (Browse) findet nichts. Leider sind für mich wichtige Anwendungen darauf angewiesen. Ich kann nicht sagen, ob avahi selbst den Geist aufgegeben hat oder irgendein anderes Paket, das von avahi genutzt wird. Auf alle Fälle funktioniert ein Scann des Netzes mit avahi von allen anderen Computern aus problemlos. Am Netz selbst kann es also nicht liegen. Bisher konnte ich keine Hinweise oder Tipps finden, die mich einer Lösung näher brachten. Vielleicht weiß hier ja jemand, an was das Problem liegen könnte Ich wende mich trotz Debian auch an die OpenSuSE Gemeinschaft, weil vielleicht hier jemand sitzt, der mir helfen kann. Ich sende auf allen Frequenzen ;-) Gruß Joachim
Joachim H. schrieb:
auf meinem Hauptsystem (Debian Bookworm) funktioniert avahi nicht mehr. Genauer: ein Scann des Netzwerkes (Browse) findet nichts.
Was sagt "ip maddr"? Taucht beim Ethernet-Device die Adresse 224.0.0.251 auf? Taucht bei "netstat -uanp" der Port 5353 auf? Mit dem avahi-Daemon als zugehörigem Prozess? Falls Du eine Firewall nutzt, taucht im Log der UDP-Port 5353 auf? Falls Du tcpdump oder wireshark bedienen kannst: Was passiert bei einem Trace auf UDP-Port 5353? Gibt es eingehende Pakete auf diesem Port? -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Moin, meine Antwort von gestern liegt wohl immer noch bei einem Moderator. Ich hatte eine wireshark Datei angehängt. Hier jetzt mal ein Downloadlink. https://uploadnow.io/f/rm297kL zum Rest der Fragen: Am 05.02.24 um 15:28 schrieb Manfred Haertel, DB3HM:
Joachim H. schrieb:
auf meinem Hauptsystem (Debian Bookworm) funktioniert avahi nicht mehr. Genauer: ein Scann des Netzwerkes (Browse) findet nichts.
Was sagt "ip maddr"? Taucht beim Ethernet-Device die Adresse 224.0.0.251 auf?
Ja, 2: enp42s0 link 01:00:5e:00:00:01 link 33:33:00:00:00:01 link 33:33:ff:fb:59:10 link 33:33:00:00:00:fb link 33:33:ff:65:36:cf link 33:33:ff:4d:a4:ea link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 inet6 ff02::1:ff4d:a4ea inet6 ff02::1:ff65:36cf inet6 ff02::fb inet6 ff02::1:fffb:5910 inet6 ff02::1 inet6 ff01::1
Taucht bei "netstat -uanp" der Port 5353 auf? Mit dem avahi-Daemon als zugehörigem Prozess?
Jein udp6 0 0 :::5353 :::* - ●avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; preset: enabled) Active: active (running)since Mon 2024-02-05 15:27:28 CET; 12min ago TriggeredBy: ●avahi-daemon.socket Main PID: 1285 (avahi-daemon) Status: "avahi-daemon 0.8 starting up." Tasks: 2 (limit: 76928) Memory: 1.8M CPU: 43ms CGroup: /system.slice/avahi-daemon.service ├─1285 "avahi-daemon: running [Theophila.local]" └─1350 "avahi-daemon: chroot helper"
Falls Du eine Firewall nutzt, taucht im Log der UDP-Port 5353 auf?
Firewall ist aus Falls Du tcpdump oder wireshark bedienen kannst: Was passiert bei einem Trace auf UDP-Port 5353? Gibt es eingehende Pakete auf diesem Port?
Joachim H. schrieb:
meine Antwort von gestern liegt wohl immer noch bei einem Moderator. Ich hatte eine wireshark Datei angehängt. Hier jetzt mal ein Downloadlink.
Das sieht eigentlich relativ normal aus und da ist tatsächlich ganz schön was los. Ein Problem kann ich da erst mal nicht erkennen. In erster Näherung hast Du kein Netzwerk-Problem.
Was sagt "ip maddr"? Taucht beim Ethernet-Device die Adresse 224.0.0.251 auf?
Ja,
2: enp42s0 link 01:00:5e:00:00:01 link 33:33:00:00:00:01 link 33:33:ff:fb:59:10 link 33:33:00:00:00:fb link 33:33:ff:65:36:cf link 33:33:ff:4d:a4:ea link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 inet6 ff02::1:ff4d:a4ea inet6 ff02::1:ff65:36cf inet6 ff02::fb inet6 ff02::1:fffb:5910 inet6 ff02::1 inet6 ff01::1
Auch gut.
Taucht bei "netstat -uanp" der Port 5353 auf? Mit dem avahi-Daemon als zugehörigem Prozess?
Jein
udp6 0 0 :::5353 :::* -
Mach das bitte noch mal als root, dann sollte auch der Prozess angezeigt werden. Nicht dass das ein anderer ist als avahi. ABER: Ist das das einzige Vorkommen von Port 5353? Bei mir sieht der Ausschnitt wie folgt aus: udp 0 0 0.0.0.0:5353 0.0.0.0:* 743/avahi-daemon: r udp6 0 0 :::5353 :::* 743/avahi-daemon: r Wenn bei Dir tatsächlich nur die EINE Zeile vorkommen SOLLTE, kann es sein, dass avahi aus irgendeinem Grund nicht auf IPv4 lauscht. KÖNNTE etwas mit dem Problem zu tun haben, allerdings tauchen in Deinem Trace auch IPv6-MDNS-Pakete auf und das sollte eigentlich auch reichen. Anyway, wenn die Zeile mit udp ohne 6 nicht auftaucht, solltest Du dem mal nachgehen.
●avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; preset: enabled) Active: active (running)since Mon 2024-02-05 15:27:28 CET; 12min ago TriggeredBy: ●avahi-daemon.socket Main PID: 1285 (avahi-daemon) Status: "avahi-daemon 0.8 starting up." Tasks: 2 (limit: 76928) Memory: 1.8M CPU: 43ms CGroup: /system.slice/avahi-daemon.service ├─1285 "avahi-daemon: running [Theophila.local]" └─1350 "avahi-daemon: chroot helper"
Das sieht auch gut aus.
Falls Du eine Firewall nutzt, taucht im Log der UDP-Port 5353 auf?
Firewall ist aus
Mach trotzdem vorsichtshalber mal ein iptables -L Nicht das "irgendwer" irgendwelche drastischen Regeln gesetzt hat. Das steht nicht im Widerspruch dazu, dass die Pakete im Trace auftauchen, denn per iptables geblockte Pakete tauchen immer noch im tcpdump auf. Was Du auch noch probieren kannst: Den avahi-Daemon mal mit "--debug" starten. Am einfachsten wohl mit "systemctl edit" oder auch händisch im Vordergrund (dazu natürlich den Service mal runterfahren). avahi ist nämlich beim Logging ohne --debug nicht besonders geschwätzig. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
netstat bringt beide Einträge, IPv4 und IPv6. Und er zeigt auch avahi an. Lag wohl daran, dass ich kein root war gestern. root@Theophila:/home/joachim# netstat -uanp Aktive Internetverbindungen (Server und stehende Verbindungen) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 0.0.0.0:5353 0.0.0.0:* 1284/avahi-daemon: udp6 0 0 :::5353 :::* 1284/avahi-daemon: und root@Theophila:/etc# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Joachim H. schrieb:
root@Theophila:/home/joachim# netstat -uanp Aktive Internetverbindungen (Server und stehende Verbindungen) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 0.0.0.0:5353 0.0.0.0:* 1284/avahi-daemon: udp6 0 0 :::5353 :::* 1284/avahi-daemon: [...] root@Theophila:/etc# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
OK, sieht also auch alles richtig aus. Bliebe noch der Versuch, avahi mit --debug zu starten, siehe meinen letzten Beitrag. Ich hatte kürzlich auch ein Problem mit avahi und im Syslog stand einfach gar nichts dazu, der hat einfach nur ein eingegangenes Paket stillschweigend verworfen (wie sich später herausstellte mit Recht, aber ich wollte halt wissen warum). Mit --debug hat er mir genau gesagt, was für ein Problem er hat. Vielleicht klappt das ja auch bei Dir. An der Konfiguration von avahi wurde sicherlich nichts geändert? -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
sorry, ich hatte schlicht vergessen den log anzuhängen root@Theophila:/home/joachim# /usr/sbin/avahi-daemon --debug Process 9609 died: No such process; trying to remove PID file. (/run/avahi-daemon//pid) Found user 'avahi' (UID 110) and group 'avahi' (GID 117). Successfully dropped root privileges. avahi-daemon 0.8 starting up. chroot.c: chroot() helper started Successfully called chroot(). Successfully dropped remaining capabilities. chroot.c: chroot() helper got command 02 No service file found in /etc/avahi/services. Joining mDNS multicast group on interface vmnet8.IPv6 with address fe80::250:56ff:fec0:8. New relevant interface vmnet8.IPv6 for mDNS. Joining mDNS multicast group on interface vmnet8.IPv4 with address 172.16.219.1. New relevant interface vmnet8.IPv4 for mDNS. Joining mDNS multicast group on interface vmnet1.IPv6 with address fe80::250:56ff:fec0:1. New relevant interface vmnet1.IPv6 for mDNS. Joining mDNS multicast group on interface vmnet1.IPv4 with address 192.168.4.1. New relevant interface vmnet1.IPv4 for mDNS. Joining mDNS multicast group on interface enp42s0.IPv6 with address 2003:d9:d709:7800:d033:5e27:f365:36cf. New relevant interface enp42s0.IPv6 for mDNS. Joining mDNS multicast group on interface enp42s0.IPv4 with address 192.168.178.15. New relevant interface enp42s0.IPv4 for mDNS. Joining mDNS multicast group on interface lo.IPv6 with address ::1. New relevant interface lo.IPv6 for mDNS. Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. New relevant interface lo.IPv4 for mDNS. Network interface enumeration completed. Registering new address record for fe80::250:56ff:fec0:8 on vmnet8.*. Registering new address record for 172.16.219.1 on vmnet8.IPv4. Registering new address record for fe80::250:56ff:fec0:1 on vmnet1.*. Registering new address record for 192.168.4.1 on vmnet1.IPv4. Registering new address record for 2003:d9:d709:7800:d033:5e27:f365:36cf on enp42s0.*. Registering new address record for 2003:d9:d709:7800:8c3c:3c92:4309:d343 on enp42s0.*. Registering new address record for 192.168.178.15 on enp42s0.IPv4. Registering new address record for ::1 on lo.*. Registering new address record for 127.0.0.1 on lo.IPv4. dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetAPIVersion dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetAPIVersion dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetState dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetState dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable Server startup complete. Host name is Theophila.local. Local service cookie is 2941279212. sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable ^CGot SIGINT, quitting. Leaving mDNS multicast group on interface vmnet8.IPv6 with address fe80::250:56ff:fec0:8. Leaving mDNS multicast group on interface vmnet8.IPv4 with address 172.16.219.1. Leaving mDNS multicast group on interface vmnet1.IPv6 with address fe80::250:56ff:fec0:1. Leaving mDNS multicast group on interface vmnet1.IPv4 with address 192.168.4.1. Leaving mDNS multicast group on interface enp42s0.IPv6 with address 2003:d9:d709:7800:d033:5e27:f365:36cf. Leaving mDNS multicast group on interface enp42s0.IPv4 with address 192.168.178.15. sendmsg() to ff02::fb failed: Network is unreachable Leaving mDNS multicast group on interface lo.IPv6 with address ::1. Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. avahi-daemon 0.8 exiting. root@Theophila:/home/joachim# An der Konfiguration von avahi habe ich persönlich nichts gemacht. Da kenne ich mich nicht aus und daher Finger weg. [server] #host-name=foo #domain-name=local #browse-domains=0pointer.de, zeroconf.org use-ipv4=yes use-ipv6=yes #allow-interfaces=eth0 #deny-interfaces=eth1 #check-response-ttl=no #use-iff-running=no #enable-dbus=yes #disallow-other-stacks=no #allow-point-to-point=no #cache-entries-max=4096 #clients-max=4096 #objects-per-client-max=1024 #entries-per-entry-group-max=32 ratelimit-interval-usec=1000000 ratelimit-burst=1000 [wide-area] enable-wide-area=yes [publish] #disable-publishing=no #disable-user-service-publishing=no #add-service-cookie=no #publish-addresses=yes publish-hinfo=no publish-workstation=no #publish-domain=yes #publish-dns-servers=192.168.50.1, 192.168.50.2 #publish-resolv-conf-dns-servers=yes #publish-aaaa-on-ipv4=yes #publish-a-on-ipv6=no [reflector] #enable-reflector=no #reflect-ipv=no #reflect-filters=_airplay._tcp.local,_raop._tcp.local [rlimits] #rlimit-as= #rlimit-core=0 #rlimit-data=8388608 #rlimit-fsize=0 #rlimit-nofile=768 #rlimit-stack=8388608 #rlimit-nproc=3
Joachim H. schrieb:
root@Theophila:/home/joachim# /usr/sbin/avahi-daemon --debug
[...]
sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable
[...] Diese Meldung ist zumindest mal merkwürdig. ff02::fb ist das IPv6-Äquivalent zu 224.0.0.251, also die Multicast-Adresse, an die der DNS-Multicast geschickt wird. In Deinem Netzwerk-Trace sieht man aber, dass die entsprechenden Pakete sogar rausgehen (und dass sogar Antworten drauf kommen). Wahrscheinlich betrifft diese Meldung ein anderes Interface als das Ethernet-Interface, vermutlich die vmnet*-Interfaces, die vermutlich zu VMware gehören. Im Rest des Logs sehe ich nichts merkwürdiges. Vielleicht wäre es mal einen Versuch wert, zu schauen, ob avahi OHNE die VMware-Interfaces funktioniert. Am einfachsten mal deny-interfaces=vmnet1,vmnet8 in die avahi-daemon.conf schreiben.
An der Konfiguration von avahi habe ich persönlich nichts gemacht. Da kenne ich mich nicht aus und daher Finger weg.
Da sehe ich auch nicht besonderes, das ist die Default-Konfiguration, die fast immer funktioniert und bei mir auch so ist. Und Deinem Netzwerk-Trace nach zu urteilen ist auch alles OK. Mehrere Clients in Deinem Netzwerk antworten auf Deinen "browse" und die Pakete kommen mindestens mal bis zum Trace. Und da der avahi-daemon auf den richtigen Port "lauscht" müssten sie dort auch ankommen. Das bringt mich auf folgende Idee: Das Problem könnte auch zwischen avahi-browse und dem avahi-daemon liegen. Da ist mittlerweile wohl der DBUS dazwischen. Mach doch mal ein dbus-monitor --system und schaue, ob da überhaupt was avahi betreffendes drüber geht. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 06.02.24 um 15:33 schrieb Manfred Haertel, DB3HM:
sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable
[...]
Diese Meldung ist zumindest mal merkwürdig. ff02::fb ist das IPv6-Äquivalent zu 224.0.0.251, also die Multicast-Adresse, an die der DNS-Multicast geschickt wird.
joachim@Theophila:~$ ping ff02::fb PING ff02::fb(ff02::fb) 56 data bytes 64 bytes from fe80::d17a:519c:9bfb:5910%enp42s0: icmp_seq=1 ttl=64 time=0.049 ms 64 bytes from fe80::d17a:519c:9bfb:5910%enp42s0: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from fe80::d17a:519c:9bfb:5910%enp42s0: icmp_seq=3 ttl=64 time=0.035 ms
In Deinem Netzwerk-Trace sieht man aber, dass die entsprechenden Pakete sogar rausgehen (und dass sogar Antworten drauf kommen).
Wahrscheinlich betrifft diese Meldung ein anderes Interface als das Ethernet-Interface, vermutlich die vmnet*-Interfaces, die vermutlich zu VMware gehören.
Im Rest des Logs sehe ich nichts merkwürdiges.
Vielleicht wäre es mal einen Versuch wert, zu schauen, ob avahi OHNE die VMware-Interfaces funktioniert. Am einfachsten mal deny-interfaces=vmnet1,vmnet8 in die avahi-daemon.conf schreiben.
Ich habe diese Zeile in den Abschnitt [server] eingefügt. Bringt aber keine Unterschiede im Verhalten.
Das bringt mich auf folgende Idee: Das Problem könnte auch zwischen avahi-browse und dem avahi-daemon liegen. Da ist mittlerweile wohl der DBUS dazwischen. Mach doch mal ein dbus-monitor --system und schaue, ob da überhaupt was avahi betreffendes drüber geht.
Also, da kommt was mit Avahi, immer mal wieder. method call time=1707235020.363518 sender=:1.236 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal', interface='org.freedesktop.Avahi.Server', sender='org.freedesktop.Avahi', path='/'" method return time=1707235020.363524 sender=org.freedesktop.DBus -> destination=:1.236 serial=3 reply_serial=2 method call time=1707235020.363584 sender=:1.236 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal', interface='org.freedesktop.DBus', sender='org.freedesktop.DBus', path='/org/freedesktop/DBus'" method return time=1707235020.363590 sender=org.freedesktop.DBus -> destination=:1.236 serial=4 reply_serial=3 method call time=1707235020.363634 sender=:1.236 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal', interface='org.freedesktop.DBus.Local'" method return time=1707235020.363639 sender=org.freedesktop.DBus -> destination=:1.236 serial=5 reply_serial=4 method call time=1707235020.363686 sender=:1.236 -> destination=org.freedesktop.Avahi serial=5 path=/; interface=org.freedesktop.DBus.Peer; member=Ping method return time=1707235020.363729 sender=:1.165 -> destination=:1.236 serial=34 reply_serial=5 method call time=1707235020.363772 sender=:1.236 -> destination=org.freedesktop.Avahi serial=6 path=/; interface=org.freedesktop.Avahi.Server; member=GetAPIVersion method return time=1707235020.363813 sender=:1.165 -> destination=:1.236 serial=35 reply_serial=6 uint32 516 method call time=1707235020.363855 sender=:1.236 -> destination=org.freedesktop.Avahi serial=7 path=/; interface=org.freedesktop.Avahi.Server; member=GetState method return time=1707235020.363893 sender=:1.165 -> destination=:1.236 serial=36 reply_serial=7 int32 2 method call time=1707235020.363950 sender=:1.236 -> destination=org.freedesktop.Avahi serial=8 path=/; interface=org.freedesktop.Avahi.Server; member=ServiceTypeBrowserNew int32 -1 int32 -1 string "" uint32 0 method return time=1707235020.363994 sender=:1.165 -> destination=:1.236 serial=37 reply_serial=8 object path "/Client4/ServiceTypeBrowser1" signal time=1707235020.374164 sender=:1.165 -> destination=:1.236 serial=38 path=/Client4/ServiceTypeBrowser1; interface=org.freedesktop.Avahi.ServiceTypeBrowser; member=CacheExhausted signal time=1707235020.374180 sender=:1.165 -> destination=:1.236 serial=39 path=/Client4/ServiceTypeBrowser1; interface=org.freedesktop.Avahi.ServiceTypeBrowser; member=AllForNow signal time=1707235022.994823 sender=:1.45 -> destination=(null destination) serial=3516 path=/org/freedesktop/UPower/devices/battery_hidpp_battery_0; interface=org.freedesktop.DBus.Properties;
Joachim H. schrieb:
Am 06.02.24 um 15:33 schrieb Manfred Haertel, DB3HM:
sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable sendmsg() to ff02::fb failed: Network is unreachable
[...]
Diese Meldung ist zumindest mal merkwürdig. ff02::fb ist das IPv6-Äquivalent zu 224.0.0.251, also die Multicast-Adresse, an die der DNS-Multicast geschickt wird.
joachim@Theophila:~$ ping ff02::fb PING ff02::fb(ff02::fb) 56 data bytes 64 bytes from fe80::d17a:519c:9bfb:5910%enp42s0: icmp_seq=1 ttl=64 time=0.049 ms 64 bytes from fe80::d17a:519c:9bfb:5910%enp42s0: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from fe80::d17a:519c:9bfb:5910%enp42s0: icmp_seq=3 ttl=64 time=0.035 ms
Da es sich um einen Multicast handelt und es Systeme gibt, die mDNS konfiguriert haben, antwortet eins, auf dem Ethernet-Interface. Was übrigens auch bedeutet, dass auch Multicast über IPv6 prinzipiell funktioniert (was aber durch den Trace ohnehin klar war). Vermutlich führt aber der Versuch, einen Multicast über ein VMware-Interface zu schicken, zu einer Fehlermeldung aus dem Treiber. Es hätte also sein können, dass dies avahi irgendwie aus dem Tritt bringt.
Vielleicht wäre es mal einen Versuch wert, zu schauen, ob avahi OHNE die VMware-Interfaces funktioniert. Am einfachsten mal deny-interfaces=vmnet1,vmnet8 in die avahi-daemon.conf schreiben.
Ich habe diese Zeile in den Abschnitt [server] eingefügt. Bringt aber keine Unterschiede im Verhalten.
Dann war's das trotz oben erklärter Hoffnung auch nicht.
Das bringt mich auf folgende Idee: Das Problem könnte auch zwischen avahi-browse und dem avahi-daemon liegen. Da ist mittlerweile wohl der DBUS dazwischen. Mach doch mal ein dbus-monitor --system und schaue, ob da überhaupt was avahi betreffendes drüber geht.
Also, da kommt was mit Avahi, immer mal wieder.
Das sieht im Grunde auch gut aus. Die reden miteinander, nur dass - wenn ich das richtig lese - der Daemon nix für den Browse hat, was wir ja schon wissen. Verflixter Bug. Einen hab ich noch. Ermittle mal die pid des avahi-daemon und mache dann: strace -t -f -p $avahi_daemon_pid -e recvmsg -s 1000 (also $avahi_daemon_pid durch die ermittelte pid ersetzen). Dann mal ein avahi-browse machen und am besten auch mal ein Gerät, was mDNS-fähig ist mal neu einschalten (dann macht sich das nämlich im mDNS bekannt). Treten dann Einträge mit sin_port=htons(5353) und sin_addr=inet_addr("192.168.178.15") auf (letzteres war ja glaube ich Deine IP-Adresse auf dem Ethernet-Interface)? Am besten mal den gesamten Output von strace per Download bereit stellen. Und noch eine Idee am Rande: Könnte es sein, dass es eine apparmor-Regel für den avahi-daemon gibt, die ihm irgendwas verbietet? Ist zwar höchst unwahrscheinlich, denn meine Debian-Test-VM hat so eine nicht und wenn Du eine gemacht hättest, wüsstest Du es, aber der Vollständigkeit halber sei dies auch noch mal gefragt, man weiß ja nie, wo die vielleicht herkommt. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Manfred Haertel, DB3HM schrieb:
Einen hab ich noch. Noch einen:
Mach mal killall -USR1 avahi-daemon Dann müsste der avahi-daemon seinen Cache ins Syslog schreiben. Damit müssten wir unterscheiden können, ob er die anderen mDNS-Knoten nicht kennt oder nicht preis gibt. Sich selber kennt er auf jeden Fall. Die Frage ist, ob er auch die anderen Knoten gecacht hat, die in Deinem Netz mDNS machen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 07.02.24 um 19:28 schrieb Manfred Haertel, DB3HM:
Manfred Haertel, DB3HM schrieb:
Einen hab ich noch. Noch einen:
Mach mal killall -USR1 avahi-daemon
hier, vom Start bis zum direkten kill danach root@Theophila:/etc/systemd/system/avahi-daemon.service.d# journalctl -f Feb 08 11:14:17 Theophila avahi-daemon[11969]: Network interface enumeration completed. Feb 08 11:14:17 Theophila avahi-daemon[11969]: Registering new address record for 2003:d9:d709:7800:d033:5e27:f365:36cf on enp42s0.*. Feb 08 11:14:17 Theophila avahi-daemon[11969]: Registering new address record for 2003:d9:d709:7800:69a6:e302:34a4:9630 on enp42s0.*. Feb 08 11:14:17 Theophila avahi-daemon[11969]: Registering new address record for 192.168.178.15 on enp42s0.IPv4. Feb 08 11:14:17 Theophila avahi-daemon[11969]: Registering new address record for ::1 on lo.*. Feb 08 11:14:17 Theophila avahi-daemon[11969]: Registering new address record for 127.0.0.1 on lo.IPv4. Feb 08 11:14:18 Theophila avahi-daemon[11969]: Server startup complete. Host name is Theophila.local. Local service cookie is 4059428316. Feb 08 11:16:07 Theophila avahi-daemon[11969]: Got SIGUSR1, dumping record data. Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; ZONE DUMP FOLLOWS ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: 1.0.0.127.in-addr.arpa IN PTR Theophila.local ; ttl=120 ; iface=1 proto=0 Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN A 127.0.0.1 ; ttl=120 ; iface=1 proto=0 Feb 08 11:16:07 Theophila avahi-daemon[11969]: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa IN PTR Theophila.local ; ttl=120 ; iface=1 proto=-1 Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN AAAA ::1 ; ttl=120 ; iface=1 proto=-1 Feb 08 11:16:07 Theophila avahi-daemon[11969]: 15.178.168.192.in-addr.arpa IN PTR Theophila.local ; ttl=120 ; iface=2 proto=0 Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN A 192.168.178.15 ; ttl=120 ; iface=2 proto=0 Feb 08 11:16:07 Theophila avahi-daemon[11969]: 0.3.6.9.4.a.4.3.2.0.3.e.6.a.9.6.0.0.8.7.9.0.7.d.9.d.0.0.3.0.0.2.ip6.arpa IN PTR Theophila.local ; ttl=120 ; iface=2 proto=-1 Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN AAAA 2003:d9:d709:7800:69a6:e302:34a4:9630 ; ttl=120 ; iface=2 proto=-1 Feb 08 11:16:07 Theophila avahi-daemon[11969]: f.c.6.3.5.6.3.f.7.2.e.5.3.3.0.d.0.0.8.7.9.0.7.d.9.d.0.0.3.0.0.2.ip6.arpa IN PTR Theophila.local ; ttl=120 ; iface=2 proto=-1 Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN AAAA 2003:d9:d709:7800:d033:5e27:f365:36cf ; ttl=120 ; iface=2 proto=-1 Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; INTERFACE enp42s0.IPv6 ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; CACHE DUMP FOLLOWS ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; INTERFACE enp42s0.IPv4 ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; CACHE DUMP FOLLOWS ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; INTERFACE lo.IPv6 ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; CACHE DUMP FOLLOWS ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; INTERFACE lo.IPv4 ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;;; CACHE DUMP FOLLOWS ;;; Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN AAAA ::1 ; ttl=120 Feb 08 11:16:07 Theophila avahi-daemon[11969]: 1.0.0.127.in-addr.arpa IN PTR Theophila.local ; ttl=120 Feb 08 11:16:07 Theophila avahi-daemon[11969]: Theophila.local IN A 127.0.0.1 ; ttl=120 Feb 08 11:16:07 Theophila avahi-daemon[11969]: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa IN PTR Theophila.local ; ttl=120 Feb 08 11:16:07 Theophila avahi-daemon[11969]: ;; WIDE AREA CACHE ;;; ich werde jetzt mal die Windows-Methode vorbereiten, d.h. deinstallieren, reboot und neu installieren. Purge nicht vergessen.
Joachim H. schrieb:
Mach mal killall -USR1 avahi-daemon
hier, vom Start bis zum direkten kill danach
OK, das sagt, dass der avahi-daemon wirklich nur "sich selbst" kennt. Das ist immerhin konsistent mit der Ausgabe von strace. Dem zufolge kommt kein Paket von irgendwelchen anderen Knoten beim avahi-daemon an - obwohl die Pakete laut Trace auf dem Interface ankommen und der avahi-daemon laut netstat auf den Port hört. D.h. die Pakete gehen irgendwo auf dem Weg vom Treiber durch den Kernel zum avahi-daemon verloren. Wenigstens mal eine Eingrenzung. Hm... kann es sein, dass aus irgendeinem blöden Grunde Multicast auf dem Interface abgeschaltet ist? Das sieht man sogar mit ifconfig, bei mir aktuell: eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 Oder die Pakete werden aus irgendeinem anderen Grunde verworfen, z.B. (vermeintlich) falsche Checksum oder irgend so was. Nur warum sollte das plötzlich ohne Benutzer-Einwirkung auftreten? Starte mal den avahi-daemon interaktiv mit strace, also sowas wie strace -f -t -s 1000 avahi-daemon Vielleicht sehe ich darin noch irgendeine Erkenntnis bringende Meldung bei der Initialisierung (irgendwas wichtiges kann er nicht öffnen oder ein ioctl geht schief oder so).
ich werde jetzt mal die Windows-Methode vorbereiten, d.h. deinstallieren, reboot und neu installieren. Purge nicht vergessen.
Da bin ich gespannt auf das Ergebnis. Ich würde im momentanen Erkenntnis-Stand erwarten, dass avahi-daemon neu installieren nichts hilft, da die Pakete ja nicht mal bei selbigem ankommen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 08.02.24 um 13:46 schrieb Manfred Haertel, DB3HM:
Starte mal den avahi-daemon interaktiv mit strace, also sowas wie
strace -f -t -s 1000 avahi-daemon
Vielleicht sehe ich darin noch irgendeine Erkenntnis bringende Meldung bei der Initialisierung (irgendwas wichtiges kann er nicht öffnen oder ein ioctl geht schief oder so).
Joachim H. schrieb:
Am 08.02.24 um 13:46 schrieb Manfred Haertel, DB3HM:
Starte mal den avahi-daemon interaktiv mit strace, also sowas wie
strace -f -t -s 1000 avahi-daemon
Vielleicht sehe ich darin noch irgendeine Erkenntnis bringende Meldung bei der Initialisierung (irgendwas wichtiges kann er nicht öffnen oder ein ioctl geht schief oder so).
Da sehe ich leider auch nichts und die interessanten Systemaufrufe wie setsockopt habe ich sogar mit dem Verhalten bei mir verglichen, wo avahi nachweislich geht - absolut identisch. Sorry, mindestens mal für den Moment bin ich mit meinem Latein am Ende. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 08.02.24 um 13:46 schrieb Manfred Haertel, DB3HM: (...)
Das ist immerhin konsistent mit der Ausgabe von strace. Dem zufolge kommt kein Paket von irgendwelchen anderen Knoten beim avahi-daemon an - obwohl die Pakete laut Trace auf dem Interface ankommen und der avahi-daemon laut netstat auf den Port hört.
D.h. die Pakete gehen irgendwo auf dem Weg vom Treiber durch den Kernel zum avahi-daemon verloren. Wenigstens mal eine Eingrenzung.
Nur mal so nebenbei ... die FW blockt kein Multicast, ja? Bernd
bnacht schrieb:
Am 08.02.24 um 13:46 schrieb Manfred Haertel, DB3HM: (...)
Das ist immerhin konsistent mit der Ausgabe von strace. Dem zufolge kommt kein Paket von irgendwelchen anderen Knoten beim avahi-daemon an - obwohl die Pakete laut Trace auf dem Interface ankommen und der avahi-daemon laut netstat auf den Port hört.
D.h. die Pakete gehen irgendwo auf dem Weg vom Treiber durch den Kernel zum avahi-daemon verloren. Wenigstens mal eine Eingrenzung.
Nur mal so nebenbei ... die FW blockt kein Multicast, ja?
Er hatte keinerlei iptables-Regeln. Also kann auch nichts geblockt werden. Es könnte noch Multicast abgeschaltet sein, besonders auf dem Interface selber, die Antwort dazu steht noch aus, aber warum sollte das erstens der Fall sein und zweitens wenn es der Fall wäre, dürfte eigentlich keine Multicast-Adresse für mDNS auf dem Interface mit "ip maddr" angezeigt werden und das wird es. Ein Kernel-Bug an sich kann es auch nicht sein, denn auf einer Debian-VM bei mir geht avahi. Vielleicht einer, der sich nur in bestimmten Umgebungen auswirkt. Daher bin ich ziemlich ratlos (geworden). -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Moin, multicast ist an joachim@Theophila:~$ ifconfig enp42s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 Mal sehen, ob sich das avahi Problem mit der Zeit berappelt. Irgendein Update irgendeines anderes Paketes könnte es richten, so hoffe ich. Am 09.02.24 um 08:10 schrieb Manfred Haertel, DB3HM:
bnacht schrieb:
Am 08.02.24 um 13:46 schrieb Manfred Haertel, DB3HM: (...)
Das ist immerhin konsistent mit der Ausgabe von strace. Dem zufolge kommt kein Paket von irgendwelchen anderen Knoten beim avahi-daemon an - obwohl die Pakete laut Trace auf dem Interface ankommen und der avahi-daemon laut netstat auf den Port hört.
D.h. die Pakete gehen irgendwo auf dem Weg vom Treiber durch den Kernel zum avahi-daemon verloren. Wenigstens mal eine Eingrenzung.
Nur mal so nebenbei ... die FW blockt kein Multicast, ja?
Er hatte keinerlei iptables-Regeln. Also kann auch nichts geblockt werden.
Es könnte noch Multicast abgeschaltet sein, besonders auf dem Interface selber, die Antwort dazu steht noch aus, aber warum sollte das erstens der Fall sein und zweitens wenn es der Fall wäre, dürfte eigentlich keine Multicast-Adresse für mDNS auf dem Interface mit "ip maddr" angezeigt werden und das wird es.
Ein Kernel-Bug an sich kann es auch nicht sein, denn auf einer Debian-VM bei mir geht avahi. Vielleicht einer, der sich nur in bestimmten Umgebungen auswirkt.
Daher bin ich ziemlich ratlos (geworden).
Joachim H. schrieb:
Mal sehen, ob sich das avahi Problem mit der Zeit berappelt. Irgendein Update irgendeines anderes Paketes könnte es richten, so hoffe ich. Da bin ich leider nicht so optimistisch. avahi hat nämlich kaum Abhängigkeiten außer dem DBus zwischen Client und Daemon und den haben wir eigentlich schon ausgeschlossen.
Und bei mir funktioniert avahi ja, auch auf einer Debian-VM, übrigens auf einer ziemlich "fetten", wo doch etliche Pakete installiert sind (die über irgendwelche dummen Zusammenhänge dem avahi in die Suppe spucken *könnten*). Es ist also auch kein generelles Debian-Problem. Irgendwas ist bei Dir anders und mir sind jetzt die Ideen ausgegangen, wo man noch danach suchen könnte. Dennoch, da ich mich grade auch intensiv mit avahi beschäftige, interessiert mich das Problem, also wenn ich noch eine Idee habe würde ich mich noch mal melden. Umgekehrt würde es mich auch interessieren, wenn Du den Grund findest. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 09.02.24 um 11:58 schrieb Manfred Haertel, DB3HM:
Joachim H. schrieb:
Mal sehen, ob sich das avahi Problem mit der Zeit berappelt. Irgendein Update irgendeines anderes Paketes könnte es richten, so hoffe ich. Da bin ich leider nicht so optimistisch. avahi hat nämlich kaum Abhängigkeiten außer dem DBus zwischen Client und Daemon und den haben wir eigentlich schon ausgeschlossen.
Ich bin auch nicht optimistisch. Aber versucht will ich es haben.
Dennoch, da ich mich grade auch intensiv mit avahi beschäftige, interessiert mich das Problem, also wenn ich noch eine Idee habe würde ich mich noch mal melden. Umgekehrt würde es mich auch interessieren, wenn Du den Grund findest.
Ich danke Dir vielmals für dein Engagement in dieser Sache. Wenn sich was tut, melde ich mich bei dir Gruß Joachim
Am 07.02.24 um 19:12 schrieb Manfred Haertel, DB3HM:
Einen hab ich noch.
Ermittle mal die pid des avahi-daemon und mache dann:
strace -t -f -p $avahi_daemon_pid -e recvmsg -s 1000
(also $avahi_daemon_pid durch die ermittelte pid ersetzen).
Dann mal ein avahi-browse machen und am besten auch mal ein Gerät, was mDNS-fähig ist mal neu einschalten (dann macht sich das nämlich im mDNS bekannt).
Treten dann Einträge mit sin_port=htons(5353) und sin_addr=inet_addr("192.168.178.15") auf (letzteres war ja glaube ich Deine IP-Adresse auf dem Ethernet-Interface)?
Am besten mal den gesamten Output von strace per Download bereit stellen.
https://uploadnow.io/f/vh6bNYg Ein anderes Gerät habe ich während des strace nicht gestartet. Habe gemerkt, dass mein Raspi auch ein Problem hat, der blieb nämlich beim reboot hängen und damit hat's kein weiteres mDNS. Außerdem hat mir die Aktion mein System ins Stottern gebracht und musste neu booten. Kurzzeitig war die Einstellung für meinen primären Monitor weg. Erst nach dem zweiten Reboot war wieder alles so einstellbar wie vorher. Holzauge sei wachsam.
Und noch eine Idee am Rande: Könnte es sein, dass es eine apparmor-Regel für den avahi-daemon gibt, die ihm irgendwas verbietet? Ist zwar höchst unwahrscheinlich, denn meine Debian-Test-VM hat so eine nicht und wenn Du eine gemacht hättest, wüsstest Du es, aber der Vollständigkeit halber sei dies auch noch mal gefragt, man weiß ja nie, wo die vielleicht herkommt.
Kommt, wenn mein Raspi wieder läuft, ist mein NAS!!
Am 08.02.24 um 12:08 schrieb Joachim H.:
Und noch eine Idee am Rande: Könnte es sein, dass es eine apparmor-Regel für den avahi-daemon gibt, die ihm irgendwas verbietet? Ist zwar höchst unwahrscheinlich, denn meine Debian-Test-VM hat so eine nicht und wenn Du eine gemacht hättest, wüsstest Du es, aber der Vollständigkeit halber sei dies auch noch mal gefragt, man weiß ja nie, wo die vielleicht herkommt.
Kommt, wenn mein Raspi wieder läuft, ist mein NAS!!
Der Raspi ist anscheinend abgeraucht! Schlechtes Karma gerade, grr. Ersatz läuft. Unter den Einstellungen von apparmor (/etc/apparmor) finde ich nur einen einzigen Hinweis auf avahi, in der Datei /etc/apparmor.d/abstractions/nameservice mit # avahi-daemon is used for mdns4 resolution @{run}/avahi-daemon/socket rw, Sonst nix.
Joachim H. schrieb:
Unter den Einstellungen von apparmor (/etc/apparmor) finde ich nur einen einzigen Hinweis auf avahi, in der Datei
/etc/apparmor.d/abstractions/nameservice
mit
# avahi-daemon is used for mdns4 resolution @{run}/avahi-daemon/socket rw,
Den hab ich auch. Damit wird einem anderen Dienst erlaubt, per Unix-Socket mit dem avahi-daemon zu kommunizieren. Also AppArmor ist auch unschuldig. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Hallo, beim Lesen dieses Threads ist mir etwas aufgefallen. Siehe unten. Am 07.02.24 um 19:12 schrieb Manfred Haertel, DB3HM:
Vermutlich führt aber der Versuch, einen Multicast über ein VMware-Interface zu schicken, zu einer Fehlermeldung aus dem Treiber. Es hätte also sein können, dass dies avahi irgendwie aus dem Tritt bringt.
Auf meinem Rechner mit OS 15.5 mit aktuellen Patches, Kernel 5.14.21-150500.55.44-default und VMware Workstation 17.5.0 build-22583795 erscheinen nach dem Booten generell folgende Fehlermeldungen bezüglich der vmnet-Interfaces: [ 5.855204] vmnet1: Current addr: 00 50 56 c0 00 01 00 00 00 ... [ 5.855209] vmnet1: Expected addr: 00 00 00 00 00 00 00 00 00 ... [ 5.855211] ------------[ cut here ]------------ [ 5.855211] netdevice: vmnet1: Incorrect netdev->dev_addr [ 5.855220] WARNING: CPU: 3 PID: 1408 at ../net \ /core/dev_addr_lists.c:513 dev_addr_check+0xbb/0x140 Danach die üblichen Meldungen über "Loaded modules", Trace usw. Das Gleiche nochmal für vmnet8. Für mich hört sich das an, als ob VMware einen API-Call mit ungültigem Parameter macht, aber ich kann nicht beurteilen, ob das Problem im VMware-Treiber liegt, oder in einem zurückportierten Patch im OS-Kernel. Grundsätzlich funktionieren hier die Netzwerkinterfaces auch aus VMs heraus, aber ich weiß nicht, welche Nebenwirkungen die genannten Fehler haben. Wenn die gleiche Fehlermeldungen auf dem Rechner mit dem Avahi-Problem auftauchen, würde ich mal testweise die VMware-Services deaktivieren: sytemctl disable vmware-USBArbitrator.service vmware.service Danach den Rechner neu Booten und prüfen, ob sich bei Avahi etwas ändert.
Am 08.02.24 um 13:17 schrieb Martin Burnicki:
Auf meinem Rechner mit OS 15.5 mit aktuellen Patches, Kernel 5.14.21-150500.55.44-default und VMware Workstation 17.5.0 build-22583795 erscheinen nach dem Booten generell folgende Fehlermeldungen bezüglich der vmnet-Interfaces:
[ 5.855204] vmnet1: Current addr: 00 50 56 c0 00 01 00 00 00 ... [ 5.855209] vmnet1: Expected addr: 00 00 00 00 00 00 00 00 00 ... [ 5.855211] ------------[ cut here ]------------ [ 5.855211] netdevice: vmnet1: Incorrect netdev->dev_addr [ 5.855220] WARNING: CPU: 3 PID: 1408 at ../net \ /core/dev_addr_lists.c:513 dev_addr_check+0xbb/0x140
Diese Meldungen tauchen bei mir nicht auf.
Wenn die gleiche Fehlermeldungen auf dem Rechner mit dem Avahi-Problem auftauchen, würde ich mal testweise die VMware-Services deaktivieren:
sytemctl disable vmware-USBArbitrator.service vmware.service
Danach den Rechner neu Booten und prüfen, ob sich bei Avahi etwas ändert.
Hat nichts verändert! Was mir aber aufgefallen ist, ist dass der avahi Service wegen der Problemsuche gerade eigentlich abgeschaltet ist (disabled). Trotzdem läuft das Teil nach einem Boot. Stoppe ich den Service per Hand, kommt noch ein Hinweis auf avahi-daemon.socket. root@Theophila:/home/joachim# systemctl status avahi-daemon ●avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; disabled; preset: enabled) Active: active (running)since Thu 2024-02-08 13:49:03 CET; 1min 16s ago TriggeredBy: ●avahi-daemon.socket Main PID: 1293 (avahi-daemon) Status: "avahi-daemon 0.8 starting up." Tasks: 2 (limit: 76928) Memory: 1.7M CPU: 22ms CGroup: /system.slice/avahi-daemon.service ├─1293 "avahi-daemon: running [Theophila.local]" └─1352 "avahi-daemon: chroot helper" Feb 08 13:49:07 Theophila avahi-daemon[1293]: New relevant interface enp42s0.IPv6 for mDNS. Feb 08 13:49:07 Theophila avahi-daemon[1293]: Registering new address record for fe80::d17a:519c:9bfb:5910 on enp42s0.*. Feb 08 13:49:09 Theophila avahi-daemon[1293]: Joining mDNS multicast group on interface enp42s0.IPv4 with address 192.168.178.15. Feb 08 13:49:09 Theophila avahi-daemon[1293]: New relevant interface enp42s0.IPv4 for mDNS. Feb 08 13:49:09 Theophila avahi-daemon[1293]: Registering new address record for 192.168.178.15 on enp42s0.IPv4. Feb 08 13:49:09 Theophila avahi-daemon[1293]: Leaving mDNS multicast group on interface enp42s0.IPv6 with address fe80::d17a:519c:9bfb:5910. Feb 08 13:49:09 Theophila avahi-daemon[1293]: Joining mDNS multicast group on interface enp42s0.IPv6 with address 2003:d9:d709:7800:d033:5e27:f365:36cf. Feb 08 13:49:09 Theophila avahi-daemon[1293]: Registering new address record for 2003:d9:d709:7800:d033:5e27:f365:36cf on enp42s0.*. Feb 08 13:49:09 Theophila avahi-daemon[1293]: Withdrawing address record for fe80::d17a:519c:9bfb:5910 on enp42s0. Feb 08 13:49:10 Theophila avahi-daemon[1293]: Registering new address record for 2003:d9:d709:7800:b473:59b4:6077:416d on enp42s0.*. root@Theophila:/home/joachim# avahi-browse -a ^CGot SIGINT, quitting. root@Theophila:/home/joachim# systemctl stop avahi-daemon Warning: Stopping avahi-daemon.service, but it can still be activated by: avahi-daemon.socket root@Theophila:/home/joachim# avahi-browse -a Failed to create client object: Daemon not running root@Theophila:/home/joachim# systemctl status avahi-daemon ○ avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; disabled; preset: enabled) Active: inactive (dead) since Thu 2024-02-08 13:51:17 CET; 28s ago Duration: 2min 14.599s TriggeredBy: ●avahi-daemon.socket Process: 1293 ExecStart=/usr/sbin/avahi-daemon -s (code=exited, status=0/SUCCESS) Main PID: 1293 (code=exited, status=0/SUCCESS) Status: "avahi-daemon 0.8 starting up." CPU: 25ms Feb 08 13:49:10 Theophila avahi-daemon[1293]: Registering new address record for 2003:d9:d709:7800:b473:59b4:6077:416d on enp42s0.*. Feb 08 13:51:17 Theophila avahi-daemon[1293]: Got SIGTERM, quitting. Feb 08 13:51:17 Theophila avahi-daemon[1293]: Leaving mDNS multicast group on interface enp42s0.IPv6 with address 2003:d9:d709:7800:d033:5e27:f365:36cf. Feb 08 13:51:17 Theophila systemd[1]: Stopping avahi-daemon.service - Avahi mDNS/DNS-SD Stack... Feb 08 13:51:17 Theophila avahi-daemon[1293]: Leaving mDNS multicast group on interface enp42s0.IPv4 with address 192.168.178.15. Feb 08 13:51:17 Theophila avahi-daemon[1293]: Leaving mDNS multicast group on interface lo.IPv6 with address ::1. Feb 08 13:51:17 Theophila avahi-daemon[1293]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. Feb 08 13:51:17 Theophila avahi-daemon[1293]: avahi-daemon 0.8 exiting. Feb 08 13:51:17 Theophila systemd[1]: avahi-daemon.service: Deactivated successfully. Feb 08 13:51:17 Theophila systemd[1]: Stopped avahi-daemon.service - Avahi mDNS/DNS-SD Stack. root@Theophila:/home/joachim#
Joachim H. schrieb:
Was mir aber aufgefallen ist, ist dass der avahi Service wegen der Problemsuche gerade eigentlich abgeschaltet ist (disabled). Trotzdem läuft das Teil nach einem Boot. Stoppe ich den Service per Hand, kommt noch ein Hinweis auf avahi-daemon.socket.
Das ist bei mir auch so, avahi-daemon.service wird durch avahi-daemon.socket gestartet. Dieser Mechanismus soll eigentlich dafür sorgen, dass der Service quasi nur bei Bedarf gestartet wird. Aber auch bei mir ist der Service immer sofort wieder da, wenn ich ihn stoppe. Man muss auch den Socket stoppen. Ist also auch normal und hat mit Deinem Problem nix zu tun. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
participants (4)
-
bnacht -
Joachim H. -
Manfred Haertel, DB3HM -
Martin Burnicki