Archiv der Kategorie: Software

Neue Firmware Version 2020.2.2+mwu1 (testing)

Hallo Freifunker in Mainz, Wiesbaden und Umgebung,

ein paar Tage nachdem wir 2020.2.1+mwu2 im testing-Zweig veröffentlicht haben, gab es wieder einen neuen Gluon-Release. Dieser enthält verschiedene Bugfixes für batman-adv, fastd und den WLAN-Treiber des TP-Link Archer C50 v4.

Außerdem haben wir uns dazu entschlossen, den Patch https://git.io/JLYJ6, der schon seit etwa Mitte Oktober in unserer experimental Firmware enthalten ist, zurück zu portieren. Ohne den Patch kann es bei Android-Smartphones vorkommen, dass diese nicht auf IPv6 MLD Queries reagieren, was zur Folge hat, dass Verbindungen via IPv6 vorübergehend nicht möglich sind, wenn das Gerät einige Zeit inaktiv war.

Viele Grüße

das Firmware-Team

Outdoor-Modus, Legacy-Hardware, Legacy-Domains u.v.m.: Neue Firmware Version 2020.1+mwu1 (testing) veröffentlicht

Hallo Freifunker in Mainz, Wiesbaden und Umgebung,

nachdem es beim Thema Firmware bei uns in den letzten Monaten etwas still war, gibt es mit 2020.1+mwu1 wieder eine neue Testing-Version. Mit Gluon v2020.1 basiert die Firmware jetzt auf OpenWrt 19.07, das viele neue Geräte unterstützt. Die Liste findet ihr wie immer am Ende dieser Email oder in den Gluon Release-Notes.

Outdoor-Modus
Der Outdoor-Modus [1] stellt Knoten, die im Außenbereich installiert sind und im 5GHz-Band funken, automatisch so ein, dass sie sich an geltenden Regularien halten. Leider hat dies auch zur Folge, dass diese dann nicht mehr über 5GHz meshen können da der normalerweise verwendete Indoor-Kanal 44 nicht im Freien verwendet werden darf und der Kanal auch automatisch gewechselt werden muss wenn sich auf dem verwendeten Kanal z.B. ein Wetterradar befindet. Das 2,4GHz-Band ist von dieser Änderung nicht betroffen. Bei neu eingerichteten Knoten wird der Modus automatisch aktiviert, bei existierenden muss die Einstellung manuell umgestellt werden. Welche Geräte von der Änderung überhaupt betroffen sind könnt ihr unter [1] nachschauen.

Legacy Hardware
Ab dieser Version stellen wir für alle Geräte mit 4MB Flashspeicher und/oder 32MB RAM keine Factory-Images zur Verfügung, mit der neue Geräte geflasht werden können. Bereits exisitierende Geräte die in die Kategorie fallen, werden weiter mit Updates versorgt. Eine genaue Auflistung der betroffenen Geräte findet ihr in diesem Blog-Eintrag [2].

Legacy Domains
Die alten Domains ffmz und ffwi können im Config-Modus nicht mehr ausgewählt werden, sondern sind nur noch über die Kommandozeile einstellbar, da diese nur noch für Knoten am Mainzer oder Wiesbadener Backbone-Netz relevant sind. Wie die Konfiguration funktioniert wurde auf der Wiki-Seite [3] hinzugefügt.

Sofern mit der neuen Version keine Probleme auftreten, planen wir diese nach 4 Wochen zum neuen stable Release zu machen.

[1] https://gluon.readthedocs.io/en/v2020.1.x/releases/v2019.1.html#outdoor-mode
[2] https://blog.freifunk-mainz.de/2020/02/04/freifunker-prueft-eure-hardware-und-ersetzt-aeltere-modelle-mit-4-mb-flash-und-oder-32-mb-ram/
[3] https://wiki.freifunk-mwu.de/index.php/Howto/Backbone-Client

MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2020.1+mwu1
Gluon Source Code: https://github.com/freifunk-gluon/gluon/releases/tag/v2020.1
Gluon Release-Notes: https://gluon.readthedocs.io/en/stable/releases/v2020.1.html
Link zur Firmware: https://firmware.freifunk-mwu.de/testing

Happy Testing wünscht,
das Firmware-Team

Neu unterstützte Geräte:
8devices Jalapeno
Aerohive HiveAP 330
Aruba AP-303
Aruba Instant On AP11
ASUS RT-AC57U
AVM FRITZ!Box 7312
AVM FRITZ!Box 7320
AVM FRITZ!Box 7330
AVM FRITZ!Box 7330 SL
AVM FRITZ!Box 7360 SL
AVM FRITZ!Box 7360 (v1, v2)
AVM FRITZ!Box 7362 SL
AVM FRITZ!Box 7412
AVM FRITZ!Repeater 1200
devolo WiFi pro 1200e
devolo WiFi pro 1200i
devolo WiFi pro 1750c
devolo WiFi pro 1750e
devolo WiFi pro 1750i
devolo WiFi pro 1750x
D-Link DAP-1330 (A1)
Enterasys WS-AP3710i
GL.iNet GL-AR300M-Lite
GL.iNet VIXMINI
Netgear EX6150 (v1)
Netgear R6220
Netgear R7800
OCEDO Panda
OCEDO Raccoon
TP-Link Archer C20i
TP-Link Archer C20 (v1)
TP-Link Archer C2 (v1)
TP-Link Archer C50 (v1)
TP-Link Archer C6 v2
TP-Link TL-MR3020 (v3)
TP-Link TL-WA801ND (v5)
TP-Link TL-WR840N (v2)
TP-Link TL-WR902AC (v3)
Xiaomi MiWifi Mini

Neue Firmware Version 2018.1.3+mwu1 (testing)

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

nach dem großen Update auf Gluon v2018.1.1 gibt es mit v2018.1.3 wieder ein kleiner Bugfix Release. Nach der erfolgreichen Einführung der Multidomain-Funktionalität nutzen wir diesen Release und die zwei verbleibenden Firmware Images für Mainz und Wiesbaden in einem gemeinsames MWU Image zusammenzuführen. Zusätzlich haben wir die Domain Bingen hinzugefügt um dem Freifunk Bingen die Möglichkeit zu bieten ihre Knoten auf unsere Firmware zu migrieren.

Weiterlesen

Neuer Wizard hilft die richtige Firmware für euren Freifunk-Router zu finden

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

da es sich nicht immer einfach gestaltet hat die richtige Firmware zu finden, hat sich unser Julian mal hingesetzt und den Firmware-Selector vom Freifunk Darmstadt auch für Mainz und Wiesbaden eingerichtet.

Weiterlesen

Neue Firmware Version 2018.1.1+mwu1 (testing)

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

nach dem letzten kleineren Update auf 2017.1.8+mwu1 steht mit 2018.1.1+mwu1 wieder ein neues Major Release ins Haus. Gluon v2018.1.x bringt neue nützliche Features wie Multidomain und VXLAN die wir nach und nach einführen werden. Den Anfang macht dieser Release, in dem wir den Multidomain-Support aktivieren. Weiterlesen

Freifunk Hessen-Meetup 2018.2 vom 2.-4.11.2018 in Frankfurt

Die Frankfurter Freifunker laden ein zum nächsten Freifunk Hessen Meetup:

tl;dr: Anmeldung unter https://pretix.ffffm.net/ffffm/meetup18/ (for scale)

Bitte diese Ankündigung wieder an eure aktiven Freifunker verteilen/weiterleiten.

Liebe Freifunkende,

der Freifunk Frankfurt am Main e.V. lädt vom 2.-4.11.2018 zum Freifunk Hessen/Rhein-Main Meetup 2018 ein. Dieses ist das 7. Treffen der Freifunk-Communities aus Hessen und Rhein-Main.

Bereits am Freitagabend (2. November) geht es mit einem gemeinsamen und gemütlichen Abendessen los.
Am Samstag und Sonntag (3. und 4. November) treffen wir uns dann in den Räumen des CCC-FFM für Talks, Workshops und zum Hacken im Hackcenter.

Das Programm und weitere Informationen zur Veranstaltung findet Ihr auf unserer Meetup-Webseite: https://ffm.freifunk.net/meetup2018/

Freifunk lebt von eurer aktiven Beteiligung. Wir haben ein Pad für Ideen und Themenvorschläge: https://pad.freifunk.net/p/ThemenHessenMeetup20182
Wir würden uns sehr über eure Teilnahme freuen!

Damit wir optimal planen können, besonders für die Speisen, bitten wir Euch um eine Anmeldung unter: https://pretix.ffffm.net/ffffm/meetup18/.

Bei Fragen erreicht Ihr uns per IRC im hackint #freifunk-hessen oder #ffffm.

Beste Grüße

für Freifunk Frankfurt

Neue Firmware Version 2016.2.5+mwu1 (testing)

Neues vom Firmware-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,
 
 wie einige möglicherweise schon bemerkt haben, ist 2016.2.4+mwu1 nicht wie angekündigt am 05.04.2017 zum nächsten stable Release geworden. Das liegt daran, dass sich in den Patches für das Mesh-Protokoll ein Fehler eingeschlichen hat der zu Abstürzen des gesamten Systems führte. Seit Gestern gibt es Gluon v2016.2.5 im dem dieser Fehler nun behoben ist.
 
 Sofern keine weiteren Probleme mit dieser Version festgestellt werden planen wir dieses Release am 16.04.2017 zum Stable zu machen.
 
 Gluon Source Code: https://github.com/freifunk-gluon/gluon/releases/tag/v2016.2.5
 Gluon Release-Notes: https://gluon.readthedocs.io/en/stable/releases/v2016.2.5.html
 MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2016.2.5+mwu1
 
 Link zur Firmware Mainz: https://firmware.freifunk-mainz.de/testing
 Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/testing
 
 Fehlerberichte bitte über die Maschinenraum Liste.
 
 Happy Testing wünscht,
 das Firmware-Team

P.S.: Das Firmware-Team sucht immer interessierte Mitarbeiter. Bei Interesse meldet euch bitte!

 

Neue Firmware Version 2016.2.4+mwu1 (testing)

Aktuelles vom Firmware-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

es ist wieder so weit, eine neue Gluon Version wurde veröffentlicht! Dieses Release behebt einen Fehler im Mesh-Protokoll bei dem Pakete mit einer bestimmten Größe nicht übertragen wurden. Außerdem wurde eine mit v2016.2.3 eingeführte Änderung überarbeitet, die zu einem erhöhten Load auf den Knoten geführt hat.

Sofern keine Probleme mit dieser Version festgestellt werden planen wir dieses Release am 05.04.2017 zum Stable zu machen.

Gluon Source Code: https://github.com/freifunk-gluon/gluon/releases/tag/v2016.2.4
Gluon Release-Notes: https://gluon.readthedocs.io/en/stable/releases/v2016.2.4.html
MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2016.2.4+mwu1

Link zur Firmware Mainz: https://firmware.freifunk-mainz.de/testing
Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/testing

Fehlerberichte bitte über die Maschinenraum Liste.

Happy Testing wünscht,
das Firmware-Team

 

Neue Firmware Version 2016.2.3+mwu1 (testing)

Aktuelles vom Firmware-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

es ist wieder so weit, eine neue Gluon Version wurde veröffentlicht! Dieses Release behebt einen Fehler im Mesh-Protokoll bei dem Pakete mit einer bestimmten Größe nicht übertragen wurden. Außerdem wurde eine mit v2016.2.3 eingeführte Änderung überarbeitet, die zu einem erhöhten Load auf den Knoten geführt hat.

Sofern keine Probleme mit dieser Version festgestellt werden planen wir dieses Release am 05.04.2017 zum Stable zu machen.

Gluon Source Code: https://github.com/freifunk-gluon/gluon/releases/tag/v2016.2.4
Gluon Release-Notes: https://gluon.readthedocs.io/en/stable/releases/v2016.2.4.html
MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2016.2.4+mwu1

Link zur Firmware Mainz: https://firmware.freifunk-mainz.de/testing
Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/testing

Fehlerberichte bitte über die Maschinenraum Liste.

Happy Testing wünscht,
das Firmware-Team

IPv6-Optimierungen im Freifunk Mainz, Wiesbaden und Umgebung (MWU)

Seit der Aktivierung öffentlicher IPv6 Adressen für alle Clients hatten wir aufgrund unser Netzstruktur einen ungünstigen Datenfluss bei ein- und ausgehenden IPv6-Verbindungen. Weil Datenpakete nicht den kürzesten Weg durch unser Netz genommen haben, sondern intern weiter verteilt werden mussten, hat dies zu einem unnötigen Bandbreitenverbrauch geführt. Das Verhalten hat uns einiges an Kopfzerbrechen bereitet, letztendlich hat unser Admin-Team aber eine Lösung gefunden, die in den letzten Wochen stückweise aktiviert und verprobt wurde.

Das Problem

Unsere Freifunk MWU-Netze (Mainz, Wiesbaden und Umgebung) bestehen aus vielen kleinen Teilnetzen die mittels B.A.T.M.A.N. Advanced zu einem großen virtuellen Layer 2 Netzwerk zusammengeschaltet werden. Innerhalb dieser Netze kann jedes Gerät direkt mit allen anderen kommunizieren. In jedem dieser Netze gibt es vier Gateways die im wesentlichen drei Aufgaben haben. 1) Sie sind die VPN Gegenstelle für alle Knoten, 2) Default Gateway für alle Clients und 3) kümmern sich und die Ausleitung des Internetverkehrs über den Freifunk Rheinland. Aufgrund dieser virtuellen Netztopologie wissen die Endgeräte nichts über die wirkliche Struktur des Netzes.

Dies war solange kein Problem, wie wir extern nur über IPv4 kommuniziert haben, da jedes Gateway eine eindeutige Adresse hatte und sämtlicher Internetverkehr der Clients mit diesen geNATet wurde. Hierdurch konnte der Freifunk Rheinland immer eindeutig zuordnen über welches Gateway die Verbindung initiert wurde und hat die Daten immer auf dem für uns kürzesten Weg übertragen.

Mit IPv6 ist es aber nicht mehr nötig NAT einzusetzen (Nein, NAT ist kein Sicherheitsfeature!) da 2^128 Adressen verfügbar sind, dass sind ca. 600 Billiarden Adressen pro mm². Ohne NAT wird die Adresse bei ausgehendem Datenverkehr nicht mehr durch die des Gateways ersetzt wodurch die Systeme des Freifunk Rheinland nicht mehr zuordnen können über welches Gateway die Anfrage gesendet wurden und senden die Daten an das erstbeste. Unsere Gateways müssen sich dann darum kümmern die Daten intern an das Gateway weiterzuleiten über welches die Daten angefragt wurden. Da diese, wie bereits erwähnt, bei verschiedenen Hostern stehen entsteht ein unnötige Belastung der verfügbaren Bandbreite.

Die Lösung

Wir haben verschiedene Ansätze diskutiert und kamen am Ende nur zu einer Lösung. Wir müssen unsere Netze (/48) in kleinere Subnetze (/56) segmentieren. Gesagt, getan. Seit ein paar Tagen besitzt jedes Gateway sein eigenes Subnetz. Leider ist dies nur die halbe Lösung da es nur für eingehende Daten hilft. Durch unser Layer 2 Netz erhält jeder Client die Router Advertisements (im folgenden kurz RA genannt) von allen Gateways und trägt sich deshalb auch alle vier als Default Gateway ein. Da der Client nicht weiß, an welches Gateway der Knoten per VPN verbunden ist, kann er keine qualifizierte Entscheidung treffen, welches Gateway für ihn das Nächste ist.

Glücklicherweise haben sich bereits andere kluge Menschen darüber die Köpfe zerbrochen und ein Programm namens gluon-radv-filterd entwickelt. Dieses Programm muss auf den Knoten laufen und ist seit der Version 2016.2.2+mwu1 in unser Firmware enthalten. Die Funktion ist relativ einfach zu verstehen: Alles was das Programm tut, ist, sich jedes eingehende RA Paket anzuschauen und zu prüfen welche Verbindungsqualität (TQ) B.A.T.M.A.N Advanced zu der Gegenstelle hat die dieses gesendet hat. Anschließend wird eine Filterregel erstellt die alle RAs verwirft die nicht von der Gegenstelle mit der besten TQ kommen. Da die TQ mit jedem Hop sinkt können wir sicher sein, dass das RA Paket mit der besten TQ vom nächstgelegen Gateway kommt.

Bei Fragen oder Feedback wendet euch bitte an die Maschinenraum-Liste.