Wir ( @MPW, @Fungur und @descilla, begleitet von @paulinsche, @Alucardo und @LostInCoding ) haben gestern Abend und Heute einige ausgewählte Knoten (in Münster und im Kreis Warendorf) umgezogen.
Dabei handelte es sich sowohl um kleinere Mesh-Wolken, als auch um Knoten, die weit und breit niemanden zum Meshen haben. Dabei haben wir einige wertvolle Erkenntnisse gesammelt:
- Wenn Knoten, die nur über Mesh (on WLAN) angebunden sind sich die Firmware ziehen, kommt es häufig vor, dass sie die Datei nicht komplett herunterladen (erkennbar im nginx logfile) und folglich auch nicht Updaten.
- Diese brauchen i. d. R. mehrere Anläufe, bis sie die komplette Firmware erhalten haben und dann korrekt updaten.
- Leider versuchen die Router nach einem fehlerhaften Download es nicht direkt erneut, sondern lassen ein komplettes “Update-Intervall” verstreichen (derzeit meistens eine Stunde).
- Leider kommt es auch bei den Mesh-VPN only Routern kam es zu Problemen. Bei den ausgewählten Routern handelte es sich um keine Exoten. Alle Router hatten die aktuelle Firmware (v191) installiert, autoupdate war aktiviert und stand auf master-branch. In der Regel handelte es sich hierbei um TP-Link WR-841v9 Router.
- Ein (unserer Meinung nach zu hoher) Teil (schätzungsweise >~10%) der Router kam, nachdem sie sich das Update korrekt gezogen hatten nicht mehr online.
Konsequenzen:
- Mesh-Wolken in denen Router mehr als einen Hop zum nächsten Router mit VPN-Verbindung brauchen, sollten aus der automatischen Knotenmigration ausgeschlossen werden und gesondert einzeln umgezogen werden.
- Außerdem sollten unsere Skripte angepasst werden, sodass Mesh-Wolken mit schlechten TQ der WLAN-Mesh Verbindungen ebenfalls von der automatischen Knotenmigration ausgeschlossen werden.
- Bei den Knoten, die “einfach nicht mehr hochkommen” sollte die Ursache geklärt werden (wir sind aktuell bemüht Kontaktdaten zu erhalten). Eine wahrscheinliche Variante ist, dass die Knotenbetreiber nur spezielle ausgehende Ports erlauben (z. B. wenn die Router in einem Gastnetz hängen). In diesem Fall gilt es folgendes zu entscheiden.
- Reicht es einfach auf unseren PR-Kanälen dazu aufzurufen, entsprechende Ports freizuschalten? Wenn ja, wie lange warten wir?
- In einem recht aufwändigen Verfahren festzustellen, welche Router betroffen sind (fastd Server auf den fraglichen Ports in der Legacy Domäne laufen lassen und Knoten vor dem Umzug auf allen anderen fastd Instanzen zu blockieren)?
- Unser Konzept mit unterschiedlichen Ports für die Domänen über den Haufen zu werfen und alles wieder über unseren “Standardport” zu fahren. Mehrere Domänen über eine VM abzuwickeln wäre damit natürlich Geschichte oder zumindest sehr umständlich (mehrere public v4 & v6 Adressen auf eine VM werfen und alles dann noch passend konfigurieren).
Meiner Meinung nach sollte es reichen öffentlich dazu aufzurufen fragliche Ports zu erlauben und dann x Tage (x = [5,14]) zu warten.
Was meint ihr? Jetzt ist eure Meinung gefragt!