Das ist entweder
Ansonsten: Ist alles in obigem Thread erläutert.
bei 30m lohnt es durchaus qualitativ hochweritges kabel zu nehmen, insbesondere die Art der Ader und deren Durchmesser sind da wesentlich , damit kann man den Widerstand bei 30m nach unten drücken und es bleibt ausreichend restspannung am Ende… (wenn denn das das problem ist)
Das hatten wir in
schon diskutiert.
aber das kabel bleibt schneefrei 
Dank erst einmal für die schnellen Antworten. Die von euch angegebenen
Links werde ich nachlesen. Bzgl. der Kabel fehlt mir ein wenig die Kenntnis
wie ich hochwertiges von weniger hochwertigem Patchkabel unterscheiden
kann. Das mit den Schirmungen und Einstrahlfestigkeit (Cat.5 - xxxx) kenne
ich. Hier wird es aber wohl auf den Innenwiderstand, den Litzenquerschnitt
und den Werkstoff/ der Legierung an.
@windoof: „Am besten das POE vor der CPE runterhohlen vom Kabel und
wieder neu draufpacken mit step up converter…“ Das habe ich nicht ganz
verstanden. Was verstehst du unter einem „step up converter“. Meinst du
am POE via Elektronik die Spannung wieder erhöhen??? Die Frage wird
dann sein, ob man den benötigen Strom aus der Leitung bekommt, oder?
LG,
Andreas
Mir ist der „Absturz“ nicht klar umrissen. Handelt es sich hier nun um
- cyclic freeze
- cyclic reboot
Die Fehlerbeschreibung des Eingangspostings ist für mich nicht plausibel.
Denn wenn cyclic reboot wäre, dann gabe es maximal 1-5 Minuten „Tot-Zeit“ wenn einer der Watchdogs anschlägt.
Passt also nicht.
Wenn es aber der Wifi-Bug wäre, dann würden die Geräte nicht (ohne spezielle Tools, die nicht Standard im Gluon sind, siehe obiger Thread) von allein wiederhochkommen, vor allem nicht rebooten, sondern allenfalls ohne „ohne Reset“ wieder zu spielen beginnen.
Da es sich aber nach Deinem Bekunden um einen „Absturz“ handelt, tippe ich auf einen echten Hardwaredefekt, denn anders ist es kaum zu erklären, nach derzeitigem Stand.
es kann absolut sein, dass immer wieder nur das WiFi vom MM_DL weg war. Da der in ca, 30 hoch oben in einem Baum montiert ist, kommen wir da nicht wirklich dran. Ich habe halt nur festgestellt, dass der MM_DL nach einen PowerCircle wieder ordnungsgemäß hoch fährt. Vorher hatte ich schon den PoE Adapter getauscht, ibss via ssh Zugriff deaktiviert (ja, der ist neben dem 802.11 bei der FW noch drin und hat eine zweiten Mesh-Link betrieben) und den MM_DL_02 (ex. 841) hatte ich durch einen 1043 ersetzt. (der wird jetzt wohl auch drin bleiben).
Da der andere CPE exakt vie gleiche FW hat und noch nie abgesürzt/abgeschmiert ist, vermute ich, dass es vielleicht tatsächlich an der Spannungsversorgung liegt.
Auf dem Node haben wir inzwischen einen Cronjob hinterlegt, der alle paar Minuten schaut, ob er via IPv6 den DL erreicht, wo er seine Daten her bezieht, Ist dem nicht so, soll er rebooten. Das ist jetzt aber ganz neu und wir müssen schauen, ob das so läuft. Danach sollten wir auch wissen, ob „nur“ das WiFi sich aufhängt oder der Node komplett weg ist. Dann würde ja auch kein Cronjob mehr laufen können…
Du kaufst ein POE Splitter Passiv set fuer 3 Euro dann eine Step Up auf auf 18V direkt vor die CPE bei zu wenig Spannung bedankt die sich mit haengen oder Reboots. 12W bekommste normal im Kabel auf 30m nicht verbraten.
Und ein Speepup kann aus 12V 1A immer noch schoene 18V 0,6A machen was der CPE dann reicht. 1A POE Netzteil setze ich mal vorraus.
Alles klar, dann hatte ich das richtig verstanden. Die StepUp-Elektronik packt ihr dann sicherlich in ein kleines Zusatzgehäuse, oder? POE Splitter Passiv set fuer 3 Euro habe ich hier noch ein paar herum liegen…
Hat sich bewährt, siehe Eingangspost in
Dort ist auch er PCB-Typ verlinkt.
das script checkt nicht auf ping6 zum gateway, sondern auf die letzten 3 bytes der Mac Adresse mit batctl gwl -
im cron jede minute ausgeführt und mit Fehlerzähler. Bei >10 gibts einen reboot (falls das Kernel zu dem Zeitpunkt noch läuft). Warte die letzten 8 Stunden jetzt schon auf 'nen crash 
https://map.freifunk-rhein-sieg.de/lohmar/#!v:m;n:ec086bc63764
Hab’ das im Wiki von kbu gefunden und lediglich angepasst.
#!/bin/ash
FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10
# check mesh connections with Meigermuehle and reboot if not present
count=`batctl gwl | grep b0:49:5e | wc -l`
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
if [ $count -gt 0 ]; then
if [ $failcount -gt 0 ]; then
echo 0 > $FAILCOUNTFILE
exit
fi
else
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE
# do not activate logread command - it will fill up flash storage and logfile content is unusable
# logread >/etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"`
# debug
# echo "maximale Fehler erreicht - rebooting ..."
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
# debug
#echo "Bisher $failcount Fehler\n"
fi
else
echo 0 > $FAILCOUNTFILE
# debug
#echo "Bisher keine Fehler\n"
fiaktuell läuft der MM_DL seit heute Morgen 08:54 Uhr ohne Unterbrechung durch.
Der hat sich vermutlich so über das Script gefreut, dass wir das jetzt garnicht
mehr brauchen…
An der Spannungsversorgung werde ich trotzdem definitiv was verbessern und
da sind eure Tipps super. Das Kabel zu ersetzen, könnte aber auch eine flotte
und nachhaltige Lösung sein. Wie man auf einfache Art und Weise mit einer
Step-Up-Elektronik einen CPE anfahren könnte, müsste ich mir erst noch
überlegen. Eine Klinkenbuchse für die Spannungsversorgung gibt es da ja
nicht. Da müsste ich sicherlich erst einmal prüfen, auf welchen Adern die
passiven PoE-Einschleifung (3,-€ Adapter) die Spannung transportiert…
Siehe auch im Paralleltrhead: TP-Link CPE210 unter Gluon instabil - #35 von adorfer
P.S. Magst Du das bitte auch in den „CPE210-Instabil-Thread“ kopieren, denn bei einem Absturz (dem szenario hier?) wird es kaum helfen.
Da bisher immer nur ein Powercycle der Installation gemacht wurde, nehme ich einen Absturz noch nicht als gegeben hin. Wenn der MM_DL seinen Link zur Gegenseite verliert, ist die gesamte Gegenseite halt weg. Deshalb warte ich auf den nächsten Ausfall. Wenn es nur wifi mesh ist (wie letztens bei einer Unterkunft hier in Lohmar), dann sollte ein automatisierter reboot das wieder glattziehen.
Hier sind parallel noch 6 cpe210 im Lohmarer Netz unterwegs, die keine Ausfälle in dieser Häufung zeigen.
Ein „Absturz“ ist für mich ein Freeze, evtl. mit Reboot aus dem Watchdog.
Dagegen hilft Dein Script nicht.
Das hilft „nur“ gegen den ath9k-Wifibug und andere mögliche Gluon/OpenWRT-Instablitäten.
daccor. bislang habe ich mit der gluon 1.5 nur meshing-fehler erlebt - link war weg, gegenstelle hatte aber noch vpn uplink. nach reboot des uplink routers war dann alles wieder ok.
Beim Setup Meigermühle ist es umgekehrt. Uplink router einwandfrei, aber die Gegenstelle der Richtfunkstrecke schmiert netzmässig weg.
Das script hatte ich eigentlich für die Installation Ev_Kirche Lohmar eingesetzt, da dort der 841n im Turm zwischenzeitlich meinte, nicht nach unten meshen zu müssen und das Hochklettern in den Turm für ein powercycle lästig war.
Bei beiden Setups warte ich auf die nächste Störung, ob’s mit dem script dann gefixt ist.
Weiterhin einiges an Ausfällen, aber die mesh-Überprüfung per script und reboots zeigen, dass kein Kernel-Crash erfolgt, sondern lediglich ein wifi bug bei mesh0
geht der Link verloren, zeigt iw dev mesh0 station dump bei der Verbindung ein OPEN_SND und HOLDING - ESTABL Status kommt nicht zu Stande. Nach dem einseitigen Reboot läufts dann wieder bis zum nächsten Wegfall der Mesh-Verbindung.
1 „Gefällt mir“