Wiregate down - was war da denn los

[swiss]

Also doch. Da bin ich beruhigt. Ich würde nur ungern auf VPN verzichten.

Was ist da allen noch dran...

- Philips Fernseher
- Sony Blueray Player
- Dreambox 8000 HD
- Vivoteck IP Kamera
- Zyxel WLAN AP
- Synology NAS
- Motorola Router vom ISP
- zweites WG (ohne probleme )

Über WLAN ist noch mein Laptop und mein HTC Handy verbunden.

Wartungs VPN auf WG 314 ist seit dem letztenmal immer nochoffen Vieleicht könnte man mal einen tcpdump machen. Aber da bin ich nicht so Fit. Wenn du Lust und Zeit hast, kannst du jederzeit mal reinschauen. Vieleicht steht auch etwas in den Logs.

[makki]

@Patrik: neuer Kernel ist ja schon drauf, uptime 15d.. mal sehen

tcpdump ist eher müssig, weil das remote zu finden grenzt an fortgeschrittene Astrologie (also raten);
dafür bräuchte man ein zweites System vor Ort, einen Spiegelport am Switch und beim auftreten alle 2W verdammt viel Platz auf ner schnellen Platte/SSD (+absolut exakte Zeiten/Monitoring)

Makki

[swiss]

Hallo makki

Ja Uptime 15 Tage. Aber...

Nicht immer geht das WG komplet in die Knie. In letzter Zeit häufen sich Probleme mit dem eibd und vor allem wiregated.pl

Da ist die Uptime nicht so rosig. Normalerweise sollten die doch genau gleich lange UP sein wie das System selbst.

Zwischendurch kommt es sogar vor, dass sich wiregated.pl verabschidet und sich nicht mehr selber startet. Dann muss ich von hand über das Webin->Status->aktivieren den Dienst wieder in Gang setzen.

[makki]

wiregated.pl ist "normal", das sind Speicherlecks das nichtmal der liebe Gott erklären kann (Die perlmonks vielleicht )
-> Da passt der monit auf..

Der eibd ist noch nie in meinem Leben abgekachelt, das ist eine (was falsch verstanden..) dumme monit-config, ein restart, sollte man bei richtiger config niemals merken.

Makki

[swiss]

Ok. Ist hald nur etwas müssig, wenn die Plugins immer mal wieder nicht funktionieren. Interessanterweise habe ich auf dem zweiten WG scheinbar keine Specherlecks oder ich bemerke die einfach nicht.

EDIT: Habe gerade nachgesehen. Wiregated auf dem neuen WG hat 1 Tag uptime der rest immer noch 100%. Seltsam, dass beim Problem WG immer mal wieder der eibd neugestartet wird. Vieleicht ist da tatsächlich der Monit etwas zu übersensiebel.

[makki]

Vieleicht ist da tatsächlich der Monit etwas zu übersensiebel.

Nein, den hab ich beim letzten Update schlicht falsch eingestellt (weils falsch in der Doku steht);
Doku: loadavg des prozesses wird überwacht
Reality: loadavg des gesamten Systems zieht.
Resultat: der eibd wird restartet, wenn irgendwas die loadavg hochfährt

Makki

[Jockel]

@Jockel: ich glaube du hast den neuen Kernel noch nicht, (deswegen gibts im nächsten Update, PL34, ein rudimentäres Logging)
-> WG-Nummer, Wartungs-VPN an, rebooten darfste/musste selber.. Das wär einen Versuch Wert auch wenn das Problem (dummerweise) nur alle paar Monate und damit sehr schwer greifbar auftritt..

Da bin ich jetzt über die Feiertage etwas drüber weggekommen. Das VPN ist geöffnet, Wiregate 198

[Jockel]

Heute morgen war es wieder so weit, der neue Kernel scheint das Problem also wohl nicht zu beheben.

Symptome wie beim letzten mal:
- Keine SSH- oder HTTP-Verbindung (auch nicht um per ssh nur einen Befehl auszuführen)
- openHAB beschwert sich über eine weggebrochene Verbindung zum eibd
- Sporadisch scheint die Verbindung aber zu funktionieren, mit sehr langer Wartezeit (> 10s) konnte ich über die Visu manchmal Licht schalten
- Die RRD-Graphen sind vollständig, die SW muss also noch aktiv gewesen sein

Auffällig ist noch, dass der ganze Syslog mit "07:51:25 wiregate198 avahi-daemon[2537]: Invalid query packet" zugemüllt ist. Brauche ich den avahi für irgend etwas außer der Namensauflösung? Dann würde ich den mal deaktivieren, mein DNS kennt das Wiregate eh.

Auch wenn es die Fehlersuche natürlich nicht erleichtert: Spricht etwas gegen einen täglich reboot, damit zumindest bei längerer Abwesenheit die ganzen Automatismen weiter funktionieren, dann würde ich da mal einen Cron-Job anlegen. Vielleicht aknn das Wiregate den Zustand aber auch selbst erkenne und dann neu starten?

[makki]

Nun, inzwischen ist relativ sicher das sich "nur" das Netz abhängt - natürlich kann man das mit reboot, Watchdog & Co abfangen aber viel interessanter fände ich die wirkliche Ursache, denn diese Tritt bei den meisten und im Testbed eben nicht auf - bei betroffenen aber auch nach HW-Tausch usw. zuverlässig auf!
Kein Vorwurf bitte, nur ein Denkanstoss: wo liegt die Gemeinsamkeit??

Auch kein Vorwurf oder negativ bitte, aber das untermischen von OpenHAB o.ä. (und meistens ist sowas oder anderes im "Topf") macht die Suche auch nicht einfacher.. (Wenigstens ehrlich, wichtig!)
Weil das bei etwas völlig ungetestetem mal unerwartet der OOM-Killer kommt und den falschen Abknallt ist halt auch im Rahmen der Möglichkeiten, ein Anwender kann das nur schwer unterscheiden weil das eine vermeintlich noch geht usw.usf..
Gebt mir eine Idee!
Der Kernel war eine Massnahme, weil ich nach langer Suche eine Möglichkeit gefunden habe das extrem mutwillig mit 70 MBit grobem schrott (allerdings auch nicht wirklich 100% reproduzierbar) herbeizuführen. Das das nicht die ganze Wahrheit ist, war vorher klar..

Makki

[Jockel]

uch kein Vorwurf oder negativ bitte, aber das untermischen von OpenHAB o.ä. (und meistens ist sowas oder anderes im "Topf") macht die Suche auch nicht einfacher.. (Wenigstens ehrlich, wichtig!)

Ich bglaube, dass hast Du falsch verstanden. openHAB läuft bei mir auf einem weiteren Rechner, nicht auf dem Wiregate. Es kommuniziert lediglich über den auf dem Wiregate laufenden eibd mit dem Bus. Ich hab es erwähnt, weil es gezeigt hat das eben doch manchmal Pakete zum Wiregate durchdringen, sonst hätte die Visu das Licht nicht schalten können. Allerdings eben mit sehr großer Latenz.

Nun, inzwischen ist relativ sicher das sich "nur" das Netz abhängt - natürlich kann man das mit reboot, Watchdog & Co abfangen aber viel interessanter fände ich die wirkliche Ursache

Das sehe ich grundsätzlich genau so. Allerdings wäre ein Workarround zumindest für längere Abwesenheit nicht schlecht, damit z.B. im Urlaub die ganzen Automatismen weiter zuverlässig funktionieren.

Gibt es Erkenntnisse, ob das Wiregate weiter nach außen kommunizieren kann? Sonst könnte man ja einen ping Test z.B. auf den Router machen und beim Fehlschlagen einen Neustart initiieren.

Gebt mir eine Idee!

Eine Systematik hab ich auch noch nicht erkennen können, beim letzten Mal ist es z.B. mitten in der Nacht ausgestiegen als im Netz eigentlich nicht viel los war. Was ich mal in den Raum werfe ist, dass ich sehr viel Apple-Hardware habe und dementsprechend bei Bonjour & Co. viel Traffic herrschen dürfte. Deswegen bin ich auch über die avahi Meldungen gestolpert. Wenn der Daemon nicht für andere Sachen gebraucht wird würde ich ihn testweise mal beenden.

[makki]

Es gibt einen Workaround, der ist jedoch wirklich extrem hässlich und extrem Fehlerträchtig!!
-> Wenn das Default-GW weg ist (also die "Fritzbox" oder der Switch stirbt oder..) mündet das evtl. in einer unendlichen reboot-loop!! -> Das also bitte mit absoluter Vorsicht geniessen, bzw. nur wenn man genau weiss, was man damit tut!

Man erstelle /etc/monit/enable/ping

check host gw with address 192.168.178.1
    if failed icmp type echo count 2 with timeout 1 seconds then 
	exec "/sbin/reboot"

-> 192.168.178.1 ist natürlich zu ersetzen durch etwas, das immer erreichbar sein muss!

monit reload

Den *vagen* Verdacht mit Zeroconf/Bonjour teile ich übrigens, allerdings gibt es hunderte "mit" die keine Probleme haben und mindestens zwei (ein Standort mit 4(!) WG's wo eins das Problem hat (HW wurde bereits getauscht) und drei andere mit allen Kernels seit Beginn eine Uptime von 2J
Ohne das dort auch nur den Hauch von Bonjour gäbe - was die These schwer beweisbar macht..

Makki

PS/Edit: mit dem Kernel 3.5.1 tritt das nicht auf, aufgrund des möglichen Fehlerpotentials wird der aber nach wie vor nur manuell auf Wunsch nachinstalliert (neuere WG: Default); bei dem ersten ders selber probiert hat gings in die Hose, spricht Bände..

[Jockel]

192.168.178.1 ist natürlich zu ersetzen durch etwas, das immer erreichbar sein muss!c

Danke, ich werde es heute abend mal einbauen und als Gegenstelle den Switch nehmen an dem das Wiregate hängt, wenn der nicht mehr erreichbar ist läuft eh nichts mehr...

PS/Edit: mit dem Kernel 3.5.1 tritt das nicht auf, aufgrund des möglichen Fehlerpotentials wird der aber nach wie vor nur manuell auf Wunsch nachinstalliert (neuere WG: Default); bei dem ersten ders selber probiert hat gings in die Hose, spricht Bände..

Da muss ich widersprechen, bei mir läuft ja der Kernel 3.5.1!

[Jockel]

So, hab jetzt mal Testweise die Regel für den monit erzeugt, allerdings noch um ein "2 cycles" ergänzt. Das gibt mir etwas mehr Spielraum um ein endloses Rebooten zu unterbrechen.

Zu dem Bonjour ist mir noch gekommen: Bis Du Dir sicher, dass in der erwähnten Installation nicht vorhanden ist? Es wird z.B. auch unter Windows mit dem iTunes mit installiert.

[makki]

.. Bis Du Dir sicher, dass in der erwähnten Installation nicht vorhanden ist?

Doch, schon.. avahi-browse -atr und 12GB tcpdump sagen mir das

Der letzte Post war auch meinerseits etwas aus dem "Kontext gerissen - iSv: was ich schon weiss";
Fakten:
1) mit dem neuen Kernel ist der seltene Spuk (bisher) IMHO vorbei
2) ich glaube nicht wirklich das es ein Problem(*1) ist
3) ich glaube auch nicht wirklich, das es WG-spezifisch ist, es waren in allen Fällen immer fragliche "dritt-faktoren" im Spiel.. HP-Switches oder Fritzboxen stehen da noch vor Avahi/Bonjour in der Fahndungsliste, ... (nur ein Beispiel, ein unharmonischer Switchport auf dem irgendeine Strom-control aktiv wurde - wird mit dem WG-reboot nun auch resetted!.. Nur das es den Hersteller des Switches nicht interessiert.. und das so eine DSL-Box manchmal ganz komische Sachen macht, die in keiner RFC stehen, damit nur das IP-TV des Providers geht: dummerweise mit einer Multicast-loop verbunden, haben wir auch schon gesehen..)

Sachdienliche Hinweise: gerne. Ohne alle Details werden wir da aber vermutlich leider alle nicht schlauer..

Makki

*1) es sind meist/oft/immer mehrere, meine Aufgabe diese zu sortieren, der AW schiebt nach einem Update immer alles auf die letzte Aktion, so kleine Infos wie das dies&das getauscht wurde, werden gerne unterschlagen.. Kein Vorwurf, nur eine Feststellung mit 15J Erfahrung im Support

[Jockel]

mit dem neuen Kernel ist der seltene Spuk (bisher) IMHO vorbei

Bei mir läuft doch der Kernel 3.5.1, scheint also damit leider auch nicht behoben zu sein.

ich glaube auch nicht wirklich, das es WG-spezifisch ist

Irgend eine Komponente auf dem WG scheint schon eine Rolle zu spielen, bei zwei anderen Linux-Rechnern die bei mir bis Anfang Januar durchgelaufen sind ist es nie aufgetreten (jetzt laufen sie in einer VM).

Ansonsten: HP-Switches sind bei mir vorhanden, aber da hingen die beiden anderen Rechner auch dran. Auch das Wiregate lief ja 2 Jahre ohne jedes Problem! FritzBox hab ich auch, aber nur als SIP-Server und WLAN AP, Router ist ein Lancom.