<unnamed>

Public Key

npub15v4lkgrm7j684npdh2udfj8e38u0pzzj3c6ylph3nkxeju5az72qwcchpl

Profile Code

nprofile1qqs2x2lmypalfdr6eskm4wx5erucn78s3pfgudz0smcemrvew2w309qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds2mzfy0

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2026-01-20 07:11:01 UTC

- reply

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.

2026-01-19 22:19:57 UTC

- reply

Die Logik basiert auf der in Gluon eingebauten Idee das es zwei Quellen für die RAs gibt. Einmal der Knoten selber, damit es auch ohne Internet immer die Möglichkeit auf Lokale Kommunikation gibt.
Die anderen RAs kommen dann von unserem Gateway und haben dementsprechend auch eine default Route.

2026-01-19 07:23:04 UTC

- reply

Wir konnten gestern Abend endlich das Problem finden.
Der Autoupdater auf die Beta (und der Autoupdater der Experimental.) gehen endlich wieder.

2026-01-17 18:45:22 UTC

- reply

Prüf bitte noch mal ob der Autoupdater jetzt geht. Wir haben da noch einen Fehler gefunden beim Automatischen erzeugen der passenden Symlinks.

2026-01-17 17:14:17 UTC

- reply

Ja wir wissen das die MTU Niedrig ist. Vorher war die MTU 1348, was eine Zahl war bei der mehrere CLAT auf Android aus dem Tritt gekommen sind, und konsequent 20 Byte zu große Pakete versucht haben zu senden. Dadurch das wir nun 1280 als MTU setzen, scheint sich das Problem lösen zu lassen.
Gerne würden wir die MTU wieder vergrößern.
Welche DHCP-108 Zeitspanne wäre denn ein Üblicher Erwartungswert? Wir haben diesen Wert aus der IPv6 Mostly Demo der Ruhr Uni übernommen gehabt.

2026-01-17 17:07:33 UTC

- reply

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.

2026-01-16 19:46:12 UTC

- reply

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:
https://firmware.karlsruhe.freifunk.net

2026-01-16 16:54:35 UTC

- reply

Wir haben ein Setup mit Jool.
Haben uns bei Aufbau hier dran orientiert und es leicht angepasst an das Routing-Setup bei uns:
https://ipng.ch/s/articles/2024/05/25/case-study-nat64/

2026-01-16 12:55:34 UTC

Nachdem unser IPv6-Mostly Setup endlich halbwegs rund läuft, sind unsere NAT64 Server regelmäßig ans Limit der möglichen Verbindungen gekommen, die sie übersetzten können.
Wir haben deswegen noch, pro Server, 8 weitere IPv4 Adressen in unseren Pool geholt.
Da diese Adressen exklusiv für das das NAT64 sind, steigt die Kapazität auf fast das 10-fache.
So ist auch Stoßzeiten nun mehr als genug Luft nach oben und ihr könnt ohne Probleme weiter surfen!
#IPv6mostily #ipv6 #nat64