Bürgernetz Gera-Greiz e.V.

CC BY-SA 2.5
by Arpad Horvath

Nach unserem letzten Update der stabilen Version läuft diese nun schon einige Zeit auf fast allen Routern der Community Gera-Greiz. Bis auf wenige Router ohne Auto-Update gibt es keine Beta- oder experimentelle Version mehr. Das liegt im Wesentlichen daran, daß alle 3 Firmware-Zweige (stable, beta, experimental) Beim Einführung der stabilen Version einen identischen Stand hatten.

Das soll sich jetzt ändern. Wir bereiten einige interessante neue bzw. geänderte Funktionen vor, die wir mit den im Downloadbereich seit heute bereitstehenden Beta- und experimental Firmwares testen möchten. (Wem das Folgende zu technisch ist: macht nichts, einfach unsere getestete stabile Firmware weiter nutzen)

Bei der Beta-Version gibt es von uns nur 2 Änderungen:

  1. Die Basis bildet die GLUON-Version 2016.1.4. Die Änderungen seit der für unsere Stable genutzte Version 2016.1.2 sind hier beschrieben. Im Wesentlichen gibt es die Unterstützung einiger neuer Routermodelle und etliche Bugfixes.
  2. Die Gateway Selection Class der Router wird auf 45 erhöht. Davon erhoffen wir uns, daß der Datenverkehr eines Routers verstärkt über das Gateway geleitet wird, mit welchem dieser verbunden ist. Bisher schicken sehr viele Router ihren Traffic gerade zu einem der anderen Gateways, was zu einem hohen Datenaustausch zwischen den Gateways führt. Gibt es mit der Beta-Version keine Probleme, werden wir deswegen sehr schnell auch eine neue stabile Version mit dieser Änderung nachschieben.

Bei der neuen experimentellen Version wurde wesentlich mehr geändert:

  • Die Gateway Selection Class wurde ebenfalls erhöht.
  • Basis ist die aktuelle Entwickler-Version von GLUON mit dem Stand vom 1. Mai
  • OPKG-Mirror: Router ohne eigene Internetverbindung (Mesh-only) haben keine IPv4-Adresse. Da die offiziellen OpenWRT-Repositories nur per IPv4 erreichbar sind, kann man deswegen keine Pakete einfach nachinstallieren. Das ist nun durch das Einfügen eines IPv6-Repositories möglich.
  • Mesh-Protokoll IEEE802.11s: In der stabilen Firmware ist die Unterstützung für das neue Mesh-Protokoll 802.11s bereits enthalten, aber deaktiviert. Das ist für die experimentelle Firmware umgekehrt: 802.11s ist per default aktiv, das "alte" Ad-Hoc-Mesh deaktiviert. damit können in der Grundeinstellung Router mit der experimentellen Firmware keine Verbindung mehr zu Routern mit der stabilen Firmware aufnehmen! Deswegen sollten alle Router der Testumgebung (nur dafür ist die experimentelle Firmware gedacht)  auf das gleiche Mesh-Protokoll gestellt werden.
    802.11s wird es ermöglichen, wesentlich mehr Router verschiedenster Hersteller mit eine Freifunk-Firmware auszustatten. Da besonders kleinere Router bei der Ativierung beider Mesh-Protokolle Probleme bekommen, werden wir bei der späteren Einführung in der stabilen Firmware die entsprechenden Meshverbindungen bereits vorher umstellen.
  • L2TP: Die experimentelle Firmware unterstützt neben dem bisherigen FastD nun die Kombination TunnelDigger/L2TP zum Aufbau eines Tunnels zu den Gateways. L2TP ist im Vergleich zu FastD wesentlich ressourcenschonender, was sowohl auf dem Router als auch auf den Gateways die Auslastung verringert und so die Geschwindigkeit erhöht. Allerdings verschlüsselt L2TP den datenverkeht zwischen Router und Gateway nicht mehr. Das sollte aber kein großes Problem darstellen: vom Client (Notebook, Tablet, Smartphone...) zum Router und vom Gateway ins Internet wird sowieso nicht verschlüsselt. Zur Bewahrung der Privatsphäre sollte man also selbst verschlüsseln (https...).
    Derzeit unterstützt lediglich Gateway2 eine verbindung mit L2TP. Auf den anderen Gateways wird die Aktivierung in Kürze ebenfalls erfolgen.
  • Im Konfigurations-Modus vergißt der Router nun nicht mehr die vorgenommenen Einstellungen, wenn zum Experten-Modus und zurück gewechselt wird.

Um uns bei den Tests zu unterstützen, können die neuen Firmware-Versionen entweder über den Konfigurations-Modus oder per SSH installiert werden. Beachtet werden muß aber, daß durchaus Probleme auftreten können. Eine Garantie für die ordnungsgemäße Funktion können wir generell nicht übernehmen. Das gilt insbesondere für die experimentelle Version. Auf schlecht erreichbare Router z.B. sollte also nur die stabile Firmware installiert werden. Auch sollte jeder, der eine Beta- oder experimentelle Firmware installiert, zumindest zu einem Recovery per TFTP in der Lage sein. Wenn Probleme auftreten, helfen wir aber natürlich z.B. im Forum oder bei einem Treffen weiter.

Update 10.5.2016: Nachden mit der Beta-Version keine Probleme aufgetreten sind, gibts die nun seit heute als stabile Version. Mit aktiviertem Autoupdater wird das Update in den nächsten Stunden erfolgen.

Details
Kategorie: Aktuelles

Hier mal eine kurze Einführung, wie man das Mesh über WLAN zu bestimmten Knoten unterbinden kann.

Das ist zum Beispiel dann sinnvoll, wenn man die betreffenden Knoten über Kabel miteinander meshen läßt und so keine Airtime für das zusätzliche WiFi-Mesh verschwenden möchte. Außerdem lassen sich damit instabile Links ausblenden, deren Aufrechterhaltung unter Umständen nur unnötig Ressourcen benötigen würde. Die Mesh-Funktion ansich bleibt hierbei erhalten, so daß zum Beispiel der Nachbar einen Knoten aufstellen und dieser dann meshen kann. Außerdem gibt es schlicht keinen Grund, 2 Knoten die per Kabel miteinander meshen, zusätzlich über WiFi miteinander meshen zu lassen, das wäre Ressourcenverschwendung.

Zum jetzigen Zeitpunkt ist es leider noch nicht möglich, die notwendige Änderung dauerhaft, also reboot- und updatefest in die Konfiguration der Knoten zu übernehmen, das wird sich hoffentlich mal ändern. Die notwendigen Befehle werden auf der ssh-Konsole ausgeführt.

Um einen Mesh-Link zu deaktivieren, muß man bei beiden beteiligten Knoten die MAC-Adresse des mesh-Interface des jeweils anderen Knotens sperren. Zunächst muß also diese MAC-Adresse ermittelt werden, dies macht man zum Beispiel mit dem Befehl:

ifconfig mesh0 | grep HWaddr

Die MAC-Adresse erscheint dann hinter HWaddr in der Form XX:XX:XX:XX:XX:XX. Hat man einen Dualband-Router, muß man entsprechend das richtige Interface (mesh0, mesh1) abrufen, die haben nämlich unterschiedliche MAC-Adressen!

Nun haben wir die MAC-Adresse, welche wir am anderen Knoten sperren müssen. Dies bewerkstelligt man mit dem Befehl:

iw dev mesh0 station set xx:xx:xx:xx:xx:xx plink_action block

An Stelle der XX muß natürlich die entsprechende MAC-Adresse angegeben werden.

Die Anweisung ist sofort aktiv, es sind keine weiteren Schritte notwendig, also auch kein commit und kein wifi oder sonstiges. Damit der Link zuverlässig deaktiviert wird, muß man nun noch analog den zweiten beteiligten Knoten anpassen.

Die Anpassung bleibt in dieser Form jedoch nur bis zum nächsten Neustart bestehen.

 

VG

Sven

Details
Kategorie: Aktuelles

Am 29.07.17 fand im Herzen von Gera die 3. Aprestour statt. Gemeinsam mit dem Veranstalter haben wir hierbei Freifunk für diesen Tag aufgebaut. Hierzu standen uns 7 Knoten zur Verfügung. Zwei Knoten befanden sich an der Videowand und zwei Nanostation am Zugangspunkt zum Internet mit einer Bandbreite von 25 MBit, welcher von einen Bürger dankenswerterweise zur Verfügung gestellt wurde. Somit konnte die Veranstaltung abgesichert werden. Ein weiterer Knoten befand sich an unseren Freifunk Infostand.
Zu Spitzenzeiten waren 145 Clients im Freifunk Netz eingeloggt.
Ich möchte mich hiermit bei dem Veranstalter Lucas Schädlich für die gute Zusammenarbeit bedanken. Weiterhin sage ich ein großes Dankeschön an alle Freifunker, welche aktiv diese Veranstaltung abgesichert haben. Wir konnten hierdurch unserer Können abermals unter Beweis stellen.

Details
Kategorie: Aktuelles

CC BY-SA 2.5
by Arpad Horvath

Basierend auf GLUON v2016.2.6 steht ab sofort die neue stabile Firmware 0.8.18 für die Community Gera-Greiz zur Verfügung. Bei Knoten mit aktiviertem Autoupdater erfolgt die Verteilung automatisch in den kommenden 2 Wochen. Seit der vorangegangenen stabilen Version 0.8.16 hat sich nicht allzu viel geändert:

  • Unterstützung für TP-Link TL-WR841N/ND v12
  • Behebung kleinerer Fehler und eines für uns unbedeutenden Sicherheitsloches
  • Behebung eines Fehlers bei Upgrades von x86-basierenden Knoten

Der letzte Punkt ist wichtig für alle, die Knoten auf PC-Hardware (Intel/AMD) betreiben. Wird beim Upgrade auf eine der nächsten Firmware-Versionen diese Version 0.8.18 ausgelassen, geht die gesamte Konfiguration des Knotens verloren. Er würde sich also nicht mehr mit Gateways und anderen Knoten verbinden und müßte vor Ort neu konfiguriert werden.

Die Version 0.8.18 wird voraussichtlich die letzte sein, welche auf dem nicht mehr gepflegten OpenWRT aufbaut. Die nächste Version läuft dann mit GLUON v2017.x unter dem aktuellen, modernisiertem LEDE. Wahrscheinlich werden wir dabei auch den Schritt von Fastd zu TunnelDigger/L2TP vornehmen. Beides sind VPN-Protokolle, welche für nicht (nur) per Mesh angebundene Knoten über unsere Gateways die Verbindung zum restlichen Netz unserer Community aufnehmen. TunnelDigger/L2TP ist im Vergleich zu Fastd ressourcenschonender und schneller, so daß auch weniger leistungsstarke Knoten die volle Kapazität des Internet-Anschlusses ausschöpfen können.

Auf Grund dieser recht wesentlichen Änderungen sind vor diesem Update noch umfangreiche Tests geplant. Unsere derzeitige experimentelle Firmware basiert bereits auf GLUON v2017.1 und LEDE und verwendet nur noch TunnelDigger/L2TP. Diese läuft auf ca. 25 Knoten bisher recht gut. Als nächsten Schritt werden wir beim kommenden Techniktreffen auf dieser Basis eine neue Beta-Version erstellen. Damit können wir auf allen Beta-Knoten testen, ob beim Wechsel auf die neue Firmware Probleme auftreten. Für eine breitere Testbasis wünschen wir uns, daß sich noch mehr Knotenbetreiber an den Betatests beteiligen. Auch Nutzer der aktuellen experimentellen Firmware sollten nach Möglichkeit nochmal den Schritt von der derzeitigen stabilen auf die folgende Beta-Firmware durchspielen. Wie das genau geschehen kann, erklären wir, sobald die neue Beta-Firmware zur Verfügung steht.

Details
Kategorie: Aktuelles

CC BY-SA 2.5
by Arpad Horvath

Basierend auf dem gerade erschienenen GLUON v2016.2 erstellen wir derzeit eine neue Beta-Version der Router-Firmware für unsere Community Gera-Greiz, die Version 0.8.9-beta1. Diese sollte ab heute (22.9.2016) abend zum Download und fürs Autoupdate zur Verfügung stehen. Sollten damit keine Probleme auftreten, wird kurzfristig eine statile Version nachgeschoben, welche dann auf dieser Beta-Version basiert.

Seit der aktuellen stabilen Version 0.8.8 gibt es folgende Neuerungen:

  • Unterstützung für viele neue Routermodelle, vor allem solche mit ath10k WLAN Chipsatz, hinzugefügt. Z.B. auch:
    • GL-AR150
    • Archer C5 v1, Archer C7 v2
    • TL-WR842N/ND v3
    • UniFi AP AC Lite und Pro
    • RaspberryPi 1 und 2
  • Die Modellnamen vieler Ubiquiti-Router werden jetzt eindeutig erkannt. Damit wird z.B. eine Loco jetzt als Loco angezeigt und nicht mehr als Bullet.
  • Aktivierung des Parameters "mesh_no_rebroadcast" für Mesh-on-WAN/LAN Interfaces. Das soll einiges an Traffic einsparen.
  • neue UCI-Option "gluon-core.@wireless[0].preserve_channels": Wird diese auf "1" gesetzt, werden manuell geänderte Kanäle euf einem Router bei einem Update nicht mehr überschrieben
  • In den Advaced Settings des Config-Modes kann nun für Nanostations und CPE 210/510 PoE Passthrough konfiguriert werden
  • Das Feld zur Angabe der Höhe im Config-Mode kann ausgeblendet werden. Das haben wir in unserer Firmware auch getan.
  • Die Angabe eines Kontaktes im Config-Mode kann jetzt verlangt werden. Auch das ist in unserer Firmware jetzt aktiviert.
  • Der Knotenname kann jetzt beliebige Sonderzeichen enthalten.
  • Beim 2,4GHz-WLAN können jetzt die unterstützten Raten gesetzt werden. Das ist bei uns nun so eingeschränkt, daß 802.11b-Clients nicht mehr unterstützt werden. Dafür sollte die Performance steigen.
  • Die Stabilität der WLAN-Treiber soll entscheidend verbessert worden sein.
  • Ab sofort verzichten wir auf das automatische Eintragen von SSH-Schlüsseln unserer Admins auf den Routern. Dies hatte es zwar ermöglicht, in den verschiedensten Notfällen schnell eingreifen zu können. Wer dies nicht wünschte, konnte den Schlüssel z.B. im Config-Mode löschen. Leider wurde der Schlüssel bei jedem Update automatisch wieder eingetragen. Das ist verständlicherweise für alle, die eine Zugriffsmöglichkeit auf ihre Router explizit nicht wünschen, nicht akzeptabel. Deswegen wird nun generell kein Schlüssel mehr gesetzt. Wer dennoch nicht auf die sehr sinnvolle Möglichkeit des Supports durch unsere Admins verzichten möchte, muß deren SSH-Schlüssel nun während der Konfiguration von Hand selbst eintragen.
Details
Kategorie: Aktuelles

Unterkategorien

Freifunk Gera-Greiz

Bürgernetz Gera-Greiz e.V.

namespace Gera

Seite 5 von 26

<name>space
geschlossen seit 29.11.2023 22:08 Uhr

RSS

Veranstaltungen / Ereignisse

Mi Dez. 06 @18:00 - 22:00
<name>space geöffnet
Mi Dez. 13 @18:00 - 22:00
<name>space geöffnet