Ich hatte ähnliches Problem. Ein CPE hing per mesh an einem 841er und war immer mal wieder für Stunden weg, kam aber meistens von allein wieder.
Ich habe in diesen offline-Phasen nicht von dem Meshpartner aus drauf zu greifen können, kein ping, kein ssh, keine wlan-Verbindung.
Die Wlanverbindung geht nur durch die Wand, Wettereinflüsse und andere störende Wlans schließe ich daher als Ursache aus.
Ich habe das Gerät ausgetauscht. Der neue hängt am gleichen Kabel und gleichem POE-Adapter am gleichen Fleck und funktioniert jetzt einfach.
Der alte liegt in meiner Werkstatt zur Beobachtung - und funktioniert jetzt seit 2 Wochen ohne Ausfall.
Das gleiche Setup habe ich nochmal an anderer Stelle hängen - und funktioniert dort einfach.
Starte alle 10 Minuten ein script welches batctl o | wc -l auf LE 4 testet für 5 minuten schlafen geht, nochmal testet und bei nach wie vor erfülltem Kriterium einen reboot macht.
ähm, das doch lieber als cronjob direkt … wozu das extra skript
auf dem rooter einloggen und
crontab -e
*/5 * * * * if [ $(batctl o | wc -l) -le 4 ] then sleep 30; if [ $(batctl o | wc -l) -le 4 ] then reboot; fi ; fi
das sollte wenn ichs richtig gemacht haben alle 5 minuten checken ob du mind 4 clients am batman hast und wenn nein , 30 sekunden später nochmal testen und wenn dann immernoch nicht genug da sind rebooten. (man will 2 mal testen , weils ja mal sein kann … ganz kurz halt)
wir haben mal was ähnliches gebraucht, da haben wir 3 mal in 60 Sekunden hintereinander gecheckt ob noch Internet (ipv4 geht) wenn nicht - reboot … eine Zeit lang war das ein echtes Problem … hatte was indifferentes mit fastd und alfred zu tun, weil wir das nicht eingrenzen konnten haben wir uns damit beholfen … nicht schön aber wirksam
Nunatak: nice one … ich würd da lieber alle 10 minuten mehrfach verschachteltes if, oder while true als 1 cronjob laufen lassen … aber das vielleicht geschmacksache,
das ganze kannst du auch in /tmp schreiben … das dann ram … ist dir ja egal wo da welcher zähler steht. und dann würde ich statt reboot im script eben noch ein „echo failboot $(date) >> somefile_not_in_ram“ schreiben
Verändert, damit es nun auch mit dem 2016.1 läuft:
#! /bin/sh
mname=$(uci get wireless.ibss_radio0.ifname) || mname=$(uci get wireless.mesh_radio0.ifname)
if [ -z "$mname" ] ; then
exit 0
else
echo radio: $mname
mesh=$(batctl o|grep $mname|wc -l)
wmesh=$(iw dev $mname scan|grep $mname|wc -l)
echo meshneighbours: $mesh wifineighbours: $wmesh
if [ ! -f /tmp/noisland ] ; then
if [ "$mwesh" != "0" ] ; then
echo 1>/tmp/noisland
fi
else
if [ "$wmesh" == "0" ] ; then
if [ -f /tmp/wifipbflag ] ; then
reboot -f
else
echo 1>/tmp/wifipbflag
fi
else
if [ -f /tmp/wifipbflag ] ; then
rm /tmp/wifipbflag
fi
fi
fi
fi
Vielen Dank für deine Mühe! Mit den Scripts als Workaround kann man schon gut leben, zumindest werden längere Downtimes verhindert. Aber hat eigentlich schon mal jemand die Ursache herausgefunden? Sollte das Problem mit der 2016.1 eigentlich nicht sowieso verschwunden sein?
Mich würde wirklich mal interessieren woran das liegt.
Bei mir laufen 2 CPE210 V1.0 seit Monaten ohne Probleme mit 2015.1 und seit Dezember mit dem Gluon Master Stand 12/2015. Beide hängen an einem POE Netzteil (POE Passthrough), und sind mittels „billig“ Flach-LAN-Kabel angeschlossen, insg. etwa 15m.
Zum Glück kann ich keine Probleme feststellen. - Irgendeinen Grund muss das ja haben.
Das Problem wandert mit Geräten.
Wenn man also eine andere CPE210 hinhängt, dann läuft die durch.
Und die ursprüngliche CPE210 zeigt den Effekt dann am neuen Standplatz. (trotz anderer Kabel und anderem Netzteil).
Ist also wohl wirklich etwas individuelles.
Trotzdem kein Grund, das deswegen in Garantieabwicklung zu geben oder wegzuwerfen.
Hallo zusammen,
hoffe ich bin hier richtig, ich habe das gleiche Problem, seit der Firmware 2016-1.x.x habe ich gleiche Problematik. Vorher liefen die beiden CPE´s problemlos, auch die Signalpegel-anzeige an der Seite war aktiv (4 LED´s). Es kann mal nur eine Stunde dauern, oder auch mal 9 Tage - ohne neustart. (Die LED´s sind zwar nicht mehr notwendig wegen der neuen Statusseite, zur groben Ausrichtung aber recht hilfreich.
Auf der Statusseite ist das Signal noch zu sehen, allerdings werden keine Bytes mehr transportiert. Wurde beim wechsel der Firmware evtl. ein neuer Treiber für den WLAN-Chip benutzt?
Zum glück gibt es von der anderen Seite per Kabel die Möglichkeit auf den Router zuzugreifen über eine andere Brücke darauf zuzugreifen um den Router per SSH neu zu starten. Am mesh kann es nicht liegen, sonst wäre dies auch per LAN nicht mehr möglich.
Gibt es bisher nur den Workaround den CPE per Script neu zu starten? Bzw. per Modul.?
@adorfer: Du bist herzlich eingeladen dir einen Account zu erstellen. Allerdings halte ich es für deutlich sinnvoller so technische Probleme hier zu diskutieren. Wir haben niemanden, der da so richtig Plan davon hat.
Ich habe auch das Gefühl, dass die CPEs mit 2015.1.2 besser liefen.
Baust du dann spezielle Images für die CPE oder steckst du das überall mit rein?
Ich stecke das Package überall mit hin
ein, da es nicht schadet.
in seltenen Fällen gibt es auch 841er mit dem Effekt. Die würde ich dann zwar unter „eigentlich defekt“ einordnen. Aber wenn’s hilft, warum nicht.
BTW: Ich müsste etwas ähnliches noch mal für’s Lan bauen.
oder das Script erweitern.
Denn wir haben jetzt auch mehrere 841er gefunden, die sporadisch ihr Lan verlieren.
Ohne dass es erkennbar wäre von wegen „down“ oder „no link“. Selbst die Link-LED an Gegenstelle und dem 841er selbst bleibt an. Es gehen nur schlicht keinerlei Daten mehr durch.
Selbst ifconfig down/up hilft nicht(!) weiter.
Mal schauen, wie ich das Minimalinvasiv hinbekomme.
