Posts by eins99

    Dann zeige mal die richtig anonymisierte (falls erforderlich) Ausgabe von:

    meinst du im kaputten Zustand?

    Jetzt gerade, mit korrektem Hostnamen, kommt bei denen mit Suffix nix (failed to resolve host name ... DNS failure: NXDOMAIN) und sonst "nur" die IPv4 Adresse, keine IPv6. wanda ist aber per IPv6 (ping, ssh, ...) erreichbar.


    EDIT:

    ich muss differenzieren, sry.

    für wanda-1.local kommt Failed to resolve host name 'wanda-1.local': Timeout reached
    für wanda-1.fritz.box kommt Failed to resolve host name 'wanda-1.fritz.box': DNS failure: NXDOMAIN

    meine Augen hatten sich in der falschen Zeile verfangen!

    Ich bin den ganzen Thread noch mal durch, vielleicht habe ich was übersehen.


    Was ich bisher noch nicht gemacht habe, ist avahi mit check-response-ttl=no. das steht noch aus.

    Was mir jetzt noch aufgefallen ist, eigentlich sollte aktuell die IP mit der Mac-Adresse erstellt werden. Es gibt aber keine IPS mit dem wohl typischen Teil ff:fe. Das wäre noch ein Ansatz zum prüfen.

    Ich wollte eigentlich zum Ausdruck bringen, dass ich mich wundere, warum das Problem noch besteht und noch nicht von offizieller Seite eine Lösung existiert.

    Die Lösung gibt es und ist: PEs auf dem PI deaktivieren, mac-address-basierte ID bei den IPv6-Adressen und das v6DHCP der FritzBox benutzen.

    Das ist komisch, denn ich dachte, das hätte ich so auch gemacht. Und trotzdem hat es mich heute Nacht wieder erwischt. Dann ist da was anderes faul.

    Zurück auf Los? Ich weiß nicht, denn irgendwas verstehe ich nicht.

    Die mac-basierte Adresse betrifft die ULA. Der Namenskonflikt von avahi hat aber (das ist mein aktueller Kenntnisstand aus meinen Tests) nichts damit zu tun, wie die ULA aufgebaut ist. Ich habe es mittlerweile mit den drei Varianten ausprobiert, einmal gewürfelt, einmal mac-basiert und einmal komplett per Hand gesetzt. Immer dasselbe, keine Besserung. Die Annahme, die ULA ändert sich bei der Zwangstrennung war ja falsch. Worin sollte dann ein Unterschied für avahi bestehen, ob nu die oder die andere ULA?

    avahi meldet alle alten IPs ab und versucht, diese neu zu registrieren. Dabei kommt es zu einer Race-Condition, avahi stolpert und fällt hin. Warum sollte das davon abhängen, wie die IP erzeugt wurde? Das ist für mich nicht schlüssig.


    • avahi meldet die alte GUA ab und die geänderte GUA an. Da könnte ich nachvollziehen, dass es evtl. klemmt wenn die alte noch nicht komplett verschwunden ist und damit der Hostname unter zwei GUAs bekannt wäre. Aber Moment mal, das sollte doch auch nix ausmachen, denn mein PC (Opensuse Tumbleweed) hat ja zwei GUA gleichzeitig, hmmm. ahh, es ändert sich das Präfix und nicht die hinteren 4 Segmente. Das ist hier der entscheidende Unterschied?
    • avahi meldet die ULA ab und registriert die selbe IP unter dem selben Namen wieder an. Hier passen IP und Hostname immer zusammen. Warum sollte hier ein Konflikt auftauchen?
    • avahi meldet auch lo ab und wieder an. Das sollte aber nix mit Hostnamen zu tun haben. Oder?


    Nach all dem Geraffel der letzten Tage ist für mich die Änderung der GUA der wahrscheinlichste Kandidat für den Namenskonflikt. Die ULA als Ursache macht für mich keinen Sinn.

    So würde ich mir das als Laie zusammenreimen. Wo liege ich falsch?

    Klar würde ich gerne wissen warum das ganze so ist wie es ist, doch scheint sich keine Lösung abzuzeichnen.

    Ich gehe jetzt den pragmatischen Weg.

    Aber wir wissen doch warum es so ist wie es ist.

    Ich wollte eigentlich zum Ausdruck bringen, dass ich mich wundere, warum das Problem noch besteht und noch nicht von offizieller Seite eine Lösung existiert. Wie schon gesagt, mein System ist kein Exot und da wundert's einen schon wenn es an so grundlegenden Sachen klemmt.

    Wenn Du auf einem deiner PI5 nicht auf IPv6 angewiesen bist, könntest Du temporär (für ca. 4 Wochen) das IPv6, mit Hilfe des Bootparameters, vollständig deaktivieren und beobachten. In der FritzBox musst Du nichts ändern. avahi funktioniert auch mit "IPv4 only".

    EDIT:

    Die einzige lange Zeile der cmdline.txt ergänzen:

    Code
    sudo nano /boot/firmware/cmdline.txt

    mit

    Code
    ipv6.disable=1

    und nach dem speichern, den PI5 rebooten.

    Meine PI benötigen für sich selbst zwar kein avahi aber aktuell IPv6 schon.

    Wenn mein cron-Script mit dem Restart von avahi nicht funktioniert und es weiterhin dazu kommt, dass Backups etc. nicht laufen weil avahi in meinem System meint, randalieren zu müssen, dann bleibt immer noch IPv6 abzuklemmen. Aber auch das ist "nur" ein Workaround um das Problem zu umgehen, nicht zu lösen. Mein Ansatz mit einem Neustart von avahi greift weniger tief in das bestehende System ein, als IPv6 abzuklemmen. Letzteres zöge weitere Anpassungen nach sich.


    Mein Script ist fertig und protokolliert die Namenskonflikte in einem einfachen Log-File. Das habe ich jetzt im Blick und dann sehen wir weiter.

    ...

    Danach auf dem PI 5 testen:

    Code
    host -t aaaa wandax.fritz.box 192.168.178.1

    (IPv4-Adresse der FritzBox evtl. anpassen).

    Code
    Host wandax.fritz.box not found: 3(NXDOMAIN)

    Ich habe jetzt wie viele Stunden in diesem Problem versenkt? Keine Ahnung! Das wird mir jetzt zu blöd. Klar würde ich gerne wissen warum das ganze so ist wie es ist, doch scheint sich keine Lösung abzuzeichnen.


    Ich gehe jetzt den pragmatischen Weg. Avahi bleibt am Leben und nach dem Zeitfenster der Zwangstrennung schaue ich mit einem cron-Job im Journal nach, ob ein Namenskonflikt aufgetreten ist und starte dann gegebenenfalls avahi einfach neu. Das ist zwar nur ein Workaround aber immerhin kehrt dann wieder Ruhe ein.


    Danke dir, rpi444, für deine Unterstützung und Geduld.

    Joachim

    EDIT:
    ...

    1. Wenn avahi den Hostnamen ändert, meldet es den neuen Hostnamen an den Kernel

    D. h. Du benutzt "avahi-set-host-name" aus dem package "avahi-utils" auf deinem PI, oder? Eine "richtige" Hostname-Änderung ist das aber nicht. Siehe dazu die Ausgaben von:

    Code
    which avahi-set-host-name
    cat /etc/hostname
    hostname
    hostnamectl status

    , wenn Du meinst, dass avahi den Hostname gerade geändert hat und sofort auch an den Kernel gesendet hat.

    bewusst mache da gar nix, weil ich mich nicht auskenne. Die Aussage, dass avahi den geänderten Hostnamen an den Kernel sendet, habe ich aus anderer Quelle. Das passiert automatisch wenn avahi den Namen ändert und macht ja auch Sinn. Die anderen Angaben, z.B. unter /etc/hostname sind davon natürlich nicht betroffen. Die Änderung im Kernel ist nur temporär. Ein simpler Neustart von avahi schaltet zurück auf den eigentlichen Namen.


    Wie ist auf deinem PI, die Ausgabe von:

    Code
    dig -4 aaaa pi.fritz.box +short @fritz.box

    ? Siehe auch den Beitrag #21 in diesem Thread.


    ich kann das nicht in Echtzeit prüfen, denn die Zwangstrennung und der Namenskonflikt finden nachts um 3 Uhr statt. Ich sehe das nur, wenn ich später ein Ping mache oder mich per ssh aufschalten will. Einen weiteren Hinweis erhalte ich, wenn ein Backup fehl schlägt, das um 12:00 Uhr gestartet wird. Und es kommt auch nicht jedes mal vor.

    Jetzt gerade ist alles wieder korrekt hingebogen. Ich muss warten, bis es wieder vorkommt.

    Hier eine Erläuterung einer KI warum keine AAAA-Records ohne avahi vorhanden sind.


    Display Spoiler

    Bei IPv4 läuft alles über DHCP: Der Pi fragt per DHCP-Request eine Adresse an und schickt dabei (Option 12) seinen Hostnamen mit. Die FritzBox hat also immer ein Namen-Adresse-Paar direkt aus dem DHCP-Protokoll – unabhängig von Avahi/mDNS.

    Bei IPv6 sieht das anders aus. Die meisten FritzBoxen (auch deine 7530) vergeben IPv6-Adressen standardmäßig nicht per (stateful) DHCPv6, sondern per SLAAC (Stateless Address Autoconfiguration) über Router Advertisements. Ein Nutzer im deutschen Raspberry-Pi-Forum bringt es auf den Punkt: IPv6 benötigt keinen DHCP-Server – der Kernel generiert die IPv6-Adresse selbst, völlig ohne DHCP. Das Problem dabei: SLAAC/Router Advertisement transportiert keinerlei Hostnamen-Information. Der Pi konfiguriert sich seine IPv6-Adresse komplett eigenständig (aus Präfix + Interface-ID), ohne dass dabei irgendein "Hallo, ich heiße pi" an die FritzBox übermittelt wird. Raspberry Pi Forum

    Wie die FritzBox die Lücke schließt: mDNS

    Da der DHCPv4-Kanal für die Namensmeldung bei IPv6-Adressen schlicht nicht existiert, nutzt die FritzBox ersatzweise mDNS (Avahi), um herauszufinden, welche IPv6-Adresse zu welchem Hostnamen gehört. Genau das wird im selben Forumsthread bestätigt, wo als Workaround via mdns_minimal konfiguriert wird, damit avahi sowohl IPv4 als auch IPv6 unterstützt, was für die AAAA-Registrierung in der FritzBox nötig ist. Die FritzBox lauscht also im lokalen Netz auf die mDNS-Announcements (u. a. die AAAA-Records, die Avahi für die eigenen IPv6-Adressen des Pi verschickt) und übernimmt diese Zuordnung in ihre eigene .fritz.box-DNS-Zone. Raspberry Pi Forum

    Konsequenz beim Abschalten von Avahi

    Schaltest du Avahi ab:

    • Der A-Record (IPv4) bleibt bestehen, weil dieser Weg komplett unabhängig über DHCPv4-Option 12 läuft.
    • Der AAAA-Record (IPv6) verschwindet, weil damit der einzige Kanal wegfällt, über den die FritzBox die IPv6-Adresse des Pi überhaupt einem Namen zuordnen kann – es gibt schlicht keine andere Informationsquelle (kein DHCPv6 mit Hostname-Option im Einsatz, SLAAC liefert von Haus aus keinen Namen).


    Ob das so stimmt, kann ich nicht sagen, da weiß ich zu wenig drüber. Es klingt aber schlüssig und passt zu dem was ich hier erfahre.

    ich habe weiter getestet.

    1. Die ULA ändern sich entgegen meiner ursprünglichen Annahme nicht. Da hab ich mich, warum auch immer, vertan.
    2. Wenn avahi auf den Pi nicht läuft, erreiche ich diese nicht über den Hostnamen, auch wenn ich fritz.box als Domäne angebe. Das verstehe ich nicht, denn die Fritzbox sollte doch ein vollständiger DNS-Server sein. Avahi registriert Adressen mit .local. Warum hat avahi auf fritz.box einen Einfluss?

    Mein Netzwerkproblem reduziert sich auf Punkt 2. Und das wundert mich doch arg, denn ich bin doch nicht der einzige, der eine Fritzbox als Router und DNS-Server betreibt und Linux-Clients hat die avahi laufen haben. Das ist dich eher der Normalfall.

    ich würde es kapieren, wenn avahi einen Namenskonflikt erkennt, daraufhin nicht pi.local, sondern pi-2.local registriert aber pi.fritz.box im Ruhe existieren lässt. Da stimmt doch was am Konzept nicht.

    Oder stimmt bei mir was mit dem DNS grundsätzlich nicht?


    EDIT:
    So langsam kristallisiert sich ein stimmiges Bild heraus.

    1. Bei der Neuregistrierung der IPs durch avahi nach der Zwangstrennung kommt es unter Umständen dazu, dass avahi zur falschen Erkenntnis kommt, es läge ein Namenskonflikt vor. Das kann man durchaus als Bug interpretieren, da avahi selbst sich durcheinander bringt.
    2. Wenn avahi den Hostnamen ändert, meldet es den neuen Hostnamen an den Kernel
    3. Dieser wiederum meldet den Namen bei einem DHCP-Request an die Fritzbox weiter und diese übernimmt ihn. Damit nimmt das Unglück seinen Lauf.

    Was jetzt bleibt, ist die Frage warum die Fritzbox keine AAAA-Records vetreibt wenn avahi nicht läuft. ... To Be Continued

    Ich muss den Sack noch einmal aufmachen. Dass avahi nicht gebraucht wird, hat sich als falsch herausgestellt.

    Sobald avahi abgeschaltet ist, vergibt die Fritzbox (7530 AX mit OS 8.25) für die Pi keine AAAA-Records mehr. Weiß der Deibel warum? Ist das ein Bug oder ein Feature?

    Ohne AAAA Record verweigert mein PC den Zugriff des Pi für das Backup, obwohl ich per rsync nichts auf IPv6 pinne, sondern nur piname.fritz.box in rsyncd eingetragen habe. Für meinen PC sind beide Pi jetzt über IPv6 nicht erreichbar. Das ist so keine Alternative.

    "Gehe zurück auf Los, gehe direkt dort hin." heißt es sonst wo.

    Mir sind jetzt mehrere Möglichkeiten im Sinn, wie ich die Kuh vom Eis kriege, ohne dass diese vollends absäuft.

    1. ULAs auf Basis der MAC-Adressen erstellen lassen
    2. festes Präfix für die ULAs in der Fritzbox eintragen, bzw. möglichst komplette lokale IP fest einstellen (oder ist das eine Fehlinformation und bringt nix?)
    3. Alles aus dem Fenster schmeißen ...


    Es hätte so schön sein können .... X(

    Nach diversen Recherchen habe ich mich entschlossen avahi komplett abzuschalten. Meine Pis verwenden es nicht und da nicht klar ist, was die eigentliche Ursache für die Namenskonflikte ist, ist das der einfachste und sicherste Weg, das Problem los zu werden.

    Seit zwei Tagen läuft alles ohne avahi und es passt.

    PE deaktivieren und abhängig vom Frontend (NM oder systemd-networkd oder ...).

    Was bedeutet PE? Ich bin nicht wirklich drin im Netzwerk-Sprech.


    Mich würde es vor allem interessieren, warum es überhaupt zu diesem Problem des Namenskonfliktes kommt. Avahi meldet die alten Adressen ab und versucht, die neuen zu registrieren. Dabei fällt avahi auf, dass der zu setzende hostname schon/immer noch belegt ist, genauer, dass es Dienste gibt, bei denen die Abmeldung noch nicht angekommen ist.

    Das was avahi macht ist doch eigentlich ein Standardverhalten und warum sollte das bei mir haken? Das muss einen Grund haben. An avahi bzw. dem ganzen Netzwerkdingens habe ich keine eigenen Änderungen vorgenommen.

    Was könnte die Ursache sein?

    Hallo,

    meine zwei Pi5 (Trixie) hängen an einer Fritzbox. Wenn die Fritzbox die Zwangstrennung durchführt und neue IPs vom Provider erhält, kann es vorkommen dass avahi ins trudeln kommt.


    Die alten Adressen werden abgemeldet und bei der Registrierung der neuen IPs (IPv6) erkannt, dass der Hostname (fälschlicherweise) schon vergeben ist. Danach ändert avahi einfach den Namen durch anhängen eines Suffix mit laufender Nummer. Das bricht dann weitere Netzzugriffe, da ja der Hostname nicht mehr passt und Zugriffe verweigert werden.

    Das kommt bei beiden Pis vor, doch bei einem deutlich häufiger. Nicht jede neue IP triggert das Problem auf beiden gleich oft. Komischerweise ist der Pi, auf dem eigentlich nichts läuft, außer einmal nächtens ein Backup, der empfindlichere und der mit Docker-Container, und anderem Geraffel, den juckt das weniger.

    Kennt das jemand? Wie kriege ich das gefixt?


    Joachim

    Zeige doch bitte einmal den genauen Aufruf von rsync. Also auch inkl. des systemd-Drumherums...


    zu sichernder Client

    rsyncd.conf:

    [admin]
    comment = Admin Global 
    path = /mnt/extend/admin_global 
    read only = yes 
    list = yes 
    uid = root 
    gid = root

    und rsync.service (nichts zur Standardinstallation geändert!)

    [Unit]
    Description=fast remote file copy program daemon 
    ConditionPathExists=/etc/rsyncd.conf 
    After=network.target 
    Documentation=man:rsync(1) man:rsyncd.conf(5) 

    [Service]
    ExecStart=/usr/bin/rsync --daemon --no-detach 
    RestartSec=1 
    Restart=on-failure 

    ProtectSystem=full 
    #ProtectHome=on|off|read-only 
    PrivateDevices=on 
    NoNewPrivileges=on 

    [Install]
    WantedBy=multi-user.target

    Aufruf vom Backup-Server via cron

    30 01 * * * /mnt/admin_global/backup/scripte/backup.sh backup

    und im Script selbst dann über rsnapshot

            /usr/bin/rsnapshot -c "${BACKCONF}" "${INTERVAL}"