Wifimesh-TQ fällt sporadisch unter 10%

Hi,
ich habe einen Router C, der per wifi mesh an Router A und B angebunden ist.
Router A und B haben VPN Uplink.

Beim Problemrouter C (ein 841) fällt mindestens einmal am Tag der TQ auf 4% runter und wird in der Karte als offline angezeigt. C steht direkt nebenan, die Funkverbindung ist mit -50dbm sehr gut.

Problem ist wohl hier schon beschrieben:
https://github.com/freifunk-gluon/gluon/issues/605

Ich habe den Router schon gegen einen anderen getauscht, gleiches Problem.

Auf Router B habe ich Zugriff, und kann mit ‚iwinfo phy1 scan && wifi‘ ein TQ auf 50% hochschubsen, dann fällt es aber sofort wieder runter. Der Router kriegt auch keinen Namen.

Ich habe im Gebäude ca. 50 Clients gleichzeitig, pro Woche ca. 1000 Nutzer.
Die Konfiguration im Gebäude ist schnell. Aber nur, wenn das mesh auch funktioniert.

Was denkt Ihr, muss ich hier einen Cronjob einrichten der alle 3 Stunden rebootet, oder vielleicht eine Zeitschaltuhr einbauen?

Ich würde vorschlagen, ein neueres Gluon zu benützen.
(Welches es derzeit ist, keine Ahnung, aber in den letzten Monaten wurde da signifikante Verbesserungen erzielt.)

Ansonsten gibt es da zahlreiche Wlan-Blackou/Keepalive-Pakete in den verschiedenen Communities.

Ist immer aktuell.
Zur Zeit 2016.2.3+bremen1

Dann wirst Du wohl eines der vielen Pakete nutzen müssen, welches versucht a) diesen Zustand zu erkennen und in dem Fall dann auf dem wlan-interface ein „iw dev $linkname scan lowpri passive“ abzusetzen.

Könnte ich deinen Befehl denn als Cronjob einrichten?
Muss ich hier bei $linkname radio1 eintragen (für 2Ghz), oder wofür steht das?

Das Problem kenne ich auch von einigen Routern. Auch ein 3600 verliert hier alle seine Nachbar. Und der ist der einzige Uplink.

Da verwechselst Du etwas.
Das ist ein anderes Problem, und da hilft ein simples Blackout script.
Hier geht’s um die Wifimesh-Links, die auf 1-10% (typisch: 2%) einbrechen.
Das macht die Sache zumindest für „simple scripte“ schwer zu fassen, da man nämlich wirklich nach der TQ im „batctl o“-output parsen muss und nicht nur auf „alle Nachbarn auf Interface xy weg“ parsen kann.

Ich kenne hier das Problem mit Nanostations M2. Seit diese auf 2016.2.4 sind, ist das Problem jedoch nicht mehr aufgetreten.

1 Like

Das < 10% ist aber nur eine Vorstufe zu weg. Und es gibt auch Verbindungen, die nur mit Mühe auf 10% kommen. Da ist die Unterscheidung nicht so einfach.