Wir haben nun die ersten Knoten auf die zunächst zwei zusätzlichen Segmente verteilt. In Sachen IPv6 müssen wir noch etwas tuning betreiben, aber einzelne Knoten und kleine Wolken mit wenigen Uplinks möchte ich schon mal zum Testen einladen.
Am schönsten für mich per pull request:
Ansonsten auch hier per Nachricht, seinen fastd Key bekommt man auf dem Knoten in der Kommandozeile so heraus:
/etc/init.d/fastd show_key mesh_vpn
Oder man bringt den Knoten in den config Mode und klickt einfach auf Speichern, dann wird er auch angezeigt.
Ein paar weitere Knoten sind schon rein gekommen, bitte darauf achten, das Knoten für das Stadtgebiet Aachen in den Ordner Segment-02 gehören, alle anderen in den Ordner Segment-03
Außerdem gilt:
Pro FastdD Key eine Datei, der Dateiname soll mit der NodeID wie sie in MeshVierwer zu finden ist beginnen und nach einem - zur Trennung als zweiten Teil den Nodenamen enthalten.
Derzeit ist bekannt dass in vielen Fällen IPv6 im neuen Segment nicht korrekt funktioniert. Ursache ist der auf den Knoten installierte radvd der ein IPv6 Prefix verteilt das so in allen Segmenten aktiv ist. Das kann nicht klappen, leider erkennen nicht alle Clients welches Prefix funktioniert.
Ein Autoupdate von Stable oder Beta zur Experimental ist nicht möglich.
Beim manuellen update muss der Autoupdater auf Experimental umgestellt werden, sonst wechselt der Knoten direkt wieder zur alten Branch:
/etc/config/autoupdate
Hier eine kurze Anleitung mit den nötigen Schritten um per ssh auf aktuelle experimental zu wechseln:
uci set autoupdater.settings.branch=experimental
uci set autoupdater.settings.enabled=1
uci commit autoupdater
echo 1 > /lib/gluon/release
uci set wireless.client_radio0.disabled=1
wifi
autoupdater
Das Client wlan wird fürs autoupdate abgeschaltet da es dann zu 100% zuverlässig funktioniert hat. Mit >20 Clients habe ich sonst teils mehrere Anläufe benötigt.
Außerdem definiere ich das aktuell die Firmware Version 1 läuft (mit dem echo >1) nur so wir wenn aktuell eine stable Firmware läuft die experimental als neuere Version akzeptiert.
Hi,
ich finde die Idee der dynamischen Segemntierung richtig klasse und würde gerne mit testen. Im Zugriff habe ich meinen lokalen Freifunkrouter (ffach-Gressenich-Bergerhof27-uplink) , der per Mesh on LAN ffach-Gressenich-Bergerhof27 bedient und dieser wiederrum über das WLAN mit ffach-Gressenich-Feuerwache vermeshed ist.
Reicht es aus den Uplink (der einzige mit Internetzugang) auf experimental zu ziehen, damit das meshen mit den anderen beiden noch funktioniert?
Oder muss ich die Kette von hinten bedienen. Also erst die Feuerwache hochflashen und zuletzt den Uplink?
Es ist genau anders herum. Die fastd Verbindungen haben wir in der Firmware schon recht lange eingeplant.
Ich war nur bisher die Hoffnung den IPv6 Prefix den die Knoten Verteilen nicht ändern zu müssen. Inzwischen sind wir der Meinung dies nicht vermeiden zu können und haben daher einen neuen Prefix für die Knoten festgelegt.
Es müssen also alle Knoten die Clients bedienen über die neue Version verfügen, reine offloader können auf Beta und Stable bleiben.
Die Beta Version baue ich jetzt, ich strebe eine Verteilung in der Nacht von Sonntag auf Montag an.
Nein, die Benennung der experimental ist leider diesmal so, dass man den Autoupdate auf experimalt sellen muss damit die Firmware sich nicht direkt zum aktuellen Beta/Stable ändert. Das mache ich in Zukunft wieder sinnvoller.
Die Beta ist seit eben im Bau, das dauert nicht lange. Ich würde an deiner Stelle kurz warten.
Ich habe die Beta8 nun auf einem Ubiquiti Bullet M und einer TP-Link TL-WR1043N/ND v2 installiert. Beide sind online und meshen mit ihren Kollegen auf Stable.
Ich bin schon sehr gespannt auf die automatische Verteilung, nun erstmal gebanntes warten aufs Autoupdate. Dienstag sollten es die meisten Knoten erhalten haben.
Irgendwelche Bedenken bezüglich der Grenzen wird es immer geben. Die Unterteilung von Aachen Innenstadt und Aachen Stadt Randbezirke ist sicher wegen der vielen Nodes sinnvoll.
Beim Umland würde ich es gut finden, wenn sich die Städteregion Aachen, der Kreis Düren und der Kreis Heinsberg klar trennen würden. Vielleicht wollen die Dürener/Heinsberger auf lange Sicht eigene Supernodes betreiben und dann wäre es gut, wenn das Gebiet entsprechend abgesteckt wäre? Auf jedenfall muss man sich so die Frage gefallen lassen, warum die Landkreise vermischt sind.
Dementsprechend würde ich das Segment 6 im Kreis Düren belassen und Würselen, Eschweiler, Alsdorf, Herzogenrath und Baesweiler entweder in ein neues Segment stecken oder zu dem Aachener und Stolberger Segment hinzufügen. Der Kreis Düren bestände dann aus zwei Segmenten und die Heinsberger hätten eines.
Anbei zwei Karten aus der Wikipedia mit den entsprechenden Landkreisen:
Ja, die Segmentierungs nach „Verwaltungsbereichen“ wäre auch eine Überlegung. Im Moment haben wir uns eher an geographischen Meshbarrieren orientier (Autobahnen und grüne Landstriche).
Wobei der riesen Vorteil an dem angestrebten System ist ja auch, dass eine spätere Umgestaltung „einfach automatisiert“ durch verschieben der Segmentgrenzen durchgeführt werden kann und die Nutzer es im Idealfall nicht mal bemerken.
Würde auch erstmal vorschlagen wir orientieren uns erst daran wie es technisch am besten läuft um die Kinderkrankheiten besser abfangen zu können (dazu braucht man z.B. kleine Segmente, damit Kurzschlüsse nicht ganz so schlimm sind).
Wenn Düren dann konkret eigene Supernodes allein für Kreis Düren betreiben möchte ist es natürlich noch möglich von Hand einen geographischen Bereich rauszuschnitzen.
Die Segmente sind in der Tat alles andere als statisch.
Im Stadtgebiet Aachen ist definitiv mit Knoten zu rechen die über die Grenzen hinweg meshen, diese werden dann in eines der beiden Segmente verschoben.
Technisch ist es ohne weiteres zu realisieren einzelnen Segmenten zusätzliche Supernodes hinzuzufügen die lokal finanziert werden.
Wir haben sogar schon zusätzliche Supernodes in der Firmware die nicht existieren. Schlicht als Reserve.
Momentan sind 50% unserer IPv4 Adressen in unserem default Segment gebunden. Die anderen habe ich jetzt komplett auf die Segmente 02-07 verteilt. Sobald ein Großteil der Knoten verschoben ist soll das default Segment auch nur noch ein /20 Netz haben. Wir haben also bald wieder Raum für weitere Segmente. 1,8,9,10 sind schon in der Firmware. Doku im Wiki: https://wiki.freifunk.net/Freifunk_Aachen/IP-Adressen
Ok, dann halten wir fest, dass die Aufteilung rein technisch ist und mit wenig Aufwand geändert werden kann. Dann kann es gerne (meiner Meinung nach) so bleiben und die Orientierung an natürlichen Grenzen (Wald, Autobahn) ergibt natürlich auch Sinn. Wenn ihr einen Blogeintrag für den Rest der Welt schreibt, sollte mit 2-3 Sätzen vielleicht erwähnt werden, warum die Grenzen so sind und das sie bei Bedarf verschoben werden können.
Die gesamt load pro Kern (von je 4) ist dabei auf den Supernodes mit schwächerer CPU etwas gestiegen. Diese bedienen nun aber auch viel mehr Knoten als zuvor. Dafür ist auch der Traffic Richtung Exit Nodes nenneswert höher, ohne einen entsprechenden Anstieg des gesamt Traffics. Unser prozentualer Overhead ist also geringer geworden.
Falls sich jemand fragt, wieso das Default-Segment noch so voll ist:
Einerseits sind dort im Moment noch alle Knoten die keine Geo-Koordinaten haben und auch keine Mesh-Partner haben durch die man auf eine Position schließen kann. Das ist ca. die Hälfte.
Die andere Hälfte sind inkompatible Firmwares, meist weil die Leute den Autoupdater abgeschaltet haben, oder auch weil Eigenbau im Einsatz ist. Diese Leute sollten dringend eine neue Firmware flashen, weil sie sonst bald keinen Zugang mehr zu unserem VPN haben werden!
Anleitung zur Reaktivierung des Autoupdaters: Howto: Autoupdater aktivieren - Freifunk für Aachen, die StädteRegion und Umgebung
(Dieser drastische Schritt wird notwendig weil wir die IP-Netzstruktur komplett umgemodelt haben, und wir nicht das alte ac01 Legacy-Netz auf ewig drin haben wollen. Außerdem würde ein solch alter Knoten der mit einer neuen Wolke mesht die gesamte Wolke notgedrungen ins Default-Segment ziehen.)
Ebenfalls betroffen sind die TP-Link WR841 v10, da wir für diese nur eine master-Branch-Firmware als Übergangslösung zum Download angeboten haben, aber auf Autoupdate verzichtet haben. Das sollte mit dem nahenden Release von Gluon 2016.1 aber spätestens behoben sein, dann kriegen die ebenfalls ihr Autoupdate.
