[Freifunk-Bonn] Firmware Build

Mi Dez 17 12:43:09 CET 2014

Am Wed, 17 Dec 2014 09:52:46 +0100 schrieb Jan Lühr <ff at jluehr.de>:

> > [...]
>
> > Weniger nachvollziehbar ist für mich dann schon, die Kanal-Automatik auszuschalten. Klar gibt es dadurch andauernde Wechsel, aber es verteilt sich so halt auch recht schön und es geht ja hier um kein Frequency Hopping ala Bluetooth nur halt nicht-deterministisch, sondern die wechseln alle paar Stunden mal. Kaum ein Verlust. Dafür erhält man eine gleichmäßigere Verteilung als es ein permantentes Absprechen mit (neuen) Nachbarn, die man ansonsten möglicherweise kaum kennt, mit sich bringen würde. Insbesondere in der Stadt, wo dann die Nachbarn wieder andere Nachbarn haben, die du selber nicht siehst und so weiter. (meine Meinung)
> 
> Ich denke, Deine Überlegungen betreffen kaum die Freifunk-Router. Damit
> das mesh funktioniert, müssen alle Nodes auf dem gl. Kanal senden. Eine
> 2. 2.4Ghz Karte existiert idR nicht. Damit wird bei uns der Kanal fest
> verdrahtet. Mir ist nicht, wie es mit Standard WLAN / ath9k möglich sein
> soll, den Kanal bei dutzenden Geräten quer durch ein Mesh gleichzeitig
> zu wechseln

Ja, mir ging es da um den verlinkten Beitrag, in dem empfohlen wurde auch bei den Nachbarn die Kanalautomatik abzuschalten und sich mit diesen über die Kanäle abzusprechen. Und das wiederum halte ich für schwerer durchsetzbar als es einfach bei der Kanalautomatik zu lassen, zumal diese durchaus gut funktioniert. 

Dass Freifunk auf einen festen Kanal muss, da entweder das ganze Mesh wechseln muss oder keiner, ist klar. 

Daher ja das "verscheuchen", denn ein fest auf Kanal eingestelltes kbu-freifunk.net zählt ja mit und wird von besagten Nicht-Freifunk-Nachbarn und automatisch wechselnden Routern auch erkannt und gemieden, wenn andere Kanäle freier sind bzw. muss halt ebenfalls Konkurrenz ertragen, wenn zu viele andere Router ebenfalls da sind. Zu Gunsten des besseren Zusammenlegens dieser wiederum. 

Das mit dem Absprechen klingt mir nur sinnvoll, wenn man die Nachbarn wirklich überzeugt kriegt, Kanal 1 möglichst ganz zu meiden, da dort ja ganz ganz viel los ist. Das wäre für die Freifunk-Zwecke sicherlich optimal, aber über alle gesehen ebenfalls nicht fair, die sich dann ja um so mehr auf den anderen Kanälen knüppeln.

> > Und die Ausführungen zur Fritzbox werden dort in meinen Augen missgedeutet. Das Verhalten klingt nämlich so, als würde es die Fritzbox so machen, wie es sein sollte: Es wird auf voller gewünschter Kanalbandbreite (40 MHz) ermittelt, ob der breite Kanal frei genug ist. Ist dies nicht der Fall, wird auf eine schmalere Breite zurückgestuft. Und weil sich so ein WLAN-Umfeld ständig ändert, wirds halt alle Nas lang mal probiert. Wenn das nur selten passiert, sehe ich da keine großen Reibungsverluste. Natürlich ist bei dichter Besiedlung HT20 besser, aber das wird ja eben durch die Automatik erreicht, ohne dort auf HT40 verzichten zu müssen, wo das problemlos möglich ist. (meine Meinung)
> 
> Soweit ich Rougu (gerade da?) verstanden haben, waren das Erfahrungen
> als theoretische Überlegungen: Es performed besser, wenn man es ausschaltet.

Das mag sein, will ich nicht abstreiten. Es performt aber sicherlich nicht so viel besser als HT40 dort zu nutzen, wo es problemlos genutzt werden kann. AVM muss sich halt entscheiden und diese Automatik ist wohl der beste Kompromiss für alle. Wenig Verlust für die mit zu vielen Nachbarn, großen Gewinn für die mit wenigen. 

Ich sehe dabei, die Diskussionen werden gerne emotional geführt. Siehe z.B. "Wer glaubt denn im Ernst, bei 5..20 sichtbaren WLANs ganze 10 benachbarte Kanäle allein und sinnvoll nutzen zu können. Das ist nur ein Werbegag!" 
Das ist eine sehr emotionale Aussage, keine technische. Nicht nur weil der Klang alleine schon unsachlich ist, auch die Belegung erfolgt keineswegs _allein_, sondern es können durchaus auch mehrere solcher WLANs gleichzeitig betrieben werden. Dafür gibt es verschiedene Medienzugriffsverfahren wie CSMA/CA, die bei HT40 natürlich ebenso funktionieren und kein Alleinsein erfordern.  Nur die Qualität sinkt halt schneller mit mehr aufkommenden Nachbarn, halt durch die geringere Anzahl überlappungsfreier Kanäle. Rougus Standpunkt ist da rein aus der Sicht, wenns halt zu viele Nachbarn für HT40 werden. Die Sicht ist für diesen Standpunkt dann natürlich korrekt und das ist mit Sicherheit auch entsprechend messbar. 

Ich bezweifel aber, dass das generell gilt. Ganz im Gegenteil würde HT40 in einem Gebiet, in dem sich kaum Nachbarn aber viel Freifunk befindet, sogar positiv auf Freifunk auswirken. Ein 40 MHz-Mesh. Jedenfalls sofern die Technik IBSS mit HT40 überhaupt zulässt und dann abwärtskompatibel ist, so dass 20MHz-Geräte weiterhin die Mesh-Zelle teilen können. 

> > Schlechter finde ich da schon das Verhalten von TP-Link, die halt einfach dennoch HT40 nutzen... Zeitslots finden sich halt immer und leiden tun dann ja nicht die eigenen Nutzer, sondern die anderen. (so jedenfalls mein kurzer Eindruck, kann aber auch Zufall gewesen sein und auch diese Firmware schaltet bei dichterer Besiedlung auf 20 MHz zurück)
> > 
> > Dass gerade eine Community, die bei allem möglichen auf möglichst automatisierte, dezentrale Abläufe setzt (avahi/mdsn, radv, komplettes Bridging, batman über fastd, etc.) anstelle ressourcenschonenderer Verfahren, bei den Punkten bei einer entsprechenden Automatik Probleme sieht, obwohl die Verfahren durchaus erfolgreich etabliert sind und einen vergleichsweise geringen Verlust haben, wundert mich ein wenig. (ihr wisst schon... auch wieder meine Meinung)
> 
> Ich kann Deine Kritik hier nicht nachzuvollziehen. Es gibt Erfahrung wie
> das Zeug am besten performed. Wenn Du Belegen kannst, dass es anders
> besser ist, können wir über einen Wechsel nachdenken.
> Grundsatzdiskussionen helfen überhaupt nicht - bau das Zeug einfach als
> prototyp.

Vielleicht reden wir da ein wenig aneinander vorbei. Dass das kbu-Freifunk aktuell so implementiert ist, wie es ist, will ich nicht kritisieren. Ich habe die aktuelle Implementierung, die eben auch aus Automatiken bestehen, aufgeführt um zu zeigen, dass man sich durchaus bewusst für Automatiken entscheiden kann, auch wenn sie nicht ein eventuelles Optimum darstellen. Eben zum Beispiel weil die optimale Lösung weit schwerer zu erreichen ist. Das ist ja gerade mein Punkt. Der spricht doch sogar _dafür_, dass Freifunk so arbeitet, wie es halt arbeitet?

Oder gibt es Zweifel daran, dass es ein theoretisches Optimum gibt, das über der aktuellen Lösung liegt? Dass das aktuelle Aufkommen von batman-Nachrichten und Ethernet- und IP-Broadcasts quer über alle Gateways, Supernodes und fastd-Links unumstößlich ist? Dass bei jeder Änderung alle informiert werden müssen? Dass zur IP-Vergabe und DNS jeder alle paar Sekunden neue Broadcasts verschicken muss, hauptsächlich an die, die diese Information nie brauchen werden.

Daran zweifel ich wirklich. Sollte das der Fall sein, kann ich das gerne nochmal detaillierter erläutern. Hmmm... wenn das die vorherrschende Meinung sein sollte, dann muss ich mir wohl tatsächlich mal Gedanken machen. Wobei, alleine die Aufforderung zu einem Prototypen: Dass Komplettes Bridging mit batman über Gateways hinweg mehr Traffic verursacht als Routing an den Gateway-Grenzen muss ich nicht erforschen, damit mir das klar wird. Dass mdns und stateless address autoconfiguration über das Gesamte Netz hinweg mehr Traffic verursachen als managed¹ dns/IP ebenfalls. Und dass mehr Hintergrundtraffic weniger verfügbaren Traffic für andere Zwecke bedeutet (sprich: geringere Performance) ist da nur eine weitere Folge. Usw. Da sehe ich schon noch Optimierungspotential. Jeder Knoten hat schon bei der aktuellen Netzgröße permanent mehrere kbyte/s Traffic, ohne dass er sonst irgend etwas macht.

Aber nur weil ich meine, dass es vielleicht eine bessere Lösung gibt, heißt das doch noch lange nicht, dass diese zu bevorzugen wären. Das heißt eben nicht, dass die aktuellen Verfahren für das aktuelle Netz nicht optimal sein können. Nur weil eine Lösung besser ist, muss es noch lange nicht sinnvoll sein, das implementieren zu wollen oder gar zu können. Eventuelle Verbesserungen bringen eine Menge weitere Komplexität, die erst einmal handlebar sein muss. 

Derzeit ist das eine gute Lösung. Erst wenn das Freifunk-Netz weiter wachsen sollte, wird das zum Problem werden. Da glaube ich auch nicht, dass da jemand ernsthaft widersprechen kann. Ein Netz, bei dem bei jeder kleinen Änderung jeder mit jedem Sprechen muss, skaliert halt nicht gut. Das sehe ich ähnlich wie die Anfangszeiten des Internets. Erst hätte eine Broadcast-Domäne gereicht (real war es direkt IP und Routing, aber DNS gabs nicht, weil alle IPs bekannt waren). Dann brauchte man Grenzen zwischen verschiedenen und Routing. Und heute reicht selbst das nicht, da braucht man viele Autonome Systeme, damit die Routingtabellen handhabbar bleiben. Dass das durchaus auch bei Freifunk eine Rolle spielt, sieht man doch an den dort schon vorhandenen Autonomen Systemen wie kbu. Das gesamte Freifunk-Netz ist halt eben jetzt schon keine gesamte Broadcast-Domäne, oder? (so verstehe ich das jedenfalls)
Aber anstatt bei mehr Wachstum im Fall der Fälle z.B. einfach Köln und Bonn zu trennen (so wie Berlin auch nicht kbu ist), sehe ich halt durchaus andere Möglichkeiten, um dann etwaiges Broadcast-Aufkommen radikal zu reduzieren... usw. das würde aber den Rahmen einer Email sprengen².

Wie gesagt, das heißt nicht, dass es mir sinnvoll erscheint, jetzt solche Überlegungen und Prototypen zu entwickeln. Das Netz ist halt aktuell so wie es ist und funktioniert.

Grüße
hede

¹) managed bedeutet nicht, dass das eine zentrale Gewalt alleine macht oder man man auf Redundanz verzichten muss, siehe DNS-System inkl verteilter root-Server und dhcp-Failover.

²) Ach, *träum*, ich hätte glaube voll Spaß daran, sowas zu entwickeln: z.B. für große Mesh-Netze: TTL für normal-batman-Node-Pakete -> nicht alle Nodes kennen sich und propagieren durch das ganze Netz -> Wahl von Ubernodes, die ein Netz im Netz bilden mit extra Ubernode-Routing-Tabellen in den normalen Nodes, deren TTL nur über die Ubernodes sinkt -> UberUberNodes nach dem Matroshka-Prinzip -> hinzustoßende Nodes, die keine Ubernodes sehen, stoßen Wahl an oder werden gleich zu einem -> usw. - Folge -> keine harten Grenzen bzgl. Broadcast-Domäne, aber weiche -> die Uber*nodes müssen dns/dhcp-Vergabe und IP-Routing übernehmen und sich diesbezüglich absprechen, was zwar wiederum Broadcasts bedeutet wie jetzt, aber eben mit einer deutlich geringeren Zahl Uber*nodes der höchsten Instanz, usw. -> hinzustoßende Nodes erhalten IP vom Ubernode, der dazu wiederum seinen UberUberNode fragt usw. bis zum Uber*Node ->  die höchste Instanz muss das untereinander klären -> es muss jederzeit klar sein, was die höchste Instanz ist, was als Tiefenzahl (int) in jedem Node gepflegt werden kann -> Bei wachsender Uber*Node-Instanz-Anzahl Wahl eines neuen ersten Uber*Node höherer Tiefe und Spezial-Broadcast mit Sequenznummer und Tiefenzahl++ -> Wegfallende UberNodes lösen Neuwahl der darunter liegenden Nodes aus -> Nodes mit langer Uptime propagieren zu höheren Ubernodes, was automatisch Neuwahlen minimiert -> usw... ui, das mal zuende zu denken, da hätt ich echt Spaß dran. Wer weiß, kommt wahrscheinlich nie, hab jedenfalls keine solchen plane und ja, möglicherweise ist da der Punkt, der das ganze Konzept über den Haufen wirft, schnell erreicht... aber wer weiß... :-P)