Schlagwort-Archive: Freifunk

Neue Freifunk-Firmware für Mainz, Wiesbaden und Umgebung (Version 2016.2.5+mwu1 (stable))

Schreibe eine Antwort

Schöne Neuigkeiten vom Firmware-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,
 
nachdem es die beiden vorherigen testing-Versionen aufgrund von Fehlern nicht nach stable geschafft haben ist es nun soweit, mit 2016.2.5+mwu1 haben wir seit Heute eine neue stable-Version. Eure Knoten sollten sich innerhalb der nächsten 5 Tage automatisch aktualisieren wenn der Autoupdater auf stable eingestellt ist. Da es in der bisherigen Version einen Fehler gab der dazu führt, dass der Autoupdater gegebenenfalls hängen bleibt ist unter Umständen ein Neustart des Knotens nötig.
 
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/stable
Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/stable
 
Happy Flashing wünscht,
das Firmware-Team

Neue Firmware Version 2016.2.5+mwu1 (testing)

Schreibe eine Antwort

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)

Schreibe eine Antwort

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 Knotenkarte (Meshviewer) für Freifunk Mainz, Wiesbaden und Umgebung

Schreibe eine Antwort

Aktuelles vom Admin-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

aus verschiedenen Gründen planen wir, die Software zu erneuern, die uns
unsere Karten malt. Wer die Details, unten, gelesen und die neue Karte
ausprobiert hat, soll uns gerne hier Feedback geben. 
Die Abschaltung der alten Karteninfrastruktur ist für den 20.4. geplant.

tl;dr https://mapng.freifunk-mwu.de

Seit Version 0.3 [1] enthält unsere Firmware den Dienst respondd [2].
Dieser läuft seit dem parallel zu alfred [3]. Beide Dienste haben
die gleiche Aufgabe, nämlich die Daten für unsere Knotenkarten
bereitzustellen.

Im Gegensatz zu alfred flutet respondd nicht periodisch das Netz mit
all seinen Statusinformationen, sondern sendet diese nur auf Anfrage.
Dies gibt uns z.B. die Möglichkeit das Datenaufkommen im Netz gezielter
zu steuern, in dem wir bei Bedarf die Frequenz der Abfragen reduzieren.

Bisher gab es außer HopGlass [4] keine wirkliche Alternative, um die
Daten über respondd abzufragen und zu visualisieren. Außerdem war
eine Übernahme der bisherigen Daten nicht ohne größeren Aufwand
möglich.

Auf dem letzten Hessen Meetup haben wir dann von Yanic [5] erfahren
und noch am selben Tag eine Testinstallation aufgesetzt.
Yanic bietet fast alles was wir benötigen und die fehlenden Sachen,
wie z.B Multi-Community-Support, konnten mit wenig Aufwand hinzugefügt werden.
Außerdem hat es die Möglichkeit unsere alten RRD Statistiken in die
von Yanic verwendete InfluxDB zu importieren, was uns die Möglichkeit
gibt die gespeicherten Daten in moderner und ansehnlicher Form aufzubereiten.

Da wir Aufgrund der begrenzten Ressourcen in den kleinen Plastikroutern
natürlich nicht ewig alfred und respondd in unserer Firmware pflegen wollen,
möchten wir das alte, seit über 2 Jahren nicht mehr weiterentwickelte,
Kartenbackend [6] so schnell wie möglich loswerden und alfred aus unserer
Frimware entfernen.

Im gleichen Zug gibt es auch einen aktualisierte Meshviewer, der durch den
Freifunk Regensburg einige neue Features [7] spendiert bekommen hat und
deutlich flüssiger auf schwachen/mobilen Endgeräten läuft, als die bisherige
Version.

Um die Last auf unseren Servern zu verringern, haben wir darauf verzichtet,
eigene Karten für die einzelnen Communities zu genieren, da wir die zwei
Klicks zum Filtern nach einer bestimmten "Site" für vertretbar halten.

Aber genug der Worte!

Karte:     https://mapng.freifunk-mwu.de
Statistik: https://stats.freifunk-mwu.de

Viele Grüße
das Admin-Team

[1] https://github.com/freifunk-mwu/site-ffmwu/releases/tag/0.3
[2] https://github.com/freifunk-gluon/packages/tree/master/net/respondd
[3] https://www.open-mesh.org/projects/alfred/wiki
[4] https://github.com/hopglass
[5] https://github.com/freifunk-mwu/yanic
[6] https://github.com/ffnord/ffmap-backend/commits/master
[7] https://github.com/ffrgb/meshviewer/blob/develop/README.md

Neue Firmware Version 2016.2.3+mwu1 (testing)

Schreibe eine Antwort

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)

Schreibe eine Antwort

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.

Neue Firmware Version 2016.2.2+mwu1 (stable)

Schreibe eine Antwort

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

wir wünschen euch allen einen exzellenten Start in das neue Jahr 2017! Das Firmware-Team beginnt das neue Jahr erstmal mit einer neuen _stabilen_ Firmware!

Seit 3-4 Monaten testen wir nun die neue Gluon Version 2016.2.x in einer nun schon recht langen Testphase – während dieser wurden seitens Gluon schon 2 Bugfix Releases veröffentlicht und auch wir haben ein paar Änderungen an der Konfiguration vorgenommen. Nun ist die Zeit gekommen, die Testphase abzuschließen und unsere Testing-Firmware als stabil zu deklarieren.

Das Announcement zur ersten 2016.2+mwu1 Testing-Firmware ist nun schon etwas her, sodass wir hier nochmal alle Änderungen seit der letzten stabilen Version „0.3.3-stable“ aufführen.

Neues Versionsschema:
Beginnend mit diesem Release werden wir unser bisheriges Versionsschema einmotten und an das von Gluon angleichen. Außerdem haben wir bisher nach einer erfolgreichen Beta-Phase die Firmware immer komplett neu kompiliert was zur Folge hatte, dass Knoten mit Beta-Version sich ein weiteres mal aktualisiert haben wenn sie wieder auf Stable umgestellt wurden. Deshalb haben wir stable/beta aus dem Releasenamen entfernt und der Status einer Version wird jetzt dadurch festgelegt in welchem Ordner sie liegt. Zusätzlich wird der Beta-Branch in Testing umbenannt da dies den Status aus unserer Sicht besser widerspiegelt.
Eine detaillierte Beschreibung des Versionsschemas findet ihr auf GitHub: https://github.com/freifunk-mwu/sites-ffmwu/blob/experimental/README.md#version-schema

Infos zur neuen stabilen Firmware:

MWU Firmware Version: „2016.2.2+mwu1“
Gluon Firmware Version: „v2016.2.2“

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

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

Änderungen an der Gluon Konfiguration (site) seit Version „0.3.3-stable“:
– neue Pakete zur Unterstützung diverser USB und PCI Netzwerkkarten zu den x86/x86-64 Images hinzugefügt
– GLUON_ATH10K_MESH und GLUON_REGION gesetzt um Geräte mit ath10k-Chip zu unterstützen
– WLAN Frequenzen für 802.11b deaktiviert (http://blogs.cisco.com/wireless/wi-fi-taxes-digging-into-the-802-11b-penalty)
– Einheitliches Repository für eigene Gluon-Pakete
– Paket gluon-ebtables-segment-mld hinzugefügt (http://gluon.readthedocs.io/en/stable/package/gluon-ebtables-segment-mld.html)
– Paket tecff-ath9k-broken-wifi-workaround hinzugefügt
https://github.com/freifunk-mwu/packages-ffmwu/tree/master/tecff-ath9k-broken-wifi-workaround
– Paket ffmwu-beta-to-testing hinzugefügt: https://github.com/freifunk-mwu/packages-ffmwu/tree/master/ffmwu-beta-to-testing
Dieses Paket benennt den alten Firmware Branch „beta“ in „testing“ um
– Paket gluon-radv-filterd hinzugefügt: https://github.com/freifunk-mwu/packages-ffmwu/tree/master/gluon-radv-filterd
Dieses Paket filtert alle Router Advertisements (http://goo.gl/t8TDZ7) außer denen die vom aktuell gewählten B.A.T.M.A.N Advanced Gateway kommen
– Vier zusätzliche Gateways (spare) für zukünftige Nutzung hinzugefügt

Die Gluon Änderungen und die Liste der Geräte, die neu unterstützt werden findet ihr unten in dieser Mail.

Fehlerberichte bitte über die Maschinenraum-Liste.

Happy Testing wünscht,
das Firmware-Team

Die wichtigsten Änderungen/Neuerungen in Gluon:
– Viele Ubiquiti airMAX XM Modelnamen werden jetzt richtig erkannt (z.B. wird eine „Nanostation Loco M“ nicht mehr als „Bullet M“ angezeigt)
https://github.com/freifunk-gluon/gluon/pull/632
– batman-adv: mesh_no_rebroadcast ist jetzt per default auf allen Mesh-on-WAN/LAN Verbindung aktiv
https://github.com/freifunk-gluon/gluon/issues/652
– Die neue UCI-Option gluon-core.@wireless[0].preserve_channels kann jetzt dazu genutzt werden um das
Zurücksetzen geänderter WLAN-Kanäle bei einem Firmwareupdate zu verhindern
https://github.com/freifunk-gluon/gluon/issues/640
– PoE-Passthrough kann jetzt über die „Erweiterten Einstellungen“ für TP-Link CPE 210/510 und Ubiquiti NanoStations aktiviert werden
https://github.com/freifunk-gluon/gluon/issues/328
– In Knotennamen können jetzt beliebige UTF-8 benutzt werden
https://github.com/freifunk-gluon/gluon/issues/#414
– Dropbear (SSH) wurde auf eine aktuellere Version aktualisiert, um neue Kryptographie Methoden zu erlauben und alte unsichere zu deaktivieren.
https://github.com/freifunk-gluon/gluon/issues/223
– Die Stabilität des ath9k WLAN Treibers wurde signifikant verbessert
https://github.com/freifunk-gluon/gluon/issues/605
– Treiber und Dienste wie mac80211 und hostapd wurden aus LEDE 42f559e zurückportiert
– Der “Experten Modus/Expert Mode” wurde in “Erweiterte Einstellungen/Advanced Settings” umbenannt
– Die Statusseite kann mit deaktivierten Cookies/Local Storage aufgerufen werden
– Kernel auf 3.18.44 aktualisiert (CVE-2016-5195 + CVE-2016-7117)
– PATA und MMC Support für x86 und x86-64 Images (z.B. werden die Futros dadurch nun nativ unterstützt)

Bugfixes:
– Booten einiger QCA955x-basierten Geräte (z.B. OpenMesh OM5P AC v2) (https://github.com/freifunk-gluon/gluon/pull/965)
– Diverse Probleme bzgl. des Compiliervorganges
– Fehlerhafte Interfacezuordnung von WAN/LAN auf der CPE210 (https://github.com/freifunk-gluon/gluon/commit/59deb2064d54a37e27139b76a3b6064f5f10f364)
– Hohe CPU Auslastung aufgrund zu hoher LED-Frequenz der Signastärken Signalisierung (https://github.com/freifunk-gluon/gluon/issues/897)
– Probleme mit dem Ethernet Port des Ubiquiti UAP AC Lite (https://github.com/freifunk-gluon/gluon/issues/911)
– Fehlerhafter RX Filter auf dem Ubiquiti UAP Outdoor+ (https://github.com/freifunk-gluon/gluon/commit/d43147a8e03dd17bc27e4ab203736f2151f9db3d)

Bekannte Probleme:
– TX Power auf vielen Ubiquiti Geräten ist zu hoch, siehe: https://github.com/freifunk-gluon/gluon/issues/94
– Manuelles Herabsetzen der TX Power via Expert Mode wird empfohlen
– MAC-Adresse des WAN Interfaces wird verändert, auch wenn Mesh-On-Wan deaktiviert ist, siehe https://github.com/freifunk-gluon/gluon/issues/496
– Führt zu Problemen wenn eine feste MAC-Adresse erwartet wird, z.B. bei VMware mit deaktiviertem Promiscious Mode
– Inkonsistente respondd/announced API, siehe https://github.com/freifunk-gluon/gluon/issues/522
– die aktuelle API ist inkonsistent und wird in einem zukünftigen Release ersetzt. Die alte API wird noch eine Weile unterstützt.

Neu unterstützte Geräte:

ar71xx-generic
– ALFA Network Tube2H N2
– ALFA Network Tube2H N5
– Buffalo WZR-HP-G300NH2
– GL Innovations GL-AR150
– OpenMesh MR1750 v1, v2
– OpenMesh OM2P-HS v3
– OpenMesh OM5P-AC v1, v2
– TP-Link Archer C5 v1
– TP-Link Archer C7 v2
– TP-Link CPE210/510 EU/US Versionen
– TP-Link TL-WR710N v2.1
– TP-Link TL-WA801N/ND v3
– TP-Link TL-WR841ND v11 EU/US Versionen
– TP-Link TL-WR842N/ND v3
– TP-Link TL-WA901ND v4
– Ubiquiti UniFi AP AC Lite
– Ubiquiti UniFi AP AC Pro

brcm2708-bcm2708
– Raspberry Pi 1

brcm2708-bcm2709
– Raspberry Pi 2

Neue Firmware Version 2016.2.2+mwu1 (stable)

Schreibe eine Antwort

Aktuelles vom Firmware-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

wir wünschen euch allen einen exzellenten Start in das neue Jahr 2017! Wir vom Firmware-Team beginnen das neue Jahr erstmal mit einer neuen _stabilen_ Firmware!
Seit 3-4 Monaten testen wir nun die neue Gluon Version 2016.2.x in einer nun schon recht langen Testphase - während dieser wurden seitens Gluon schon 2 Bugfix Releases veröffentlicht und auch wir haben ein paar Änderungen an der Konfiguration vorgenommen. Nun ist die Zeit gekommen, die Testphase abzuschließen und unsere Testing-Firmware als stabil zu deklarieren.

Das Announcement zur ersten 2016.2+mwu1 Testing-Firmware ist nun schon etwas her, sodass wir hier nochmal alle Änderungen seit der letzten stabilen Version "0.3.3-stable" aufführen.

Neues Versionsschema:
Beginnend mit diesem Release werden wir unser bisheriges Versionsschema einmotten und an das von Gluon angleichen. Außerdem haben wir bisher nach einer erfolgreichen Beta-Phase die Firmware immer komplett neu kompiliert was zur Folge hatte, dass Knoten mit Beta-Version sich ein weiteres mal aktualisiert haben wenn sie wieder auf Stable umgestellt wurden. Deshalb haben wir stable/beta aus dem Releasenamen entfernt und der Status einer Version wird jetzt dadurch festgelegt in welchem Ordner sie liegt. Zusätzlich wird der Beta-Branch in Testing umbenannt da dies den Status aus unserer Sicht besser widerspiegelt.
Eine detaillierte Beschreibung des Versionsschemas findet ihr auf GitHub: https://github.com/freifunk-mwu/sites-ffmwu/blob/experimental/README.md#version-schema

Infos zur neuen stabilen Firmware:

MWU Firmware Version: "2016.2.2+mwu1"
Gluon Firmware Version: "v2016.2.2"

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

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

Änderungen an der Gluon Konfiguration (site) seit Version "0.3.3-stable":
- neue Pakete zur Unterstützung diverser USB und PCI Netzwerkkarten zu den x86/x86-64 Images hinzugefügt
- GLUON_ATH10K_MESH und GLUON_REGION gesetzt um Geräte mit ath10k-Chip zu unterstützen
- WLAN Frequenzen für 802.11b deaktiviert (http://blogs.cisco.com/wireless/wi-fi-taxes-digging-into-the-802-11b-penalty)
- Einheitliches Repository für eigene Gluon-Pakete
- Paket gluon-ebtables-segment-mld hinzugefügt (http://gluon.readthedocs.io/en/stable/package/gluon-ebtables-segment-mld.html)
- Paket tecff-ath9k-broken-wifi-workaround hinzugefügt
  https://github.com/freifunk-mwu/packages-ffmwu/tree/master/tecff-ath9k-broken-wifi-workaround
- Paket ffmwu-beta-to-testing hinzugefügt: https://github.com/freifunk-mwu/packages-ffmwu/tree/master/ffmwu-beta-to-testing
  Dieses Paket benennt den alten Firmware Branch "beta" in "testing" um
- Paket gluon-radv-filterd hinzugefügt: https://github.com/freifunk-mwu/packages-ffmwu/tree/master/gluon-radv-filterd
  Dieses Paket filtert alle Router Advertisements (http://goo.gl/t8TDZ7) außer denen die vom aktuell gewählten B.A.T.M.A.N Advanced Gateway kommen
- Vier zusätzliche Gateways (spare) für zukünftige Nutzung hinzugefügt

Die Gluon Änderungen und die Liste der Geräte, die neu unterstützt werden findet ihr unten in dieser Mail.

Fehlerberichte bitte über die Maschinenraum Liste.

Happy Testing wünscht,
das Firmware-Team


Die wichtigsten Änderungen/Neuerungen in Gluon:
- Viele Ubiquiti airMAX XM Modelnamen werden jetzt richtig erkannt (z.B. wird eine "Nanostation Loco M" nicht mehr als "Bullet M" angezeigt)
  https://github.com/freifunk-gluon/gluon/pull/632
- batman-adv: mesh_no_rebroadcast ist jetzt per default auf allen Mesh-on-WAN/LAN Verbindung aktiv
  https://github.com/freifunk-gluon/gluon/issues/652
- Die neue UCI-Option gluon-core.@wireless[0].preserve_channels kann jetzt dazu genutzt werden um das
  Zurücksetzen geänderter WLAN-Kanäle bei einem Firmwareupdate zu verhindern
  https://github.com/freifunk-gluon/gluon/issues/640
- PoE-Passthrough kann jetzt über die "Erweiterten Einstellungen" für TP-Link CPE 210/510 und Ubiquiti NanoStations aktiviert werden
  https://github.com/freifunk-gluon/gluon/issues/328
- In Knotennamen können jetzt beliebige UTF-8 benutzt werden
  https://github.com/freifunk-gluon/gluon/issues/#414
- Dropbear (SSH) wurde auf eine aktuellere Version aktualisiert, um neue Kryptographie Methoden zu erlauben und alte unsichere zu deaktivieren.
  https://github.com/freifunk-gluon/gluon/issues/223
- Die Stabilität des ath9k WLAN Treibers wurde signifikant verbessert
  https://github.com/freifunk-gluon/gluon/issues/605
- Treiber und Dienste wie mac80211 und hostapd wurden aus LEDE 42f559e zurückportiert
- Der “Experten Modus/Expert Mode” wurde in “Erweiterte Einstellungen/Advanced Settings” umbenannt
- Die Statusseite kann mit deaktivierten Cookies/Local Storage aufgerufen werden
- Kernel auf 3.18.44 aktualisiert (CVE-2016-5195 + CVE-2016-7117)
- PATA und MMC Support für x86 und x86-64 Images (z.B. werden die Futros dadurch nun nativ unterstützt)

Bugfixes:
 - Booten einiger QCA955x-basierten Geräte (z.B. OpenMesh OM5P AC v2) (https://github.com/freifunk-gluon/gluon/pull/965)
 - Diverse Probleme bzgl. des Compiliervorganges
 - Fehlerhafte Interfacezuordnung von WAN/LAN auf der CPE210 (https://github.com/freifunk-gluon/gluon/commit/59deb2064d54a37e27139b76a3b6064f5f10f364)
 - Hohe CPU Auslastung aufgrund zu hoher LED-Frequenz der Signastärken Signalisierung (https://github.com/freifunk-gluon/gluon/issues/897)
 - Probleme mit dem Ethernet Port des Ubiquiti UAP AC Lite (https://github.com/freifunk-gluon/gluon/issues/911)
 - Fehlerhafter RX Filter auf dem Ubiquiti UAP Outdoor+ (https://github.com/freifunk-gluon/gluon/commit/d43147a8e03dd17bc27e4ab203736f2151f9db3d)

Bekannte Probleme:
- TX Power auf vielen Ubiquiti Geräten ist zu hoch, siehe: https://github.com/freifunk-gluon/gluon/issues/94
  - Manuelles Herabsetzen der TX Power via Expert Mode wird empfohlen
- MAC-Adresse des WAN Interfaces wird verändert, auch wenn Mesh-On-Wan deaktiviert ist, siehe https://github.com/freifunk-gluon/gluon/issues/496
  - Führt zu Problemen wenn eine feste MAC-Adresse erwartet wird, z.B. bei VMware mit deaktiviertem Promiscious Mode
- Inkonsistente respondd/announced API, siehe https://github.com/freifunk-gluon/gluon/issues/522
  - die aktuelle API ist inkonsistent und wird in einem zukünftigen Release ersetzt. Die alte API wird noch eine Weile unterstützt.

Neu unterstützte Geräte:

ar71xx-generic
- ALFA Network Tube2H N2
- ALFA Network Tube2H N5
- Buffalo WZR-HP-G300NH2
- GL Innovations GL-AR150
- OpenMesh MR1750 v1, v2
- OpenMesh OM2P-HS v3
- OpenMesh OM5P-AC v1, v2
- TP-Link Archer C5 v1
- TP-Link Archer C7 v2
- TP-Link CPE210/510 EU/US Versionen
- TP-Link TL-WR710N v2.1
- TP-Link TL-WA801N/ND v3
- TP-Link TL-WR841ND v11 EU/US Versionen
- TP-Link TL-WR842N/ND v3
- TP-Link TL-WA901ND v4
- Ubiquiti UniFi AP AC Lite
- Ubiquiti UniFi AP AC Pro

brcm2708-bcm2708
- Raspberry Pi 1

brcm2708-bcm2709
- Raspberry Pi 2

Neue Firmware Version 2016.2.2+mwu1 (testing)

Schreibe eine Antwort

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

wie manchen bestimmt aufgefallen ist hätte die letzte Testing Firmware schon Anfang Dezember als „stable“ veröffentlicht werden sollen.  Es hat sich aber zeitnah das nächste Gluon Bugfix Release abgezeichnet,  auf das wir noch warten wollten.

Bitte beachtet, dass der folgende Workaround immer noch implementiert ist: leider ist die Stabilität des ath9k Treibers in Gluon v2016.2.1 immer  noch nicht zufriedenstellen aber zumindest wieder auf einem ähnlichen  Stand wie bis 2016.1.5. Aus diesem Grund haben wir uns dazu entschieden  einen Workaround in die Firmware einzubauen welcher bereits bei diversen  Freifunk Communities (München, Darmstadt, Frankfurt a.M., Altdorf) im Einsatz ist. Dieser Workaround besteht aus einem Script das einmal pro Minute aufgerufen wird und die Funktionalität der WLAN-Verbindung überprüft. Sollten die überprüften Parameter Fehler aufzeigen werden die WLAN Netzwerkinterfaces neuinitialisiert.

Wir peilen die erste Januar Woche 2017 für das „stable“ Release an.

Infos zur neuen Firmware:

MWU Firmware Version: „2016.2.2+mwu1“
Gluon Firmware Version: „v2016.2.2“

Änderungen an der Gluon Konfiguration (site) seit Version „2016.2.1+mwu2“:
– Vier zusätzliche Gateways (spare) für zukünftige Nutzung hinzugefügt
– Paket ffmwu-beta-to-testing hinzugefügt:
https://github.com/freifunk-mwu/packages-ffmwu/tree/master/ffmwu-beta-to-testing
Dieses Paket benennt den alten Firmware Branch „beta“ in „testing“ um
– Paket gluon-radv-filterd hinzugefügt:
https://github.com/freifunk-mwu/packages-ffmwu/tree/master/gluon-radv-filterd
Dieses Paket filtert alle Router Advertisements (http://goo.gl/t8TDZ7)
außer denen die vom aktuell gewählten B.A.T.M.A.N Advanced Gateway kommen

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

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

Fehlerberichte bitte über die Maschinenraum Liste.

Happy Testing wünscht,
das Firmware-Team

Behobene Probleme in Gluon:
– Booten einiger QCA955x-basierten Geräte (z.B. OpenMesh OM5P AC v2)
(https://github.com/freifunk-gluon/gluon/pull/965)
– Diverse Probleme bzgl. des Compiliervorganges
– Fehlerhafte Interfacezuordnung von WAN/LAN auf der CPE210
(https://github.com/freifunk-gluon/gluon/commit/59deb2064d54a37e27139b76a3b6064f5f10f364)
– Hohe CPU Auslastung aufgrund zu hoher LED-Frequenz der Signastärken
Signalisierung (https://github.com/freifunk-gluon/gluon/issues/897)
– Probleme mit dem Ethernet Port des Ubiquiti UAP AC Lite
(https://github.com/freifunk-gluon/gluon/issues/911)
– Fehlerhafter RX Filter auf dem Ubiquiti UAP Outdoor+
(https://github.com/freifunk-gluon/gluon/commit/d43147a8e03dd17bc27e4ab203736f2151f9db3d)

Andere Änderungen:
– PATA und MMC Support für x86 und x86-64 Images (z.B. werden die
Futros dadurch nun nativ unterstützt)

Bekannte Probleme:
– TX Power auf vielen Ubiquiti Geräten ist zu hoch, siehe:
https://github.com/freifunk-gluon/gluon/issues/94
– Manuelles Herabsetzen der TX Power via Expert Mode wird empfohlen
– MAC-Adresse des WAN Interfaces wird verändert, auch wenn Mesh-On-Wan
deaktiviert ist, siehe https://github.com/freifunk-gluon/gluon/issues/496
– Führt zu Problemen wenn eine feste MAC-Adresse erwartet wird, z.B.
bei VMware mit deaktiviertem Promiscious Mode
– Inkonsistente respondd/announced API, siehe
https://github.com/freifunk-gluon/gluon/issues/522
– die aktuelle API ist inkonsistent und wird in einem zukünftigen
Release ersetzt. Die alte API wird noch eine Weile unterstützt.

Neu unterstützte Geräte:

ar71xx-generic
– TP-Link CPE210/510 EU/US Versionen
– TP-Link TL-WA801N/ND v3
– TP-Link TL-WR841ND v11 EU/US Versionen