Mit der Firmware 1.1.5 beginnt auch die Auftrennung der großen Netze (Kreis Gütersloh und Müritz/Feldberg/Neubrandenburg) in kleinere Segmente.
Konkret teilen wir das Netz im Kreis Gütersloh auf in die Segmente Stadtgebiet Gütersloh, Stadtgebiet Rheda-Wiedenbrück sowie »Nordkreis« und »Südkreis«.
Aus dem Netz in der Müritz-Region wird für den Bereich der Feldberger Seenlandschaft ein eigenes Segment eröffnet; Neubrandenburg (z. Zt. unter fünf Knoten) teilt sich bei anderer SSID weiterhin das Netz mit der Müritz-Region.
Damit einher gehen Änderungen auf der VPN-Tunnel-Ebene: Nachdem statt zwei nun sechs getrennte Netzsegmente existieren, benötigen wir einen größeren Wertebereich an freizuschaltenden sogenannten »Ports«: statt nur (UDP-) Port 10000 (Kreis Gütersloh) bzw. 10169 (Müritz/Feldberg/Nebrandenburg), nutzt unsere Firmware nun die Ports 10000 bis 10099, jenachdem, in welchem geographischen Bereich sie eingesetzt wird.
Insgesamt nutzt Firmware 1.1.5 damit diese Verbindungen über vorhandene Internetzugänge:
Sollten wir das nicht in einem zweiten Schritt machen? Um erst einmal zu sehen, das alle Knoten in das neue Netz rüber kommen?
Sonst verlieren wir den überblick an welcher Stelle es hakt!
Wir sollten auch nicht vergessen, das u.U. viele Knoten Offline sind wegen dem Lockdown. So sieht es mir auf jeden Fall auf der Karte aus bei vielen die Langzeit Offline sind. (unter anderem sind einige Kneipen Offline, Fitnesstudios, und Vereinsheime, …)
Ist halt in der tng-FW drin; in der fastd-site.conf gehen alle ›Domänen‹, wie das im Gluon-Sprech heißt, entweder auf die 4 fastd-Server für GT oder die 2 für Müritz. In der l2tp-site.conf haben gut, gto, gt8, rhw sowie wrz/neb und fsl jeweils andere v6-ULA-Adressen und Gateways.
Kann man rückbauen, zumal eh’ noch eine weitere tng-Firmware nötig ist: mit dem Schwenk auf tng als stable soll tng ja eingestellt werden — aber dann würden heutige tng-Knoten niemals mehr Updates bekommen. (Gleiches gilt für den, an der Müritz oft eingesetzten, master-Branch.)
Firmwarebuild 1.1.5~42 (sic!) würde Autoupdater von tng auf rawhide und von master auf stable setzen — und noch kein Mesh-Splitting vornehmen. Dennoch ändern sich die Ports, für Kreis GT von 10000 auf 10001 (Mesh GT Stadt) und an der Müritz von 10169 auf 10005 (Mesh Müritz).
Meine bedenken sind eher wegen der Port Änderungen. Einen Fallback Server mit 10000 Port geht nicht, oder? (Evtl. auch ohne Funktionalität. So könnten wir dann aber gezielt die Knotenbetreiber ansprechen und würden dann nicht nur einen Offline Knoten sehen)
Ist aktuell nicht vorgesehen, sprich gibt keinen. (Und wenn, dann müßten es ja zwei sein, Müritz lief seit jeher auf 10169.)
Es geistert allerdings die Idee herum, daß die Knoten nach Erstinstallation in ein »Default-Mesh« kommen und aus diesem dann per zentraler Konfiguration ins »Ziel-Mesh« verschoben werden. Damit könnten die Veränderungen an der Gluon-Basis weiter reduziert werden, was die Adaption neuerer Versionen beschleunigen könnte. Und im Zweifel auch wieder Offline-Konfiguration möglich gemacht werden — wobei es dafür bislang keine Nachfrage gab …
Bei denen hatte ich vor, sofern eingetragen, die Kontaktmailadresse mit einem Hinweis auf die Änderungen (Link zu den Beiträgen) einmalig anzuschreiben; möglichst als individuelles Ticket zwecks Nachverfolgbarkeit.
Die alten fastd-Gateways könnten sicherlich noch bis 31.03.21 oder so weiter laufen; ich hatte auch nicht direkt vor, am 01.02.21 00:00 diese runterzufahren. Ein Enddatum würde ich aber schon setzen wollen, und sei es, um die (v4-) IPs wieder freizubekommen.
Fallback in dem Sinne geht mit der Ansible-basieren Automatisierung auch nicht. Die Portnummer ermittelt sich aus, Pseudocode, »Port=$Portbasis + $Domainnummer«. Domainnummer ist ein numerischer Wert, mehr oder weniger willkürlich in einer Konfigurationsdateil festgelegt für alle Meshes.
Natürlich kann man in der Firmware l2tp-gut00.4830.org:10000 bei den »NRW-Meshes« und l2tp-wrz00.4830.org:10169 bei den »MeckPomm-Meshes« hinzufügen — und diese beiden Gateways bekäme man auch über Ansible deployed, denke ich.
Nur: dann würden sich Knoten zufällig mit einem der Gateways verbinden, also entweder mit ihren »richtigen« Meshes (Lokalisierung Stadtgebiet GT über Port 10001, Nordkreis über 10003, …), ggf. aber auch mit dem Fallback-Gateway. Sprich: wir würden in Kauf nehmen, daß wir die eigentlich getrennten Meshes über Knoten bridgen könnten (zwei Knoten mit WLAN-Mesh und zwei Uplinks, einer nach 10001, einer nach 10000) oder von Knoten zu Knoten sich die dahinterliegende Infrastruktur ändert (anderer v4- und v6-Bereich), die Clients also beim AP-Wechsel offline gehen.
Gefühlt haben wir im Kreis GT keine Handvoll Knoten, die auf Port 10000 festgenagelt sind — es ist kaum nachgefragt worden, was freizuschalten sei. Ich weiß von einem Autohaus, wo das vor ~5 Jahren relevant war. Aber ja, wir wissen es nicht.
Vielleicht weiß @charrr näheres? Bei den ERXen gibt’s ja ein seit Gluon v2020.1 bekanntes Problem (1.1.5~41 basiert aber noch auf Gluon 2018.2.x; keine Ahnung, ob es da auch zum Problem werden kann):
Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
das hatte ich schon erwartet. dort muss noch die portfreigabe in der firewall geändert werden. werde mal kontakt zum it dienstleister von denen aufnehmen.
können wir die Links der funktionierenden Karten als Linksammlung z.B. auf https://map.4830.org/? Ich habe mittlerweile drölfzig Links wo Karten sein könnten, aber es nicht mehr sind.
Ja, der virtuelle Webserver map.4830.org wird wohl auf eine Webserver-VM (web01.4830.org oder so) umziehen, dort dann auf die neuen Ziele für die kommunizierten Links (map.4830.org/ffgt, map.4830.org/mueritz) zeigen (per redirect denke ich). hopglass.4830.org und die anderen temporären Mapserver werden dann wieder eingestampft.
BTW, irgendwas ist mit dem Tile-Caching auf newmap.4830.org im Argen
Works, danke! Lustig; hat sich da »kürzlich« was bei OSM geändert? Weil, initial läuft’s, aber auch auf map03.4830.org zeigen sich erste Ausfallerscheinungen. Und auch die Münsterländer Karte zeigt bei mir nur noch grau — ihr Ansible hat da auch noch den $host-Header drin.
Hallo! Du (Kai ›wusel‹ Siering via Freifunk Kreis GT) hast geschrieben:
Works, danke! Lustig; hat sich da »kürzlich« was bei OSM geändert? Weil, initial läuft’s, aber auch auf map03.4830.org zeigen sich erste Ausfallerscheinungen. Und auch die Münsterländer Karte zeigt bei mir nur noch grau — ihr Ansible hat da auch noch den $host-Header drin.
keine AHnung. Mittlerweile zeigen ([abc].)?tile.openstreetmap.org alle
auf fastly und immer auf dieselben IPs.
Damit das da funktionieren kann muss man den richtiugen Host-Header
mitschicken.
Vielleicht haben die kürzlich erst umgestellt? Muss wohl:
