Tunneldigger-client Retryverhalten

Derzeit scheint es mir so zu sein, dass sowohl die 5s retry für die Broker-Selektion, als auch die 5s nach Zusammenbruch eines Tunnels hardcodiert sind.
Wo letzteres auch meines Erachtens kürzer sein könnte, so finde ich einen statischen Retry „wenn offline“ problematisch.

Insbesondere auf Knoten an denen MoW aktiviert wurde und kein WAN angeschlossen ist (aber falsch eingestellt wurde) verursachen diese ständigen dns-Requests und restarts einen überflüssigen Overhead. (ob das Logspamming nicht von einem systemd/journald besser dedupliziert werden sollte: kann man sich streiten, sparsameres logging in so einem Szenario wäre schon irgendwie nett)

Und bevor jemand schreibt „selbst schuld, den Knoten falsch einstellstellen!“:
Ich behaupte nicht, dass es keine Fehlconfig ist, eine Minimierung der Auswirkungen wäre jedoch sinnvoll. Ein dhclient versucht schließlich auch seine Netzlast zu reduzieren, wenn niemand auf seine requests antwortet und vergrößert die Retry-Abstände)
Zeile 1428 und Zeile 1489 in

grafik

Irgendwie wäre ein langsamer Anstieg der Zeit bis auf eine Stunde sinnvoll. Ruhig am Anfang oft probieren, aber dann irgendwann nur noch stündlich.

Dann hätte man beide Fälle abgedeckt: Nach einem Verlust schnelle Wiederherstellung und bei Knoten, wo der TD auf Verdacht läuft keine zu hohe Belastung.

1 Like

Leider ist der Client eine ziemlich alte Codebase und in C geschrieben – ich finde es extrem schwer, da bei Änderungen sicher zu stellen, dass man keinen Mist macht. „Den Timeout schrittweise erhöhen“ führt extra State ein, das ist immer besonders knifflig. Einfacher wäre es vermutlich, irgendwie zu erkennen, ob überhaupt Internet auf dem WAN ist und das dann mit in Betracht zu ziehen.

Was gibt es dann an Möglichkeiten, so ein MoW-Gerät ohne WAN-Internet zu erkennen? Ich vermute mal es hat im WAN (gluon-wan) keine Default-Route oder so?

1 Like

Zumindest keine für legacy-IP.
Wenn da ein MoW aktiv ist, dann kommen da schonmal komische RAs herum.
Umgekehrt möchten wir ja tunneldigger ja gern auch für IP nutzen können (zukünftig?), wenn dort kein legacy-IP zur Verfügung steht.
Will sagen: Ja, die Abwesenheit einer IPv4-defaultroute auf gluon-wan es wäre heute vermutlich zu 99% ein sinnvolles Kriterium, aber nicht langfristig.

Was spricht dagegen, DNS-Auflösungs-Fehlschlag als ‚kein WAN‘ zu verstehen?

1 Like