@goetz @tschaefer Für den Knotenbetreiber ändert sich gar nichts, die Config auf dem Node bleibt gleich.
Die neuste Firmware hat dann aber, einen lokalen Cache der automatisch unsere DNS64 Server nutzt.
DNS64 über DoT und DoH kommt auch noch, da muss der Moderisierungsprozess noch unsere Name-Server für erreichen, damit es passende Zertifikate ohne größeren Aufwand gibt.
Unsere Firmware gibt es hier:
Danke, dass ich das auch als Ortsfremder ausprobieren darf. Ein paar Dinge sind mir aufgefallen:
Die RAs sind vom Inhalt her nicht einheitlich. Es kommen zwei verschiedene (der individuelle und der multicast). Was auch zur Folge hat, dass die Clients drei verschiedene Resolver bekommen, zwei dns64 und ein "normalen" dns.
@tschaefer @goetz Feedback ist immer willkommen.
Das “Problem” an der Stelle ist der Resolver-Cache auf dem Knoten selber. Dein Node hat noch unsere aktuelle Stable Version aus 2025, bevor das v6 Mostly gestartet ist.
Da fragt der Cache noch die non-DNS64 Server.
Wir haben das zwar “hintendrum”umgebogen, aber bei neuen Knoten dauert es eine weile bis es greift. Du kannst aber Firmware ab Version 0.15.0 testen, da ist der default dann die DNS64 Server.
Mit dem Autoupdater komme ich nicht auf beta bzw. experimental. Ersteres geht gar nicht, letzterem fehlen Signaturen: "only carried 0 valid signatures, 1 are required"
Muss ich für den Wechsel von vorn anfangen?
beta:
autoupdater: warning: error downloading manifest: HTTP error 404
autoupdater: error: no usable mirror found
experimental:
only carried 0 valid signatures, 1 are required
autoupdater: error: no usable mirror found
Ist nicht so schlimm. Kann auch warten.
@tschaefer Wir konnten gestern Abend endlich das Problem finden.
Der Autoupdater auf die Beta (und der Autoupdater der Experimental.) gehen endlich wieder.
Update hat geklappt.
Jetzt steht erstmal Computerabstinenz (Sport)an.
Die DNS-Resolver scheinen jetzt einheitlich zu antworten. Mein Notebook stottert noch etwas beim Verbindungsaufbau. Die Logik hinter den sehr verschiedenen RAs (einer sogar mit und der andere ohne o-Flag) verstehe ich nicht. Aber ich muss auch nicht alles verstehen.
Das erklärt zumindest die Fehlermeldung vom Network-Manager, dass man zwar mit dem Netzwerk verbunden sei aber das Internet nicht erreiche.
(mit einem DNS Resolver)
Die Fehlermeldung erhielt ich sehr oft, also mit beta und stable.
(der Node hatte zu diesen Zeitpunkten definitiv einen funktionierenden Uplink)
Kann man den Ersatz-RA nicht einfach runterfahren, wenn der Node selbst online ist?
@tschaefer hast du die genaue Fehlermeldung für uns? Dann können wir besser verstehen was da vor sich geht.
Eine richtige online detection Logik haben wir bis jetzt nicht im Node intrigiert, zumindest nicht in einer Art und Weise die es uns relativ einfach macht den extra RA einfach abzuschalten. Wegen der niedrigen Prio und dem fehlenden Gateway sollte der so oder so von den meisten Systemen durch den unser Gateways überschrieben werden.
Der Network-Manager (Opensuse 16) bringt sinngemäß obige Meldung und hat dann, wenn ich mich nicht irre, ein Ausrufezeichen im Symbol. Da ich wenig Geduld habe, habe ich dann die Verbindung getrennt und erneut versucht.
Ich muss mal schauen, vielleicht kann ich dir auch die nm-logs schicken.
Rechne aber nicht vor heute Abend damit. Erstmal ruft der Broterwerb.
Andere Verbindungen werden zügiger aufgebaut. Das gesamte Logfile zur Verbindung liegt hier:
http://tschaefer.dynv6.net/nm.log
inklusive der schönen Meldung:
dhcp4 (wlan0): received option "ipv6-only-preferred": stopping DHCPv4 for 900 seconds
Nicht wundern, clat ist nicht im Logfile. Solange DNS64 aktiv ist, sehe ich bei mir keine Notwendigkeit.
Freifunk Karlsruhe
Thomas Schäfer