WLAN-Meshen bestimmter Knoten untereinander via SSH-Befehle unterbinden. Wie geht das?

Hallo Leute.

Für bestimmte Testszenarien möchte ich das Meshen per WLAN zweier bestimmter Freifunk-Knoten gern unterbinden. Da sich die beiden Knoten auf kurzer Distanz hier in meiner Wohnung natürlich beide empfangen können, kann ich das schwerlich durch größeren Abstand entkoppeln.

Und in eine HF-dichte Blechkiste möchte ich auch keines der Geräte stecken.

Dunkel erinnere ich mich, dass via SSH-Konsole man bestimmte Befehle absetzen kann, um Clients von Knoten auszuschließen.

Geht das auch für das WLAN-Meshnetzwerk für benachbarte Knoten?
Und wie mache ich dann nach den Tests das wieder rückgängig?

LG
Jörg

du kannst meshwifi oder das clientwifi jeweils ganz abschalten … du kannst aber auch falls du verkettungen testest die penalty sehr sehr sehr hoch drehen bei einzelnen knoten …
schau mal bei den helfer skripten von mir , da findeste „dinge“ zum spickeln meshwifi 0 oder hop_penalty 200 bspw.

2 „Gefällt mir“

Siehe in diesem etwas ältere Thread.

Hallo…
Wir haben in unserer Gemeinde in manchen Bereichen ein flächendeckendes Freifunknetz. Mich freut der Zuspruch als Initiator sehr und fühle mich in der Pflicht die Verbindungen zu optimieren, da die Geräte mitunter sinnfreie Verbindungen aufbauen. Ich habe die Probleme in der lokalen Freifunkgruppe schon angesprochen. Leider konnte mir dort aber bisher niemand helfen. Hier mal den Beitrag den ich in der lokalen Freifunkgruppe geschrieben habe:

Ich hab nun mehrere Versuche unternommen doppelte und dreifache
Verbindungen zu blockieren, da ich es für wenig sinnvoll erachte
Verbindungen über Lan und zusätzlich über WLAN herzustellen.

Außerdem
würde ich gern einige Verbindungen, die nicht stabil sind und über
andere Knoten viel besser laufen gleich von vornherein unterbinden, da
dies das Netz entlasten könnte.

Ich habe Versuche mit folgenden Abfragen unternommen:

uci set wireless.mesh_radio0.macfilter=deny
uci set wireless.mesh_radio0.maclist=‚mesh0-MAC oder bath0-MAC‘
uci commit wireless
wifi
/etc/init.d/network restart

Oder auch mit
vi etc/rc.local
iw dev mesh0 station set plink_action block
ESC
:wq

Test erfolgte auch in /etc/config/wireless

Leider alles ohne Erfolg.

Kann natürlich sein, dass mein Ansatz völlig falsch ist. Es wäre richtig dufte wenn jemand hierfür eine Lösung hätte.
Liebe Grüße in die Freifunkrunde…

Ich kann von deinem Vorhaben nur abraten. Batman nimmt automatisch die bessere Verbindung. Also wenn ein Kabel da ist, wird das auch genutzt.

Wenn du jetzt umständlich die Wlan-Verbindung blockierst und morgen stolpert jemand über das Kabel, hast du ein Problem, weil kein automatisches Umschwenken erfolgen kann.

Das was du vor hast, eine feste Strecke zu definieren, übernimmt das Meschprotokoll für dich. Dafür gibt es dieses Batman.

Es kann in Einzelfällen mal sinnvoll sein, das Wlan-Mesch zu deaktivieren, wenn man besser per Kabel um zwei Ecken gehen kann.

Magst du mal einen Link zu der Wolke einstellen? Dann kann man das etwas konkreter besprechen und schauen, wo die Probleme liegen.

Grüße
Matthias

1 „Gefällt mir“

Siehe Einzelne Wifimesh links unterbinden? - #11 von adorfer und Einzelne Wifimesh links unterbinden? - #14 von adorfer

Das möchte ich auch nicht für jeden Router machen, Es gibt aber 1-3 wo das wirklich sinnvoll ist, da die Internetverbindung ständig von einem auf einen anderen Zugang wechselt und in der Zwischenzeit der Nutzer in der Luft hängt.

[quote=„MPW, post:5, topic:13550, full:true“]
Es kann in Einzelfällen mal sinnvoll sein, das Wlan-Mesch zu deaktivieren, wenn man besser per Kabel um zwei Ecken gehen kann.[/quote]
Ein komplettes Deaktivieren des Mesh kommt bei diesen Geräten nicht in Frage, da sie sehr wohl kommunizieren sollen, aber nicht mit jedem um das oben beschriebene Problem zu umgehen.

Ich denke schon, dass ich mit dieser Einstellung sehr behutsam umgehen werde und nur im Notfall einsetze.
Allein die Möglichkeit zu haben (auch für Tests) wäre sehr praktikabel. Wenn das ganze am Ende nichts bringt, kann ich es ja auch wieder deaktivieren.

Nur haben sollte man die Möglichkeit schon.

1 „Gefällt mir“

Hallo.

„MAC80211 mac filtering happens via hostapd which is not used in Ad-Hoc mode.“
https://dev.openwrt.org/ticket/10179

D.h. für das Meshinterface wird der Macfilter nicht funktionieren.

Gruß Christian

1 „Gefällt mir“

Für mich als Laie zum Verständnis:
Das Ausfiltern via MAC-Adressen geht ausschließlich im Client-WLAN-Netzwerk auf dem FF-Knoten.
Ausfiltern von anderen Freifunk-Knoten, um gezielt nicht per WLAN zu meshen, geht also nicht, korrekt?

@ffksBeteiligter … versuche doch auf den Knoten die nicht komisch meshen sollen, an denen die Weiter weg sind etwa das dreifache an hop_penalty zu geben und der der prefferiert werden soll etwa 2/3 … damit verhinderst du in der Regel das Batman diese Verbindungen benutzt, da sie aus sicht von Batman schlechter sind.
in der Regel als da wos lang soll 10 und da wos hinten nicht lang soll 45. - eine genaueres Bild (Meshviewer oder Handgemalt mit bezeichnungen wär schon sehr sehr Hilfreich, wie @MPW meinte )

hier steht sehr viel, manchmal sehr technisch erklärt … Tweaking - batman-adv - Open Mesh

Hm, alles ziemlich kompliziert…

Für meine Tests werde ich wohl bei meinem heimischen Freifunk-Router für die Testzeitdauer einfach das Wifi komplett abschalten (Taste) oder bei längeren Aktionen das Meshen via uci set-Kommando ab/anschalten.

Schade, dass ein deny nur bei clients geht.

Was soll das bringen?
DAS problem löst der Batman schon völlig allein. Ohne Nachhilfe.
Die lokale Airtime wird durch das überflüssige Mesh trotzdem verpested, da sowohl der TQ-Graph (und der Routinggraph damit der Updatetraffic für TG etc) explodiert (und verteilt werden möchte an alle Nodes, inkl. der niemals sinnvollen Links)
Es müssen nicht die Router 6km weiter erfahren, dass die 20 Router in der lokalen Wolke untereinander 350 aktive Meshlinks haben und stets wissen, wie gut die TQ für jeden dieser Links ist.

Es kann nur Einbildung sein, aber ich habe das Gefühl je mehr sinnfreier Meshverbindungen zustandekommen desto problembehafteter ist die Performance, desto schlechter wird der TQ der guten Verbindungen und wie beschrieben hängen die Nutzer für den Moment des Wechsels von der einen zur anderen Verbindung zusätzlich in der Luft.
Außerdem fühle ich mich entmündigt, wenn ich nicht selbst bestimmen kann welche meiner Router miteinander kommunizieren. :wink:
Ich hatte irgendwo mal gelesen , dass die Verbindung auf beiden Seiten der jeweiligen Router gesperrt werden müsse um diese Vernetzung zu unterbinden.
hop_penalty hilft mir da auch nicht weiter, da ich dann andere Verbindungen, welche über diesen Knoten laufen sollen benachteiligen würde.

Wie wäre es, wenn du die, die miteinander peeren sollen im Mesh jeweils eine gemeinsame Mac gibst? Ich bin nicht sicher, aber man sollte auch mehr als ein Mesh Interface anlegen können. Die nicht meshen sollen, müssen verschiedene Mac haben.

Sorry, wenn meine Beschreibung unklar war.
Ich hätte vielleicht dazu sagen sollen, dass der Batman-Overhead dazu führt, dass die TQ auf den benötigten Links sinkt.
(Übrigens tut sie das auch, wenn dort nicht gemeshed wrid, das liegt schlicht an der fehlenden Airtime)
Abhilfe: Kabel-Links und Kanal/Frequenzbelegung überlappungsfrei gestalten.

DAS ist auch einer der vielen DoS-Vektoren, die ein Freifunk-Mesh hat.
Unfreiwillig hatten wir das bei einigen Gluon-Versionen für den WDR4900.

Anway: Was Du meinst: Ändern der Mesh-SSID.

Ach so, falls man noch historisch auf „adhoc“ meshed, dann würde ich erstmal auf 11s umstellen, das bringt auch schon mal ein paar Prozent.

Ich weiß nicht so recht wie ich es erklären soll.

Deshalb noch ein Beispiel:

Station A steht in einem Internetfreiem Gebiet und verteilt dort an weitere Stationen…
Station A hat konstante MeshVerbindung zu Station B (Internet) mit stabilen TQ 65%-95% durchweg.

Alles wäre super, wenn nicht Station A zur Station C (Internet) die oft zwar keine Verbindung hat, dann aber gelegentlich Spitzen mit 90% hätte, zu kurzen Zeitpunkten an denen Verbindung A-B einen wesentlich schlechteren, aber stabilen TQ aufweist, eine Verbindung herstellen wûrde.

In diesem Fall übernimmt unnötiger Weise kurzzeitig Verbindung A-C bis diese Verbindung wieder abbricht. Durch den Wechsel entsteht eine merkliche Ausfallzeit in der die Nutzer in der Luft hängen.

Genau das Problem würde nicht entstehen, wenn ich Verbindung A-C von vornherein unterbinden könnte.

Station C soll aber auch nicht mit Strafe belegt werden, da sie wiederum für andere Stationen die bestmögliche Verbindung darstellt.

Netzwerk läuft über 802.11s

1 „Gefällt mir“

Dann kannst du entweder einen MAC Filter setzen, der A / C verbietet, oder wie von fuzzle angesprochen die hop penality auf A hoch setzen und diese Verbindung unattraktiver werden zu lassen.

…ich dachte, im Mesh-WLAN ginge das mit dem deny via MAC nicht? (Nur im Client-WLAN)

So hatte ich die Ausführungen von DL3DCF etc. verstanden.

Bei 11s soll es gehen (nach Doku). Bei AdHoc geht es nicht (getestet).

Ich bezweifle übrigens, dass das was bringen wird. Meist ist einfach der Kanal dicht. Das hab ich selbst schon in größeren Installationen gesehen, wenn alle über Kabel verbunden waren. Sobald man einige auf andere Kanäle umstellt, wird es besser.

Ggfs., wenn es per Lan nicht überall geht, kannst du zwei 841er direkt nebeneinander stellen. Einen auf Kanal 1 zum meschen und einen auf Kanal 5, 9 oder 13 für das Clientnetz, ohne Mesch. Die beiden natürlich dann per Kabel verbunden.

Grüße
Matthias

1 „Gefällt mir“