April 2017 - Dev - Freifunk Nordwest

Offline-SSID
by Simon Kurka 19 Oct '17

19 Oct '17

Hallo zusammen, auf dem letzten Treffen kam nochmals die Frage nach einer Offline-SSID auf. Tarek möchte so eine grundlegende Entscheidung auf der ML diskutieren. Ich denke wir sollten eine Offline-SSID einführen. Diese muss nicht direkt vom Online-Status des Routers herrühren, sondern könnte auch durch ein fehlendes (Batman-)Gateway ausgelöst werden. Grund: Ohne Gateway Anbindung hat man nicht den erwarteten Zustand. Befindet man sich beispielsweise in Oldenburg und verbindet sich mit unserem Netz, erwartet man eine IPv4 und eine Publicv6 aus dem Oldenburger Bereich zugewiesen zu bekommen und mit jedem anderen im Freifunk Nordwest Netz und auch mit dem gesamten Internet Daten tauschen zu können. Für Nutzer, die auch die ganz grundlegenden lokalen Features nutzen, sollte es kein Problem sein sowohl Offline- als auch Online-SSID zu speichern / sich damit zu verbinden. Wenn wir das nicht tun provozieren wir an reinen Mesh-Routern ohne Anbindung ein Offline-legen der User. Die Geräte verbinden sich mit Freifunk, schalten mobile Daten ab und sind offline. Außerdem kann es auch beim Ausbau unterstützen: Mein Blick in der Oldenburger Innenstadt geht gerade dahin, wo ich einen Uplink her bekomme, obwohl ein weiterer Routerstandort auch ohne cool ist. Ich werde aber keine Router aufbauen, die von vornherein offline sind und Nutzer beeinträchtigen. Mit Offline-SSID kein Problem und die Geräte würden sich auf die normale SSID konfigurieren, sobald ein Uplink-Router in der Nähe ist. -- Viele Grüße, Simon

7 17

Neue Hoods - Bentheim - Emsland - Cloppenburg - Bad Iburg
by Johannes Rudolph 09 May '17

09 May '17

Moin zusammen, nach dem Update ist vor dem Update. Unser Freifunk Netz wächst und wächst in der letzten Zeit verdammt schnell. Dank unseres Hoodsystems und des Hoodselectors können wir darauf mittlerweile relative einfach darauf regaieren. Daher habe ich zusammen mit Stefan bereits die nächsten Schritt geplant. In dem Bereich Nordwest sind mittlerweile überall Hoods, die letzten weißen Felcken haben wir mit dem Letzten Update (20170410) beseitigt. Aktuell sind ca. 65 Router in der Default Hood, das sind all diese, die nicht auf der Karte sind und keine Koordinaten haben oder ausserhalb unser Region sind. Stefan und ich haben uns überlegt nun uns an die „großen“ Hoods zu wagen und diese sinvoll zu unterglidern. Die Hood Südwest ist da so ein Kandidat, aktuell auch die größte Hood mit 200 Routern. Diese soll in 3 Hoods mit geografischen Bezug aufgeteillt werden in: - Landkreis Grafschaft Bentheim - Landkreis Emsland - Landkreis Cloppenburg Die Zweitgrößte Hood „Landkreis Osnabrück“, dort würden wir Bad Iburg in eine separate Hood verfrachten, da dort auch eine Menge von Routern auf kleiner Fläche installiert sind. Mein Vorschlag für die neuen Hoods findet ihr hier. Wenn hier keine Einwände kommen würde ich zeitnah eine neue Firmware bauen. Das neue Hoodfile habe ich hier zum Entwurf:https://git.ffnw.de/snippets/15 Man kann es sich wie gewohnt mit unserem Hoodgen anschauen https://hoodgen.ffnw.de Stefan hat das ganz Serverseitig bereits alles vorbereitet. Die Sachen kann man auch hier sich anschauen: https://mw.ffnw.de/Hood_IP_Netze Gruß Johannes Von meinem iPhone gesendet

3 5

Hoodselection Bug Mesh
by Simon Kurka 01 May '17

01 May '17

Hi, > root@ffnw-8416f99be428:~# hoodselector > No VPN connection found > Batman gateways found > Set hood "default" > Hood set by batmanHasGateway mode, GW source is wifi Steht mitten unter Oldenburger Routern, kein Default Router in Sicht. Offenkundig ein Bug. -- Viele Grüße, Simon

2 1

Logread Raspi 2
by Sebastian Wolzenburg 27 Apr '17

27 Apr '17

Moin zusammen, gestern einen Raspi 2B (1GB RAM 4x 0,9Ghz) als Offloader aufgesetzt mit aktueller Stable FW (fastd). Im Logread sehe ich folgendes: https://pastebin.com/gRma3Xfa Screenshot davon auch noch im Anhang. Liegt das am Loglevel, oder muss ich mir Sorgen machen :) Danke! -- Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian(a)freifunk-ibbenbueren.net

1 1

Sign Request 20170421
by Johannes Rudolph 27 Apr '17

27 Apr '17

Hi zusammen, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20170421 * Gluon-Version: v2016.2.5-1-g03fc7b8e * Download: https://firmware.ffnw.de/20170421/ Folgende Änderungen gab es: * hoodselector: remove upper function by scan #102 * hoodselector: filter redundancy networks #105 * hoodselector: prepare scanmode for handling ibss and mesh #103 * hoodselector: filter Own Respondd with Mac address * hoodselector: 802.11s support * hoodselector: delete all running wifi interfaces except ibss #103 * hoodselector: fix wrong function parameter on #99 * hoodselector: get location fix nil returned by uci fault #100 * hoodselector: set default hood in state scanmode #99 * hoodselector: replace stderr with stdout * Move Hoodselector Control to Own Package hoodselectorctl and add it * Hoods: Add Hood Landkreis Grafschaft Bentheim * Hoods: Add Hood Landkreis Cloppenburg * Hoods: Rename Südwest to Landkreis Emsland * Hoods: Add Hood Bad Iburg * Hoods: Emden-Leer-Aurich improved boarders * Hoods: Add Second Fastd Instance for Default Hood Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/siteconf/compare/201704...johannes%2F2017… Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/packages/compare/201704...johannes%2F2017… Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firm… Nach dem die Firmware signiert wurde werde ich die entsprechenden Tags im GitLab setzen und in die entsprechenden Branches mergen. Parallel zu der Stable baue habe ich auch eine Testing Firmware gebaut und die gibt es die hier: https://firmware.ffnw.de/20170421_testing/ Viele Grüße Johannes Rudolph

5 6

neuer runner verfügbar
by Bjoern Franke 26 Apr '17

26 Apr '17

Moin, ich habe gestern abend einen neuen runner02 auf srv19 eingerichtet. Specs: - 8 cores - 16 GB RAM - 750 GB HD Erreichbar ist die VM nur per IPv6, sie kann aber auch per IPv4 raustelefonieren. Grüße bjo

4 4

Wechsel auf IEEE802.11s Diskussion
by Jan-Tarek Butt 21 Apr '17

21 Apr '17

Hallo zusammen, Vor ein paar tagen habe ich den Support für IEEE802.11s im hoodselector in den master gemerged. wir können nun also mit dem Abschluss des Milestones auch IEEE802.11s zur Verführung stellen. Es besteht noch ein issue #87 was ich hier zuvor nur besprechen wollte. Wenn wir jetzt einfach ibss und IEEE802.11s parallel über das gesamte Netz aktivieren, dann würde sich die Link Anzahl pro node verdoppeln. Da ja zwei nodes über zwei verschiedene Interfaces untereinander sichtbar sind und nicht wie zuvor nur über ibss. Das würde somit auch den Management traffic erhöhen. Im issue #87 geht es um die Überlegung eines workearound zum Wechsel auf IEEE802.11s, Gründe dafür s.u. Mein Ansatz wäre eine Erkennung von Nachbarroutern einzubauen um zu ermitteln ob ein Router ein und den selben Nachbarrouter sowohl über 11s als auch über ibss sieht. trifft das auf alle Router in der Umgebung zu schaltet der Router das ibss ab. Dazu kommt das die Router z.b. immer zwischen 24-6 Uhr einmal Täglich später wöchentlich nach Freifunk Routern schauen soll die ibss aktiv haben. Um eine Abwärtskompatibilität zu ermöglichen. Die zeitlichen Intervalle währen jetzt erst mal Platzhalter. Vorteil von IEEE802.11s gegenüber IBSS ist mehr Hardware Support. Probleme mit dem ath9k bug werden damit nicht behoben da der Bug unabhängig davon im Treiber ist. Das wird mit lede und insbesondere mit ath10k deutlich besser (WIP). Der workaround soll im Milestone 201705 Erstmal nur besprochen werden ( diese Mail ). schöne Grüße Tarek

1 0

Sign Request 20170410
by Johannes Rudolph 21 Apr '17

21 Apr '17

Hi zusammen, wer nicht arbeitet macht auch keine Fehler! niemanden ist es aufgefallen, auch die die Signiert haben nicht, im Hoodfile fehlten für die neue Hood von Ibbenbüren die Serverdaten. Diese sind nun mit drin und auch bereits von mir was das angeht getestet. Auch 8 Augen machen mal einen Fehler. Stefan und ich habe das Firmwareupdate für die 20170409 mittlerweile gestoppt. Alle anderen 500 Router sind problemlos durchgelaufen ;) Bitte noch mal prüfen und signieren, dass wir die neuen Hoods ausrollen können, danke ;) Basisdaten: * Firmware-Version: 20170410 * Gluon-Version: v2016.2.5 * Download: https://firmware.ffnw.de/20170410/ Folgende Änderungen gab es: * Serverdaten für Ibbenbüren: https://git.ffnw.de/ffnw-firmware/packages/commit/987df0dd52d9aa440532901ee… Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/packages/compare/master...johannes%2F2017… Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firm… Viele Grüße Johannes Rudolph

5 9

Hoodfile, Hoodselector mehrere Tunnelprotokolle
by Johannes Rudolph 19 Apr '17

19 Apr '17

Moin zusammen, ich würde gerne das Hoodfile Format wie folgt anpassen, um damit unterschiedliche Tunnelprotokolle einbinden zu können. Am Beispiel an l2tp und fastd würde ich das so machen: [ { "name": "astest", "bssid": "02:CA:FF:EE:BA:AA", "defaulthood": true, "servers": [ { "host": „fastd.ffnw.de ", "port": "10000", "publickey": „22e270ff9b2d1017c3a0b00dd22a58ef7e5915a355eeb16f0b8b52d7eb377869“, "type“ : "fastd" }, { "host": „l2tp.ffnw.de ", "port": "10000", "type“ : "l2tp" } ], "boxes": [] } ] damit könnte dann auch der hoodselector dementsprechend später je nach Tunnelprotokoll die richtigen daten finden an hand der Property „type“ Sollten nochmal andere Protokolle dazukommen könnten wir diese dann einfach ergänzen. Hat der Hoodselector seine entsprechende Hood gefunden schaut er einfach nach den entsprechenden Peers mit dem jeweiligen Typ. Ich würde dann bei Zeiten mal den Hoodgen und den Hoodselector dafür anpassen. Grußß Johannes

4 5

Sign Request 20170409
by Johannes Rudolph 15 Apr '17

15 Apr '17

Hi, Aufgrund eines neuen Gluon Release ziehe ich meinen vorherigen Sign Request der Version 20170406 zurück und stelle direkt einen neuen auf Basis des neuen Gluon Releases Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20170409 * Gluon-Version: v2016.2.5 * Download: https://firmware.ffnw.de/20170409/ Folgende Änderungen gab es: * Hoodselector: * Johannes: * Hoodselctor sysupgrade fest * Hoodselector kann über kommandozeile ein und ausgeschaltet werden * https://git.ffnw.de/ffnw-firmware/packages/blob/master/hoodselector/README.… * Tarek: * respondd add "get bssid falback" for radioless devices * add hoodfile bssid to molwm tbl for respondd * molwm add bssid default state * add difference bssid source on molwm choose VPN router befor mesh router. * fix #92 and drop first molwm neighbor because its node it selfe * Banner * Zeigt nun die gewählte Hood mit an, wird im /tmp gespeichert also im RAM und wird alle 2 Minuten neu erstellt * Hoods: * Add New Hoods: * Ibbenbüren * LK Wesermarsch * Südost * Modify: * Wittmund * Friesland * LK Vechta * Steinfurt * Rastede * site.conf * drop v4 next node addr * drop prefix4 for mesh * Alte VPN Peers aus der Site Conf gelöscht. Nur noch der Eine VPN Peer des Default Netzes Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/siteconf/compare/20170222...johannes%2F20… Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/packages/compare/20170222...johannes%2F20… Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firm… Nach dem die Firmware signiert wurde werde ich die entsprechenden Tags im GitLab setzen und in die entsprechenden Branches mergen. Parallel zu der Stable baue ich auch eine Testing Firmware diese sollte heute im Laufe des Tages fertig sein und dann gibt es die hier: https://firmware.ffnw.de/20170409_testing/ Viele Grüße Johannes

6 11