Hallo zusammen! Wir betreiben 2 CPE210 um eine größere Strecke zu überbrücken. Leider steigen beiden Geräte in unregelmäßigen abständen soweit aus, dass diese im Meshviewer als offline gekennzeichnet werden. Es hilft dann nur ein Neustart, den wir über einen cronjob alle paar Stunden ausführen. Hardwareprobleme würde ich ausschließen, da das Problem bei 2 Geräten auftritt. Gibt es irgendeine Möglichkeit, da etwas zu tracen oder ist solch ein Verhalten bekannt? Das Problem tritt mit den Branches „Experimental“ und „Stable“ genau gleich auf.
Und mit älteren Gluon-Versionen läuft das?
Ich tippe ehrlich gesagt eher auf ein Stromversorungsproblem, denn die Kisten sind SEHR picky diesbezüglich.
Was bedeutet das? Sind die Netzteile schlecht oder reagieren die Geräte sdo auf Stromschwankungen? Was kann man dagegen tun? Eine USV vorschalten ist vielleicht ein wenig übertrieben…
Ältere Gluon-Versionen haben wir nicht getestet.
Ihr habt ältere Gluons nicht getestet?
Wie kommt ihr dann auf das schmale Brett dieses Betreffs?
Meine CPEs sind übrigens POE Geräte.
Werden die denn nur im Meshviewer nicht mehr richtig angezeigt, oder sind die dann auch nicht mehr nutzbar / erreichbar?
adorfer: Ähm, älter als 2015.1.2 ? Sorry, wenn das missverständlich ist. Wir sind erst mit dieser Version eingestiegen,
CHRIS: Sorry, auch missverständlich. Die Geräte sind dann im Netzwerk nicht mehr erreichbar.
Welche stable und experimental Firmware habt ihr denn da überhaupt drauf gespielt?
Mit welcher Strippe habt ihr die Geräte zwischen Netzteil und Router verbunden?
Der adorfer hat schon ziemlich viel Ahnung von den Dingern…wenn er sagt dass die sehr empfindlich sind was die Spannungsversorgung anbelangt, dann könnte es zum Beispiel auch ein Problem der Zuleitung zwischen PoE Netzteil und Router sein…
Wir checken mal die Kabel.
Also konkret: Die Dinger brauchen stabile, belastbare 16V am primären LAN-Port. Auf CCA oder minderquerschnittig Kupferkabel reagieren die bisweilen schon nach 10m allergisch mit ständigen spontanen Reboots.
Auf ein „Offline im Meshviewer“ würde ich nichts geben.
„Nicht anpingbar per im Lan“ oder „nicht per batctl p erreichbar“: Das würde mir in der Tat sorgen machen. Denn normalerweise, wenn das Kabel nicht völlig Knülle ist, dann holt der Watchdog die wieder ins Leben zurück.
Wir haben nun mittlerweile weitere CPE210 im Einsatz. Die Verkabelung ist komplett ausgetauscht worden bei den ersten instabilen Geräten und bei den neuen Geräten sind es nur kurze Kabelverbindungen. Das Verhalten ist überall das gleiche - nach nicht näher bestimmbaren Zeiträumen (mehrmals am Tag) steigen die Geräte aus und sind im Netzwerk nicht mehr erreichbar. Nicht mal ein Ping ist möglich. Wir haben Cronjobs alle paar Stunden eingerichtet, damit die Geräte rebooten. Danach läuft wieder alles für ein paar Stunden. Aber das kann nicht die Lösung sein. Habt ihr irgendeine Möglichkeit, da etwas zu debuggen?
Nein, wir haben dazu keine Möglichkeit, da wir nicht einmal wissen, was für eine Firmware dort läuft oder zumindest welche Domain das ist.
Aber vielleicht bekommen wir unsere Glaskugeln bald aus der Inspektion zurück.
Mich würden Details zu diesem besagten „Ausstieg“ und der „Nichterreichbarkeit“ interessieren.
Gluon v2015.1.2 - was meinst du mit „Domain“? Ich liefere gerne alle nötigen Daten. Vielleicht hilft das hier ja schon: http://map.freifunk-lippe.de/#!v:m;n:c4e984b0a5a8
Wenn der Knoten als „offline“ beschrieben wird: Logge Dich auf einem ANDEREN Knoten der Domain ein, und versuche ein
batctl p c4:e9:84:b0:a5:a8
Ob Du dann noch Antwort bekommst.
Und wenn ja, dann logge Dich per SSH auf dem Knoten ein (von dem anderen Noten aus „weiterhüpfen“)
ssh root@fe42:ffee:ff42:0:c6e9:84ff:feb0:a5a8
Dann schaust Du dort mal, was
batctl gwl
ausgibt
und ob Du mit
batctl p bis zur Mac des gewählten aktuellen Gateways kommst.
Hi,
wir haben mit dem (inzwischen leider wieder) einzigen Uplink eines Flüchtlingsheims ähnliche Beobachtungen machen müssen. Der CPE210 mit Gluon 1.2-2 mesht (überwiegend) mit zwei weiteren CPE210 in ca. 50m Entfernung und die mesh0-Verbindungen sind alle paar Tage mal plötzlich weg, wobei die mesh0-Verbindungen von den Knoten zu sich selbst noch mit „batctl o“ ausgegeben werden.
Da der Uplinkknoten dann noch am VPN hängt, konnte ich per ssh darauf und das Problem jeweils kurz analysieren, duchstarten half dann.
Hier ist ein Script dokumentiert, welches nach 10 Minuten den betroffenen CPE210 durchstartet, sofern in jeder dieser Minuten der Fehler bestehen bleibt:
https://kbu.freifunk.net/wiki/index.php?title=Pimp_my_Node#Automatischer_Neustart_bei_l.C3.A4ngerem_Mesh-Verlust.2C_quick_hack_.28and_improved_hack.29_zur_Analyse
ich habe mehrere CPE210er hier im Dauerbetrieb an „Remote locations“ (auf Dächern) und beobachte soetwas nicht.
Bitte bringt verwertbare Debugging-Informationen, dass man der Sache auf den Grund gehen kann.
Da muss ich @adorfer vollkommen Recht geben, ohne die passenden Informationen ist das hier nur
Blinde-Kuh spielen. Über die bereits angeforderten Infos hinaus würde ich noch „logread -f“ laufen lassen
während du per SSH eingeloggt bist, vieleicht kommen da auch noch Infos bei raus.
Unsere CPE210/510er laufen mit Gluon 2015.1.2 seid über 2 Monaten ohne Reboot, es liegt also
an eurer Domain oder sonstigen Besonderheiten.
http://map.en.freifunk.ruhr/sprockhoevel/#!v:m;n:14cc203831e4
LG
Der Effekt tritt sehr selten auf, weshalb man da schlecht vor der Konsole sitzen bleiben kann. Das verlinkte Script hilft collimas ggf. erstmal, die Ausfallzeiten gering zu halten.
Vor dem Reboot steht nun
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"`
so dass man später nachschauen kann und hoffentich Hinweise findet. Zwei weitere mesh-only CPE210 und einer mit Uplink laufen tadellos.
@Nunatak: Herzlichen Dank! Das Script habe ich eingebaut, nun schauen wir mal, was so in den Logs dokumentiert wird.
@adorfer: Vielleicht helfen die mit dem Script erlangten Debug-Infos ja weiter. Ich werde diese dann heier posten.
in freiburg hatten wir gleiches setting, mesh only, keine probleme.
mittlerweile haben die 2 cpe uplink, auch da keine probleme