Die Anforderung war, das Mesh abzuschalten. Das tut das.
vgl:
Bin mir nicht sicher ob ohne Bat0 ein Client noch irgendwas im Netz machen kann. Mit Bat0 off schaltest du quasi den verteilten Layer 2 Switch ab.
Diese Antworten verwirren mich nun etwas… Was heißt: „kein richtiges Freifunk mehr“?
Beide Knoten haben eigene Uplinks. Kann man sich ohne „Mesh“ nicht mehr damit verbinden? Oder gilt das Abschalten des Meshens nur für die Knoten untereinander (was ich ja gern ausproieren wollte).
Vielleicht gibt es ja noch eine andere Lösung.
Das Problem bleibt: wenn die oben genannten Knoten sich miteinander verbinden werden sie, wenn die Qualität der Verbindung schlechter wird, also in rot dargestellt wird, immer weniger benutzbar. Das äußert sich in immer längeren Ladezeiten der Seiten, bis hin zu dem Gefühl, das neu aufgerufenen Seiten gar nicht mehr geladen werden.
Diese Verhalten wurde weiter oben auch von anderen schon bestätigt. Gibt es für dieses Problem einen Lösungsvorschlag? Am besten einen, den man auch per ssh und Kommandozeile umsetzen kann.
Ich hoffe, ich konnte mich verständlich ausdrücken… und danke für eure Mühe mit den Antworten…
Wenn ich die Paderborner richtig verstehe, kannst du das Mesh auf dem Wlan abschalten, die Clients aber anlassen → http://wiki.freifunk.net/Freifunk_Paderborn/Mesh-on-WAN_LAN (ganz unten).
Ja - natürlich ist das nicht im Freifunk Sinn, zum Testen oder speziellen Konstellation mag es aber Sinn machen.
Ein grundsätzlicher Baustein aus meiner Sicht, wie gesagt meine persönliche Meinung, ist das ein Freifunk Knoten die Fähigkeit haben sollte sich mit anderen Freifunkknoten via MESH zu verbinden. Schalte ich das MESH auf einem Knoten ab, sende aber die Ortsübliche Freifunk SSID aus, so kann ein Nutzer der denkt er könnte an deinen Knoten andocken in dem er auch einen Freifunk Router in dessen Nähe platziert vielleicht verzweifeln. Weil er nicht begreift wieso sich sein Freifunk Knoten nicht mit deinem verbindet obwohl es eigentlich klappen müsste.
Allerdings gibt es Spezialfälle wo solch ein Setup Sinn macht. In unserer Community gibts ein Hotel welches seine teure kommerzielle und umständliche Voucher Hotspot Lösung gekündigt hat. Der Inhaber hat sich einen Knoten hingestellt und die im Hotel verteilten APs des alten Hotspot Systems umkonfiguriert. Sie strahlen jetzt die Freifunk SSID aus. Das ganze System hat der Inhaber dann an ein LAN Port des Freifunk Routers geklemmt der irgendwo tief im Gebäude steht.
Wir als Community haben dann bemängelt das man auch vor dem Hotel die SSID unserer Community empfangen kann, aber es keine MESH Möglichkeit gibt. Der Betreiber hat das eingesehen und außen am Hotel Pico und Nano Stations angebracht. So das jetzt auch Nachbarn des Hotels sich potenziell am MESH beteiligen können.
http://map.freifunk-uelzen.de/geomap.html#lat=52.913253&lon=10.775232
Viel wichtiger wäre allerdings mal auf einem der Knoten zu sehen was passiert wenn trotz MESH zwischen den Knoten und MESH VPN keine Seiten geladen werden. Zu aller erst aber müsste man wissen wieviel Bandbreite die beiden Knoten für MESH VPN freigegeben haben. Und wieviel Bandbreite die Internet Verbindungen hergeben.
Dann wären auch Ausgaben von batctl gwl von den Knoten Sinnvoll wenn es mal wieder hakt. Um festzustellen welche Route BATMAN_adv zum Zeitpunkt der langsamen Verbindung gewählt hat.
2 „Gefällt mir“
im Prinzip ja, aber die Verbindungsqualität muss konkret nutzbar sein. Ein Mesh mit z.B. 97% Packet loss ist Murks, besser kein Mesch.
Diesen Paketloss sollte ein Routingprotokoll erkennen und umschiffen können. Die Gründe wieso es in dem Fall nicht passiert sind zu erforschen und falls belastbare Ergebnisse vorliegen diese den Entwicklern mitgeteilt werden. Kann aber auch sein das der Fehler schon bekannt ist und in neueren Protokoll Versionen schon behoben worden ist. Die meisten Gluon Freifunk Communitys verwenden noch ein älteres BATMAN Protokoll.
1 „Gefällt mir“
Vielen Dank für die ausführliche Darlegung deines Standpunktes - der für mich absolut einleuchtend klingt.
Die Situation ist die, dass ich schon seit ca. 3 Monaten versuche, einen weiteren Knoten quasi auf der halben Strecke zu etablieren. Trotz der Hilfe anderer Aktiver ist das leider bis jetzt nicht gelungen, wird aber natürlich weiter verfolgt und bekommt bei jeder Veranstaltung auf dem betreffenden Platz neue Unterstützer.
Es sind auch nicht die Betreiber der Knoten mit der Bitte nach einem Router aufgetaucht, sondern es war eher so, dass aktive Leute aus dem Stadtteil das Ziel hatten, den entsprechenden Platz mit freiem W-Lan/Internet zu versorgen. Das hat einige Überzeugung gekostet, schon ein paar kleinere Problemchen verursacht und ich möchte die Geduld der Anschlussspender nicht überstrapazieren.
Bevor das Cafe jetzt wieder abspringt weil die Gäste sich erst freuen, dann aber wegen der Performance häufig enttäuscht sind, versuche ich auf diesem Weg zunächst eine technische Lösung zu finden.
Natürlich ist auch richtig, dass eine genauere Analyse uns bei dem Problem weiter bringt, dummerweise tritt es nicht kontinuierlich auf.
Die Internetzugänge haben min. 16000 auf der einen, der andere müsste sogar ein VDSL sein. Die Bandbreite habe ich nicht begrenzt…
Wenn es eine etwas genauere Anleitung für den letzten Absatz, vielleicht auch im Wiki, gibt, bin ich gern bereit weitere Daten zu sammeln.
Nach meiner bisherigen Erfahrung würde ich sagen:
Links mit „Linkquality“ (alte ffmap-metrik) oberhalb von 1.5 sind nicht mehr brauchbar. Die Komfortzone verlässt man schon bei 1.3.
(Und bei mehreren Hops müssen das Produkt aller unterhalb von 1.3/1.5 liegen, was ein toughes Ziel ist…)
Daher: Router haben einen idealen Abstand. „Näher als 5m“ ist genauso schädlich wie weiter als „80% TC“.
Von daher sind Riesenwolken zwar ein toller Traum, aber zumindest für „responsives“ Webbrowsen (inkl. so einem AJAX-Gefiedel wie dieses Forum hier) kaum sinnvoll nutzbar.
1 „Gefällt mir“
Zudem kann man noch sagen Bandbreite n/2 je Wifi Hop.
Kann man sagen, stimmt aber nicht, zumindest für >2 hops.
(Ausgenommen: die Nodes hören sich alle gegenseitig, routen die Pakete aber trotzdem „im Kreis“ statt direkt von Start zu Ziel.)
Bei einer angenommenen Linkquality von 100.
Ansonsten würde ein LAN aus verketteten Switches auch exponentiell langsamer mit Anzahl der Hops.
Hast du nochmal richtig hohe Grenzwerte versucht? Adorfer schrieb, dass weniger als 80% linkqualitat nachteilig sei. Ich würde es mal mit 30000 oder sogar 40000 versuchen.
Ich weiß nicht, ob das jeder auf dem Schirm hat, aber @Oli s Problem besteht, obwohl beide Knoten einen Uplink haben. Ich habe das Gefühl im Laufe der Diskussion war das nicht allen 100% klar.
Generell scheint es hier aber definitiv ein Problem mit BATMAN zu geben. Es darf nicht sein, dass meshing mehr kaputt macht als es hilft. Genau das passiert hier jedoch.
In diesem speziellen Fall würde ich definitiv die Abschaltung der Mesh Funktionalität über die Luft befürworten.
Dann sind wir ja inzwischen wieder bei einer sinnvollen Fragestellung angekommen (statt „Mesh komplett abschalten“, das dann ja auch das VPN-Mesh beinhaltet)
Lässt sich nicht nicht für eine Verbindung nachträglich eine extreme Hop-Penalty drauflegen?
Würde mich auch interessieren, da ich die Situation habe, das auf Grund der physikalischen Anordnung der Knoten immer der langsamere Uplink benutzt wird, und der schnellere nur die direkt an diesem Router angemeldeten Clients versorgt.
Daher suche ich nach einer Möglichkeit, den Meshlink zum langsameren Uplink zu benachteiligen.
1 „Gefällt mir“
Ich würde gemäß dieser Seite mal ein
echo 255>/sys/class/net/bat0/mesh/hop_penalty
versuchen.
Und wenn das hift, das in das richtige Config-File schreiben, oder besser gleich in die /etc/rc.local, damit es beim Update bleibt.
Das Funktioniert so nicht.
Am 11.02.2015 um 09:19 schrieb Jan-Philipp in gluon@luebeck.freifunk.net:
Das stimmt leider nur bedingt: Die hop_penalty wird für Routen ÜBER den
aktuellen Host angewandt, nicht aber für die Route des aktuellen Hosts
selber. Konkret heißt dass, in einem Setup A–B–C würde eine
hop_penalty auf B die Route von A nach C und vice versa verschlechtern,
aber die von A oder C nach B nicht.
Und auch die Seite die du angegeben hast schreibt:
The value is applied to the TQ of each forwarded OGM
Also nur auf weiter geleitete OGM wird die Penalty drauf geschlagen und nicht auf die selbst gesendeten. Bei zwei Knoten die sich direkt sehen kannst du den Link nicht künstlich verschlechtern.
1 „Gefällt mir“
Aber die Route erfolgt doch von Deinem Nachbarnode „A“ über Deinen Node „B“ ins Meshvpn zum Endpunktnode „C“ (gateway)
Damit sollte eine Hoppenalty auf B doch genau das erreichen.
Oder geht es darum, dass Du bei Dir auf dem Node lokale Dienste hast, die nicht von B nach A sondern über C geroutet werden sollen?
Meine Antwort bezog sich auf dieses Problem:
Ein Knoten welcher direkt ein MESH VPN hat wird seine Clients niemals über ein oder zwei weitere Hops zu einem schnelleren Uplink routen. Und er kann das MESH VPN für diesen Knoten nicht explizit schlechter machen. Da Hop Penalty hier noch nicht greift. Und da BATMAN die Bandbreite nicht in die Link Qualitätsberechnung mit einbezieht zählen quasi nur die Anzahl Hops. Deswegen werden in einer Wolke die Knoten den Traffic immer so leiten das der kürzeste Weg zum Gateway/Supernode genommen wird.
In einem Szenario mit den Knoten A - B - C, wobei A und C einen Uplink haben, werden Clients an A und C nur die Bandbreite der MESH VPN Verbindung nutzen können und nur bei Clients an Knoten B könnte es sein das je nach Metrik entweder nach A oder C geroutet wird.
Für das Problem von @Oli könnte die Hop Penalty allerdings die Lösung sein. Da das andere Gateway jeweils schlechter gemacht wird und die Knoten trotzdem Meshen können um lokalen Traffic direkt auszutauschen.
Dann sieht es leider so aus, als könnte ich an der Situation nichts ändern.
Trotzdem danke für die Antworten. 