[Freifunk-Bonn] FF MWU wechselt von HT40+ auf HT20 - Fwd: [Freifunk Mainz] Gluon Konfigurationsänderungen (Firmware Upgrade auf Version 0.2.2 - Stable)

[krugar]

moin zusammen,

auf die gefahr hin, ein totes pferd zu misshandeln: die freifunkgruppe
in mainz/wiesbaden/umgebung schalten gerade von ht40 auf ht20 "runter".
die begründung ist evtl auch für jemanden hier auf der liste von interesse.

lg
-alex


-------- Weitergeleitete Nachricht --------
Betreff: 	[Freifunk Mainz] Gluon Konfigurationsänderungen (Firmware
Upgrade auf Version 0.2.2 - Stable)
Datum: 	Mon, 12 Oct 2015 16:35:27 +0200
Von: 	Tobias Hachmer <tobias at hachmer.de>
Antwort an: 	Mailingliste für Freifunk-Aktivitäten in und um Mainz
<mainz at freifunk.net>
An: 	mainz at freifunk.net



Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

seit guten 8 Monaten läuft nun das neue Freifunk Netzwerk auf Basis von 
Gluon. Die Teilnahme ist wunderbar und das Netz wächst rasant.
Vielen Dank an alle, die sich in welcher Form auch immer daran 
beteiligen!

In den letzten Monaten haben sich zwei technische Probleme aufgetan, 
denen wir mit kleinen Änderungen an der Firmware Konfiguration begegnen.

Die Kurzfassung:
 - HT-Mode (2,4 GHz Band) wird von "HT40+" auf "HT20" geändert
 - Die Anzahl der VPN Verbindungen eines Knoten wird von "2" auf "1" 
herabgesetzt.

Diese Änderungen werden wir voraussichtlich im Laufe der nächstenWoche 
(KW 43) mittels Autoupdater ausrollen. An der OpenWRT sowie Gluon 
Code-Basis ändert sich nichts.
Das Upgrade wird aber nochmal gesondert angekündigt.

Für Fragen und Anregungen sind wir immer offen. Eine detaillierte 
Erläuterung findet ihr unten in der Langfassung.

Frohes Freifunken!
wünscht das Admin-Team


P.S.: Die Langfassung:

---
1. HT-Mode im 2,4GHz Band

Von Anfang an sind wir mit einer Kanalbreite im 2,4GHz Band von 40 MHz 
gestartet. Das bedeutet, dass 2x benachbarte 20MHz Kanäle gebündelt 
werden, um mehr als das Doppelte an Bandbreite in der WLAN Funkzelle zu 
erzielen.

Unser verwendeter Kanal: 6 (Primärer Kanal)
Unsere OpenWRT Einstellung: HT40+

Das + bzw. - weist den Knoten an für die Kanalbündelung als sekundären 
Kanal den oberhalb liegenden, respektive darunterliegenden Kanal zu 
verwenden.
Die Praxis hat gezeigt, dass das 2,4GHz Band überall so belegt ist, dass 
die Software sehr schnell den sekundären Kanal deaktiviert und somit 
ohne Kanalbündelung mit einem 20MHz breiten Kanal arbeitet.

Zunächst ist das alleine kein Problem. Man muss dazu wissen, dass die 
WLAN Konfiguration unter OpenWRT mit Hilfe des Scripts 
"/lib/netifd/wireless/mac80211.sh" erfolgt. Dieses Script startet für 
das Freifunk Client WLAN einen hostapd-Prozess.
Das IBSS (Adhoc-WLAN für das Meshing) wird hingegen ganz simple durch 
den Befehl "iw" konfiguriert. Bedeutet: Wenn der hostapd-Daemon 
feststellt, dass der Sekundär-Kanal belegt ist schaltet dieser die 
Kanalbündelung aus. Die Kanalbreite für das IBSS bleibt aber auf 40MHz.
Im Endeffekt führt das zu einem Geschwindigkeitseinbruch (mehr Packet 
Loss/ mehr Interferenzen) auf den WLAN-Mesh-Verbindungen, wenn der 
sekundäre Kanal belegt ist, das in den meisten Szenarien der Fall ist.

---

2. fastd peer limit (Anzahl der gleichzeitig aktiven VPN-Verbindungen 
eines Knotens mit den Freifunk-Gateways)
Auch hier sind wir mit dem "fastd peer limit" von "2" auf den Knoten 
gestartet. Damit baut jeder Knoten 2 aktive VPN Verbindungen auf, also 
zu 2 der 4 Freifunk Gateways. Hintergrund war ein schnelles Failover, 
wenn eines der verbundenen Gateways ausfällt.
Die zunehmende Anzahl an Knoten sowie Clients im Mainzer sowie im 
Wiesbadener Freifunk-Netz führt zu stärkerem "Grundrauschen", also 
Batman Management Traffic sowie Layer 2 Management Traffic (ARP, NDP, 
Broadcasts/Multicasts im Allgemeinen, etc.).
Um dieses Grundrauschen etwas zu reduzieren wird die Anzahl der VPN 
Verbindungen auf den Knoten auf "1" heruntergesetzt. Damit wird jeder 
Knoten nur noch eine VPN Verbindung zu einem der 4 Freifunk Gateways 
aufbauen. Die Gateway-Redundanz bleibt nach wie vor bestehen. Fällt das 
verbundene Gateway aus wird eine neue VPN Verbindung zu einem der 
verbleibenden aktiven Gateway aufgebaut. Der einzige Nachteil ist der 
Timeout von 90 Sekunden. Der fastd-prozess baut die neue VPN-Verbindung 
erst auf, wenn die alte Verbindung 90 Sekunden lang nicht reagiert.

Wir empfinden 90 Sekunden als verschmerzbar, da vor allem die geringere 
Grundlast wichtiger fürs gesamte Netz ist. Dieser Timeout wird zudem in 
einer zukünftigen Version konfgiurierbar sein, sodass wir den Timeout 
auf lange Sicht nochmal reduzieren können.

Positive Nebeneffekte:

 - Die CPU-Last auf den Knoten sowie Gateways verringert sich
 - Das per VPN verbundene Gateway ist für einen VPN-Knoten immer auch 
das Batman-Gateway für IPv4 (bei ordentlicher Funktion des Gateways)
---