Leider fällt ab und zu die WLAN-Mesh-Verbindung aus, dann ist in der Unterkunft für die Bewohner Freifunk komplett weg. Denn Maßgabe zur Installation war, dass rund um bzw. vor dem Büro kein Freifunk sein soll (enger Gang, Fluchtweg etc.).
LAN-Mesh fällt leider aus, keine Kabelwege im Haus vorhanden.
Nun die Frage: Ein Watchdog zum reboot des Büro-Freifunkrouters bei Wegfall einer WLAN-Meshverbindung wäre ein möglicher Weg, denn per Hand hatte ich das so gemacht und dann ging alles wieder. Oder was für Möglichkeiten gäbe es, die WLAN-Mesh-Verbindung zwischen beiden Geräten zu re-initiieren?
Schau mal das an.
Das schaut auf allen Interfaces, „ob es allein ist“. Und wenn (nach einem Booten) hinter einem Interface mal mindestens zwei Knoten gesehen wurden, dann merkt er sich das. Wenn dann irgendwann dort plötlich „nix mehr ist“, dann wiederholt er die Prüfung noch 3 mal (chron…) und bootet dann ggf. neu durch.
Gibt auch false positives… klar. Aber besser „so herum“ als anders.
Ein wifi reload könnte schon ausreichen. Kommt auf den Versuch an, evtl. genügt es, auf dem 1043er das WLAN neuzustarten.
Laut Statistik ist der Traffic ja < 1 Mbit/s, da könnte es auch einen Option sein, den 841er und den 1043er zu tauschen. Die Bandbreite schafft der 841er ja locker über fastd.
Ich vermute, dass das Problem beim 841er liegt. Die verlieren bei mir auch gerne die Verbindung.
Ich habe mir ein kleines Script geschrieben, dass alle 20 Minuten durch die crontab ausgeführt wird
0-55/20 * * * * /etc/dropbear/testmesh
testmesh kommt in den Ordner /etc/dropbear/:
#/bin/sh
# Test auf Verbindungen zu anderen Routern auf mesh0.
# Router Dreesertor 1
MINUPTIME=1800
IPV6="fda0:747e:ab29:2241:9ade:d0ff:fe31:7886"
MAC="52:3f:79:ac:6c:e9"
logger Cecking connection to $MAC
test "$(iwinfo mesh0 assoclist)" = 'No station connected' && ( logger "All stations lost!" ; wifi ; exit 1 )
### mesh0-Verbindung testen ###
TQ=$(batctl o | grep "^$MAC" | sed 's#).*##; s#.*( *##')
logger "BATCTL TQ = $TQ"
[ -n "$TQ" ] && [ "$TQ" -le 100 ] && ( logger "Bad connection TQ = $TQ" ; wifi ; exit 1 )
ping -c 10 $IPV6 || ( test $(sed 's#\..*##' /proc/uptime) -ge $MINUPTIME && ( sleep 70 ; /bin/touch /etc/banner; /sbin/reboot ))
Man sollte den Router nicht zu schnell booten. Wenn es auf zwei Routern läuft, sollte es zeitversetzt laufen, damit das Script nicht einen Rboot startet, weil der andere Router gerade rebooted.
Nach meiner Beobachtung gibt es mindestens drei Zustände:
Auf dem mesh0 werden keine verbundenen Stationen mehr gefunden. Dann reicht es wifi neu zu starten.
Die Verbindung steht noch, aber die TQ bei BATMAN ist zu niedrig, dann hilft ein wifi restart.
Die Gegenstelle ist nicht mehr über ping erreichbar. Dann starte ich den Router neu.
Die Zeiten und Schwellwerte sollten nicht zu niedrig, sein der „normalen“ Leitung anpassen.
Die IP-Adressen und MAC müssen natürlich für die Gegenstelle angepasst werden.
In einer anderen Unterkunft laufen ebenfalls zwei 841er rein mit WLAN-Mesh. Der 1043er stellt die VPN-Verbindung über den landkreiseigenen Speedport-Router und der 1043er darf dort auch Clients versorgen.
Da beobachte ich solche Ausfälle aber nicht. Die Installation läuft so schon zwei Jahre ohne nennenswerte Probleme.
Diese Ausfälle gibt es nicht überall. Manche Bereiche fallen selten oder nie aus, andere regelmässig. Es sind auch kurze Strecken betroffen. Manchmal sind Nodes noch erreichbar, sich aber nicht beim Hopglass Server.
Dafür sind die Pakete gluon-check-mesh und gluon-check-client-mesh zum Checken und gluon-rsk-block-mesh zum Blocken von Meshverbindungen mit 11s gescripted worden: github
bei der stable 2.9.11 in Rhein-Sieg bereits eingebacken, aber in der config per default nicht aktiv gesetzt (paket gluon-rsk-config)
Für alleinstehende nodes gibt es das gluon-robinson Paket.
Das Problem (bzw wahrscheinlich auch mehrere WLAN-Probleme?) ist leider schon länger bekannt und verschiedenste Communities haben sich schon eigene Scripte gebaut. zuletzt zb hier
Übrigens: Ein WLAN-Restart scheint oft gar nicht notwendig. Ein WLAN-Scan (iw dev wlan0 scan) und das Gerät funkt meist wieder normal. Letztens reichte sogar das Aus- und Einschalten vom ANI
Beim „normalen“ WLAN- oder Geräteneustart (wifi bzw. reboot) ist zu beachten, dass batman-adv „hängen“ bleiben kann! Wir nehmen da bei uns lieber „reboot -f“.
Bitte vergesst auch nicht, das eigentliche WLAN-Problem quasi „im Auge“ zu behalten. zb per logger, zentralerem Logger oder anderen Statistiken. Wie oft und unter welchen Umständen treten die Abbrüche auf?
Aber bitte im ersten Versuch nur als „lopri“ (low priority), ansonsten wirft man damit wahlweise die noch vorhandenen Clients und/oder die noch bestehenden Meshverbindungen -bis zum nächsten Reconnect- ab.
Gar nicht so einfach, wenn der Router nur über mesh im Netz hängt. Beim reboot ist leider auch das log weg. Bei denen, die pber WAN erreichbar sind, ist mir noch nichts besonders aufgefallen, außer das die Verbindung auf 1.0Mbit/s für TX jnd RX runtergeht.
Das ist einer der bekannten wifi-AT9K-Bugs.
Auch dafür gibt es scripts. Nicht nur das obere, sondern auch den „ATH9k-blackout“-Workaround.
Der ist etwas schonender als das bisher hier vorgeschlagene:
@Byggvir ja genau. aber zumindest bei der freifunk-gluon-variante mit der passenden statistikfunktionen gibt es ja zumindest einen ansatz, zb über die immer abgefragte „uptime“. Ist die eigentlich mit in den grafana-statistiken bei gluon? Wenn ja, sieht man die Reboots ja dort recht gut.
Erweiterte Statistikfunktionen über die Reboots der Nodes (sowie auch der Ausfälle aller VPN-Verbindungen) könnten das besser visualisieren, wäre ein eigene Thema wert!
Allgemein gesagt sollten „wichtige(re) Freifunk-Nodes und -Verbindungen“ möglichst immer doppelt oder dreifach vorhanden sein, um auch dort den Vorteil von Mesh-Netzwerken „mitzunehmen“.
Ein einziger (wie auch immer, zb Netzteil) Ausfall von einem einzigen (beliebigen) Freifunk-Router sollte keine Auswirkungen auf die Funktion des verbliebenen Netzes haben).
Damit ergeben sich zwangsläufig relativ viele mesh-on-lan-Kopplungen (aka Kabelkopplung), jeder (wichtige) Freifunk-Router ist damit also auch nach wlan-Verbindungsverlust erreichbar :-o Wir haben mit diesem Prinzip (soweit realisierbar) gute Erfahrungen in der Praxis gesammelt. Für @ffksBeteiligter würde das bedeuten, halt noch einen weiteren 841 auf jeden Funk-Seite hinzuhängen, möglichst dann auch mit Kabelkopplung zum bereits vorhandenen 841. Dann würde es auch mit einem zentralen Syslog-Server klappen bzw. wäre ssh-Zugang zur Fehlersuche möglich.
@adorfer Dein zitiertes Script von Hochstift schaltet ANI lediglich ab. Ein dauerhaftes Abschalten scheint aber ungünstig, da ANI eigentlich doch recht sinnvoll ist. Vielleicht sollten wir die ANI-Werte (es gibt mehrere Variablen) mal genauer anschauen?
Dass ein WLAN-Scan bei dieser Art Verbindungsproblemen hilft, scheint mir auch mit Blick auf die ANI-Einstellungs-Sourcen plausibel, denn dort gibt es in den (dauerhaft neu ermittelten) ANI-Werten Ausnahmen für den Fall eines gerade durchgeführten WLAN-Scans.
Weisst Du, wie Freifunk-Hochstift zu diesem Package steht und quasi allgemein dort die „Freifunk-Erfahrungen ohne ANI“ sind?
Bei 2 Installationen hier sind die Uplinks über cpe210 kritisch, um die Einrichtung zu versorgen. Dafür werden die Pakete checkmesh und checkgw aus der Firmware benutzt, die Downtimes massiv reduziert haben. Die scripts lösen im fortgesetzten Fehlerfall reboot aus und sind u.a. hier und hier im Einsatz. 20171101_ff_rsk_firmware.pdf (1,2 MB)
Heute nachmittag gab es wieder einen WLAN-Mesh-Ausfall zwischen ffks-ap100 (Büro-Router) und ffks-ap101 (AP im Gruppenraum), wie ein humanuider watchdog (Danke Thorsten ) meldete.
Daraufhin habe ich „wifi“ auf dem Büro-Router abgesetzt, und sofort war alles wieder tacko!
Die anderen Methoden werde ich das nächste Mal testen.
Aber das bitte nicht „per cron“ blind ausführen, weil das potentiell jeweils an den durchaus noch funktionierenden Linkverbindungen „wackelt“. zum Proben mit option „lowpri“ ausführen.
) meldete.