…, habe ich jüngst mal wieder ausprobiert, wenngleich unfreiwillig — aber, wie mir im Nachhinein klar ist, abseh- und nachvollziehbar. Merke: broadcasts considered harmful ;)
Ich wollte in meinem Heimnetz, wo 5 Fritzboxen für 2,4- und 5-GHz-Abdeckung des WPA2-WLANs auf 2 Geschossen und im Garten sorgen sollen, etwas Entlastung für den VDSL-Uplink (und das gesamte Freifunk-Netz) bringen, indem ich die 4 verkabelten Freifunk-Accesspoints gebündelt über einen sogenannten »VPN-Offloader« ins Netz lassen, statt jeden separat über eigene VPN-Verbindungen.
Ein Problem batman_adv-basierter Freifunk-Netze ist es, daß in einem geographischen Bereich alle Knoten zu allen anderen Verbindung haben müssen, und irgendwo zentral in dem Meshnetzwerk wird dann die IP-Vergabe geregelt. Da ich an der Firmware schraube, aber auch selbst aktiv Knoten bereit stelle, laufen bei mir halt mehrere, ans LAN angeschlossene, Knoten. Da jeder derzeit zwei VPN-Verbindungen aufbaut und jede Verbindung in die Wolke von jedem Gerät kontinuierlich mit kleinen Datenpaketen als funktional signalisiert wird, kommen da in der Summe bei uns schon ca. 100-200 kBit/sec zusammen. Wohlgemerkt, nur, um das Netz als solches zu betreiben …
Ein »VPN-Offloader« ist in erster Näherung ein Freifunk-Router, der über die Technik »Mesh-on-LAN« anderen Freifunk-Routern über dieses LAN die Möglichkeit bietet, sofern sie »Mesh-on-WAN« aktiviert haben, statt über VPN und Internet über einen anderen Freifunk-Router den Weg in die Wolke zu finden. (Das Problem mit dem VPN ist, daß die CPU der kleinen Plaste-Router nicht mehr als 6-10 MBit/sec ins VPN zu schaufeln in der Lage ist; möchte man mehr, braucht man entweder einen potenteren Router für Freifunk — oder man läßt die VPN-Geschichte z. B. von einer KVM-VM auf einem sowie laufenden PC machen, oder nimmt dafür einen Banana Pi, Odroid, NUC, …)
Was ich nicht realisiert hatte: »Mesh-on-?AN« funktioniert, indem die batman_adv-Pakete als Ethernet-Broadcasts auf’s Medium gegeben werden. »Ja, und?« mag man sich fragen …
Das »Problem« ist, daß Multi- und Broadcastpakete im WLAN typischerweise mit der niedrigsten Geschwindigkeit ausgestrahlt werden (802.11bgn: 1 MBit/sec); Hintergrund ist, daß der AP nicht zwingend weiß, welche Geschwindigkeit die Ziel-Clients unterstützen.
Kombinieren wir nun regelmäßige Broadcasts und die Belegung des Funkkanals für die mehrfache Zeit (gehen wir davon aus, daß normalerweise mindestens mit 54 MBit/sec verbunden wird: 54fache Zeit), wird klar, warum normale Kommunikation beeinträchtigt wird. Hinzu kommt, daß die Geräte i. d. R. sowas wie »listen before talk« machen (Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA)); bevor man selbst sendet, wartet man, bis der Kanal frei ist. Da Broadcasts nun ja deutlich mehr Sendezeit brauchen, kommen andere Geräte in der Zeit nicht zum senden => die Antwortzeit erhöht sich.
Quitessenz: wenn man einen (Gluon-) Offloader im LAN benutzen möchte, darf man keine WLAN-APs im gleichen LAN-Segment betreiben. Effektiv sollte man für das Offloading ein eigenes VLAN nutzen, welches alleinig auf den Ports, an denen Gluon-Geräte mit Mesh-on-?AN hängen, anliegt. Als tagged VLAN darf das Mesh-on-?AN-VLAN niemals im LAN auftauchen, falls APs angeschlossen sind.
Nun mag man sich fragen, warum ich denn noch eigene APs nutze und nicht das »Privates WLAN«-Feature der aktuellen Gluon-Versionen. Das Problem ist, daß bei Mesh-on-?AN eben dieses Feature nicht genutzt werden kann: es liegt dann normalerweise kein »echtes« IP-Netz mehr an, das Netz wird nur für Ethernet-Broadcasts verwendet.
Mesh-on-?AN ist insofern eine nette Option für professionelle Netze; im Heimnetz erscheint es nur von begrenzter Nutzbarkeit.