Anderes Performance-Problem beim Meshen

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 Likes

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 Like

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 Like

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 Like

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 Like

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. :smile: