Freifunk-Treffen 2019.02

Orginaler Blog-Post: https://freifunk-kreisgt.de/event/freifunk-treffen-2019-02/

Save the Date: wir treffen uns in Gütersloh im Februar wieder am zweiten Montag, also am 11.02.2019, um 20 Uhr im Syrtaki.

Tagesordnung siehe Forum; geplant:

 - Status Netz/Infrastruktur (insbes. nach Upgrade auf FW 1.0.0)
 - Firmware 1.0.1 — Priorisierung der Änderungen?
   - fastd => L2TP/Tunneldigger (Hintergrund: Speed)
   - batman v14 => batman v15 (Hintergrund: Software­aktualisierung)
   - IBSS => 802.11s (Hintergrund: Unterstützung neuer, aktueller Routermodelle)
 - Status Feinstaubprojekt (FSuB, Makerspace, FFGT)
 - Gründungsmitglieder "FFGT e. V." — wie finden?
   - Hintergrund: Zugang zu (Landes-) Förderungen
 - Sonstiges

Zur Info: Jene Änderungen haben unterschiedliche Auswirkungen, sind aber jeweils im Netz/Mesh draußen “disruptive”, sprich: Knoten mit alter Firmware kann nicht mehr mit Knoten mit neuer Firmware meshen (mit Ausnahme fastd/l2tp).

Wichtig wäre die Umstellung des Mesh-Verfahrens, da IBSS zunehmend, zugunsten von 802.11s, nicht mehr (funktional) implementiert wird.

Die Batman-Version hingegen ist primär für die Systembetreuer ein Thema, sie müssen nämlich die in aktuellen Kerneln vorhandene v15-Inkarnation durch einen v14-DKMS-Build ersetzen. Nervt, aber nicht kriegsentscheidend.

fastd durch L2TP zu ersetzen schließlich reduziert die CPU-Last auf Knoten und Gateways, ermöglicht wahrscheinlich mehr Durchsatz je Knoten.

Jede Änderung (außer IBSS => 802.11s) bedingt neue/anders konfigurierte Gegenstellen (Gateways).

Ich würde dies gerne über den nächsten “rawhide”-Build mal testen — es hat den geringsten Impact, testet gleichzeitig die “ziehe Update-als-Client”-Variante bei allen Mesh-only-Knoten und hat den größten Nutzen (4040 und andere Geräte, insbesondere die mit Mediatek-Chipsatz, funktionieren nur mit 802.11s vernünftig/überhaupt).

@m.bitterlich und @charrr, das betrifft auch Eure Installationen (Müritz/Feldberg), da die Auswahl des Meshmodus bestimmte Einstellungen in der Firmware triggert. Wobei, auf rawhide stehen derzeit nur 4 Geräte in Feldberg (0 an der Müritz), davon mesht auch nur 1 => Christoph, bitte go/no-go geben :wink:

@m.bitterlich und @charrr, das betrifft auch Eure Installationen (Müritz/Feldberg), da die Auswahl des Meshmodus bestimmte Einstellungen in der Firmware triggert. Wobei, auf rawhide stehen derzeit nur 4 Geräte in Feldberg (0 an der Müritz), davon mesht auch nur 1 => Christoph, bitte go/no-go geben :wink:

von meiner seite: go

die knoten befinden sich alle in näherer umgebung, so dass ich auch vorort was machen kann, falls irgendwas schief läuft

Cool, 1.0.1~0 is building :wink:
-kai

rawhide ist nun 1.0.1~0 (in ca. 60 Minuten dann 1.0.1~1 — hatte vergessen, die ganzen ramips*-Targets mitzubauen) und sollte per 802.11s statt Ad-Hoc/IBSS meshen.

Läuft! :sunglasses:

Interessanter ist der hier (mesh-only):

Hast Du da nachgeholfen, oder hat der sich zufällig vor seinen Uplink-Knoten das Update gezogen?

Hast Du da nachgeholfen, oder hat der sich zufällig vor seinen Uplink-Knoten das Update gezogen?

Der lag hier noch mit Stock Firmware rum und ich hab ihn vorhin direkt mit der 1.0.1~0 geflasht.

Wenn ich irgendwas testen soll > Bescheid sagen.

Es wurde gestern Abend auch noch ein Bau des „master“-Zweiges der Firmware angeworfen (1.1.2, basierend auf Gluon-Unterstützung v2018.2), sodaß die 4040 nun auch per 802.11s mesht. Testweise wurde ein 841er ‚demeshed‘, indem die SSID falsch eingetragen wurde: dieser hat sich brav nach ca. 3h die neue Firmware mit 802.11s-Verfahren gezogen und ist seit dem wieder erreichbar — das separate Dreieck unten links ist 802.11s, der Rest noch Ad-Hoc/IBSS:

Ich werde meine Knoten Mal alle auf „rawhide“ stellen und abwarten …

So, nachdem mein 841er Knoten dank Rawhide sich die neue Firmware gezogen hat und kein Mesh mehr aufbauen wollte / konnte. Habe ich gerade händisch meinen Archer C7 auf die neue Version gebracht, und siehe da, Mesh per 802.11s klappt auf anhieb.

Vielleicht eine Sache die man schnell durch ziehen kann, nachdem wir es im Experimentel Umfeld etwas getestet haben.

Ein Parallel Betrieb von IBSS und 802.11s ist nicht möglich oder macht keinen sinn / bzw. mehr Probleme, richtig1?

IBSS & 802.11s parallel ist möglich, überlastet aber kleine Router (841 bzw. generell 4/32er Kästen) evtl. — und das hieß es 2016, als der Speicherbedarf noch geringer war. Kurzum: ist ein Risiko. Ferner bauen einige Targets nur noch bei 802.11s als Mesh-Protokoll (dies muß man seit Gluon v2016, 0.7.9 bei uns, vor dem Firmware-Bau angeben) — bei Geräten mit neueren 5-GHz-Chips ist hier tatsächlich eine andere Firmware im Spiel.

Kurzum: da wir die Funktion „Offline-Autoupdater via Freifunk-AP“ sowieso für den Wechsel batman-adv v14 auf v15 brauchen, würde ich den Wechsel von IBSS => 802.11s gerne als Generalprobe dafür nutzen.

Ich habe gegen 15:55 meine APs zu Hause alle auf „rawhide“ umkonfiguriert und dabei dafür gesorgt, daß 3 Knoten keinen IBSS-Link mehr hatten (dafür hatte die ich Knoten mit Kabel-Uplink per „autoupdate“-Aufruf vorzeitig auf 802.11s gebracht):

Ohne weitere Änderungen, rein durch Zeitablauf, sieht es gegen 18:55 so aus:

Heißt: 2 der 3 Knoten haben sich, nach >2h Offline-Zeit, eine neue Firmware gezogen — jene mit 802.11s.

… und vor 7 Minuten auch Nummer 3:

Ich würde das insofern gerne auf „experimental“ ausweiten, aber da gilt dann, daß Knoten, die auf „testing“ oder „stable“ stehen und über keinen eigenen Uplink verfügen, bis zum nächsten Schritt offline sein werden.

Ablauf wäre: nach 23 Uhr wird die Firmware auf „experimental“ gehoben, binnen der nächsten Stunden sollten sich dann alle Knoten aktualisieren – temporär abgehängte nach ~3 Stunden – und morgens sollte der Spuk vorbei sein.

Ich stelle gleich einmal beide Knoten bei Lu-Hollenbeck auf Experimentel und deaktiviere bei einen von beiden am Netzwerkswitch die Verbindung. Mal schauen ob dann morgen alles noch läuft.

1 „Gefällt mir“

So,
Lu-Hollenbeck-1 und -2 sind auf experimental gestellt. Lu-Hollenbeck-2 hat zusätzliche keinen WAN Uplink mehr. Mal heute nacht abwarten.

(Lu-Hollenbeck-2 hat sich seit dem letzten Update regelmäßig neu gestartet. Das Problem hatte ich mit dem 841er Testknoten in Wiedenbrück auch schon einmal vor geraumer Zeit, wo die ersten 1er Updates bereit standen. Da hat ein neu aufstzen geholfen. Bei LU-Hollenbeck-2 würde das garantiert auch helfen. Das Problem tritt im zusammen hang auf, wenn auf den LAN Ports ein Client angehangen wird. Ich beobachte das mal weiter. Im Netz habe ich bisher aber noch keine änlichen großen änlichen Aufälligkeiten gesehen.)

Etwas zu schnell :wink: Ich wollte zumindest @charrr und @m.bitterlich nochmal highlighten, da insbesondere an der Müritz mehrere Funkstrecken mit experimental/testing-Knoten laufen, außerdem @ArnoSy, da unter “experimental”/“testing” auch Linkstrecken in Verl aufpoppten.

Außerdem kommt noch ein Blogpost, daß in der Nacht zu Freitag dann “experimental”-Knoten, und in der Nacht zu Samstag – oder, falls doch irgendwas hakt – zu Sonntag “testing”- und “stable”-Knoten dran kommen. Insbesondere “Linkbauer” sollten in der Zeit also ihre Funkstrecken im Auge behalten — bzw. haben sie dann ggf. die Info zum Nachlesen, falls Links nicht mehr tun.

Der Wechsel von AdHoc auf 802.11s ist in Gütersloh weitgehend durch:

07

Das war die „einfachste“ Änderung. Beim Wechsel der batman-Version spätestens werden alle(!) Knoten im Netz zeitnah mitspielen müssen — oder ›abgelinkt‹ werden. Vielleicht ein Punkt, der die Einbeziehung der Presse rechtfertigt?

Auf Facebook gibt es noch keine Serie für dieses Jahr, oder?
Bin heute dabei.

Ui, das Fratzenbuch bespielt überwiegend @cord, meine ich — seitdem ich da von extern meine Seite nicht mehr bespielen kann, guck’ ich da auch nicht mehr rein …