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
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.
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?
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.
Hm, im Prinzip nichts. Aber wie erkennt man dann, wenn später WAN doch verfügbar ist?
Wie gesagt, das ist Code den ich lieber nicht anfasse. Die ganze State Machine ist extrem schwer zu durchblicken, und natürlich alles in C d.h. jeder kleine Fehler ist fatal. Wir haben offenbar auch irgendeinen Bug drin, denn wir haben immer mal wieder einen Client der reihum alle 10s jeden Server mit einer Anfrage nervt und dann mit der Verbindung doch nichts macht… bisher hat mir da leider noch niemand ein Log schicken können.
wie bei dhclient: retry-wait hochsetzen mit wiederholenden Fails bis zu einem max-Wert.
Irgendwas ala „nach 3 Fails-in-row, retry-wait verdoppeln, sofern retry >3600“
