Autoupdate bei Spannungsversorgung aus anderen Freifunk Routern

Bei der PoE Spannungsversorgung aus einem anderen Router könnte es zu folgendem Szenario kommen:

  • A speist B über PoE
  • A startet ein Autoupdate
  • B startet ebenfalls Autoupdate innerhalb der nächsten 30 Sekunden durch Zufall
  • A startet neu und brickt durch Unterbrechung der Spannungsversorgung B

Muss Autoupdate auf speisenden FF Routern deaktiviert werden?

Sobald die relevanten GPIO Parameter gesetzt sind könnte man Autoupdates automatisch verbieten.

1 Like

Ist das nicht nur durchgeschliffen? Ich meine mich erinnern zu können, dass die Spannungsversorgung auf dem 2. Port bei einer Rocket bestehen blieb beim Reboot, bin aber nicht mehr 100% sicher…

Ansonsten würde ich es dann so halten das beide Router das Autoupdate ausgeschaltet haben, stattdessen nen SSH Key damit man auf die Schnelle nen „autoupdater -f“ in der Shell machen kann - das aktualisiert auch mit ausgeschaltetem Autoupdate manuell auf den eingestellten Branch, wenn es eine neuere Version findet.

Bei der nanostation m2 mit manuell aktivierten GPIO Ausgang in der /etc/rc.local wird bei reboot getrennt. Man kann auch schön sehen, dass die Power erst nach ausführen der o.g. Datei zurückkehrt.

Genau das habe ich gemacht. Vermutlich wird da nicht jeder dran denken. Ich sehe ein ‚the brickening‘ in ein paar Jahren, sollten wir keinen Automatismus erfinden.

3 Likes

Ohje ohje, absolut!

Russisch Roulette beim Releasen von neuer Firmware.

2 Likes

Als Notnagel setzt man die Propability auf 0.1 (oder noch niedriger)…
Russisch Roulette mit größerer Trommel…

2 Likes

Probability gibt’s im neuen Autoupdater nicht mehr in der Form (siehe Doku auf Autoupdater — Gluon 2021.1 documentation).

Stattdessen wird bei der Erstinstallation ein zufälliger Zeitpunkt zwischen vier und fünf Uhr morgens gewählt an dem die Updates überhaupt stattfinden (Es gibt noch ein Fallback, falls NTP nicht läuft). Es dürfte also so schon ziemlich unwahrscheinlich werden, dass zwei solche Knoten gleichzeitig Updates machen.

Falls das Problem relevant werden sollte, könnte man die Knoten mittels gluon-announced und gluon-neighbour-info dazu bringen zu erkennen, ob so eine Konstellation vorliegt und die Zeitpunkte der autoupdates so anpassen, dass es völlig ausgeschlossen ist.

1 Like

Ein zufällig gewählter Zeitpunkt innerhalb einer Stunde? Das klingt für mich fast nach einer Kollisionsgarantie!

Coole Lösung! +1

1 Like

Die Wahrscheinlichkeit liegt unter 3,3%, wenn man nur zwei Knoten hintereinander schaltet und ein autoupdate zwei Minuten in der kritischen Phase verbringt.

Als Workaround kann man /lib/gluon/cron/autoupdater editieren und z.B. die 4 in eine 2 bei einen der Geräte ändern.

Ich habe dazu gerade ein Issue für Gluon angelegt, so dass wir diesen Fall nicht vergessen, wenn wir irgendwann Support für PoE-Chaining einbauen.

1 Like