Minisererver Gen2 - reboot alle 660 min (11h) - seit Monaten

[buki]

Hallo Forum

Vielleicht gehört das nach Software, vielleicht nach Hardware. Ich versuche das mal so emotionslos wie möglich zu beschreiben.

Mein Gen 2 rebootet seit - gute Frage - eigentlich dem 1. Tag vor etwa 80 Tagen alle 11h.

Was ich bisher ausgeschlossen habe:
- Netzteil
- SD Karte (die ist neu und auch schon zwei andere versucht)
- Loxlink abstecken
- Programmseiten temporär entfernen - bis auf ein paar sehr zentrale Seiten waren alle schon weg, vielleicht ist es eine Kobination?
- Netzwerk ausstecken, NIC unbenutzt (dann rebootet er erst, wenn das Netz wieder eingesetckt wird, innerhalb von 10 min)
- Netzwerk eingesteckt, alleine an einem unmanaged switch (NIC am MS aktiv) - reboot exakt bei minute 660 +5 watchdog
- SSL mit einem public wildcard zertifikat, SLL mit Loxone Self-singed zertifikat, ohne SSL
- Gateway-Client (Miniserver V1) entfernt
- alle HTTP/UDP/ In und Out temporär gelöscht
- Alle Türbausteine entfernt
- log.loxone.com täglich zweimal mit crashdump beliefern
- Versions update von 10.3.11.27 --> 11.0 --> 11.0.5.5 (staun: seit gestern gibt es eine neue 2te version 11.0.5.5, Anfänger oder Vertuschung?!) --> Das einzige was Loxone bisher beigetragen hat: "Machen sie den Update, die Dev haben gesagt damit sei das Problem behoben)
- Mein Haus ging seit mitte März Conronabeding kein einzges mal in den Abwesenheitsmodus - WAF ahoi.
- Etwas positives --> ich habe seit längerem alle Remanenz Issues mit Workaround überbrückt
- keine externen Zugriffe - resp nur via VPN
- def.log unauffällig.

Loxone ist seit zwei Monaten nicht in der Lage mir zu helfen oder sich der Sache mit der nötigen Aufwerksamkeit zu widmen. Ich liefere die angefragten loxmon Dateien jeweils innert 24h.... es waren schon ein paar Lieferungen. crash file und Miniserver2 file könnte ich ggf. per PN zustellen, wenn jemand möchte.

Die Frage:
Hat jemand da draussen irgendeine eine gute Idee, was man noch versuchen könnte? Woran das liegen könnte.

Loxone hat meine Konfiguration seit zwei Monaten. Ich habe inzwischen verschiedenste KonsistenzChecks gegen die XML Datei gemacht. Immer wieder seltsame Sachen entdeckt, Bausteine gelöscht und in der Config wieder hinzugefügt. Remanez files gelöscht. Erneut die Konfig von damals vom MS Gen1 konvertiert und aufgspielt. Die Konfiguration lief übrigens am MS Gen 1 seit 2 Jahren, jedoch mit viel Memorylast und 80% CPU, aber ohne reboots. Ich habe den Gen 2 gekauft weil ich keine unkontrollierten Reboot wollte :/ ... so spielt das Leben.

Da ich eigentlich - meines erachtens - bereits alles ausgeschlossen habe - wäre der nächste Schritt wohl, meine config während elf Stunden auf einem anderen MiniserverV2 laufen zu lassen. Selber möchte ich jedoch keinen zweiten (dritten) kaufen, den ich dann mit Verlust wieder loswerden muss .. oder sogar noch kostenpflichtig bei Loxone bestelle und ggf. zurück senden muss. Ist da vielleicht irgendwo ein (Nordwest-/Zentral-) Schweizer, der für 24h einen Gen 2 entbehren kann und will?

Es ist übrigens der Listen Prozess der auf 98% CPU hoch schiesst. Das Bild ist immer das selbe (ca 3.5 minuten auf 98%, dann rechteckige Last, dann reboot) .. siehe Bild.

Danke für's lesen und ggf Ideen Posten.
buki

[Christian Fenzl]

Bei „Netzwerk alleine“, heißt, MS an Switch und am Switch ist sonst garnichts (kein Inet, kein Wifi, keine anderen Geräte)?
Was meinst du mit +5 Watchdog?

Machst du irgendwas mit PicoC, oder gibt es noch VI/VOs zu Netzwerkgeräten (auch wenn die nicht erreichbar sind), oder aber localhost?

Hast du Sachen wie LoxBerry, NodeRed, ioBroker, FHEM, ESP’s, Loxone Musicserver, Türstation oder sonst irgendeine Software am Laufen, die mit dem MS kommunizieren will?

Die 660 sind wohl ein Indikator, dass der MS sich selbst wegschießt (sonst wäre das unregelmäßig), entweder weil er dann im LAN erreichbar ist, oder weil er dann per NTP die Zeit hat und irgendwas alle 11 Stunden startet, was schief geht.

[buki]

Netz: Genau. kein Inet, kein WiFi, nix anderes, statische IP. Nur die beiden in ihrer Zweisamkeit.

+ 5 watchdog: die Probleme beginnen immer nach 660 min, nach zusätzlichen 5 minuten schiesst er sich (der watchdog) selber weg

kein PicoC, kein localhost, auch nicht auf eigene IP
aber ja: es gibt VI/VO mit konfigurierten Adressen ins LAN oder INet. Ich werde das alles nochmals entfernen, inkl. Türbaustein (cam) - vielleicht hatte ich beim letzten Mal etwas vergessen.

ja, Loxberry, NodeRed, Ms4Lox, code.m, modbus TCP (dimplex) ... aber das hatte ich eingetlich alles schonmal einzeln offline und einzeln aus der Config entfernt, und alle zusammen bei ausstecken, aber die VI/VO hierzu waren zu dieser Zeit konfiguriert. hmm.

ich sehe das auch so, es kommt nicht vom LAN und man müsste davon ausgehen können, dass Loxone weiss, was sie alle 660 minuten machen. Tja.

NTP ... ein leidiges Thema. der MS hat einen LAN internen NTP server konfiguriert (doch, der funktioniert ), trotzdem will er immer zu ntp.pool.org. Ist aber ein anderes Thema.

Den internen DNS Eintrag für weather.loxone.com habe ich auch entfernt.

Ich hatte auch schon Portspiegelung aktiv (normalerweise hängt der MS an einem Managed-Swtich), weil Loxone Support meinte es werden zuviele "TCP geöffnet und nicht geschlossen" Keine übertriebene Unicast last, kein Broadcast Sturm, kein auffälliges Multicast zum Problemzeitpunkt festgestellt. Aber das war spät abends.

Der nächste reboot wird heute abend um 20:10 sein. Ein denkbar ungünstiger Zeitpunkt um den nächsten Test zu machen (= alle Netz-Aktiven bausteine löschen plus Netzkabel raus). Das hält der WAF um diese Zeit nicht lange aus.

[Christian Fenzl]

Ich gehe davon aus, dass du die Tests eh mit einer Kopie der Config machst, also immer zum Original zurück kannst.

Den Test mit Port Mirroring würde ich nochmal wiederholen. 10 Minuten vorher anfangen, und genau protokollieren, wann der Listen-Thread losgeht.
Dann hast du das OK- und NOK-Verhalten, und kannst Paketanzahl pro Port, Protokoll usw. vergleichen.

lg, Christian

PS: Ich hab damals den Portscan-Bug im Miniserver gefunden (~v6 oder V7). Ich hab nur 5 Sekunden gebraucht, um den MS K.O. zu kriegen 😂

[svethi]

Was heißt denn den internen DNS Eintrag für weather.loxone.com hast Du entfernt?? Du schreibst, dass der MiniServer läuft wenn er kein Netzwerk hat, dann ist ja auch klar, dass Du da in Deinem Netzwerk, bzw. in Deiner Konfiguration des Netzwerkes bezüglich irgendwelchen Murks drin hast, auf den der MiniServer allergisch reagiert. Wenn Du z.B. in allen VO/VI einen Fehler drin hast, dann ist es auch logisch, dass das Deaktivieren des einzelner nichts bringt. Der entscheidende Hinweis und eine Erklärung ist doch, dass da zu viele TCP Verbindungen geöffnet werden, die nicht wieder geschlossen werden. Das würde erklären, dass es keinen Neustart gibt, wenn der MS kein Netz hat. Dann öffnet der MS gar keine Verbindungen erst. Hast Du Netzwerk aber nur abgeschottet, dann werden jede Menge Verbindungen geöffnet und keine einzige wieder geschlossen weil keine Antwort kommt und das legt den MS schon nach 10Min flach. Am richtigen Netz dauert es dann länger, weil durch Antworten dann doch immer mal wieder Verbindungen geschlossen werden. Arbeite mal diese Hinweise richtig ab.

[doc-brown]

blöde frage - wenn du 5 mins VOR den 660 minuten von hand neu startest - dann passiert kein zweiter neustart?

[buki]

danke für deine konstruktive frage. ich kann den miniserver x mal kontrolliert neu starten, die 660 min nach dem letzten crash bleiben bei exakt 660. er bootet dann trotzdem. die 660 minuten beginnen nur von vorne wenn der ms vom strom getrennt wird, oder ein firwareupgrade lief oder eben ein "crash" war.

[BSiege]

Ich würde mal nach einem verunglückten Zählerüberlauf suchen 16Bit uint = 65,535 das kommt 660(.00) verdammt nahe. Zugegeben mit Hundertstelminuten zu rechnen ist etwas Abenteuerlich, aber bei Lox... ich weiss nicht..

[buki]

Zähler sind noch nicht vom Tisch.

[TGeissler]

Wäre es dir möglich den Gen2 nochmal aus der Config für dein Haus raus zu nehmen?
Dann wäre die Option mal bei 0 zu starten und den mal so ohne einer großartigen Config stehen zu lassen. Ob da nach den 660min wieder ein reboot kommt. Wenn nicht dann liegts an der Config (also um die Hardware mal auszuschließen).

[buki]

Danke Dir. Deinen Vorschlag habe ich bisher so noch nicht versucht, aber ich bin auf einem ähnlichen Weg.
Ich habe nun schon länger wieder den Gen 1 in Betrieb. Dieser läuft mit der vorher auf Gen 2 aktiven Konfig bestens, wie er das vorher auch schon zwei Jahre tat.
Seit ich den Gen 2 auf dem Bürotisch liegen habe, lösche ich am Gen 2 Programmseiten. Leider dauert das ewig, immer 11h auf ein Ergebniss zu warten. Momentan bin ich noch bei zwei von etwa 80 Seiten, eine davon müsste es dann sein. Ich vermute es wird je nach Glück oder Pech noch etwas dauern, bis ich genauer weiss, welcher Baustein(e) oder Statistik oder was auch immer es dann wirklich war.
Ich werde das Ergebnis hier im Forum sicher mitteilen, falls es ein eindeutigens geben wird.

[buki]

Problem gefunden. Fixen muss es wohl Loxone, wenn sie dies als wichtig genug erachten. Es wird ja wohl nicht jeder so faul sein und einfach alle 45 sekunden ein WOL rausballern solange das Haus auf anwesend steht

Das Problem liegt, wie bereits erwähnt, beim wol:// des Gen 2 Miniservers. Nach etwa 880 wol commands schiesst sich der Gen 2 weg. Meiner zumindest. Die 660 Minuten haben keine Relevanz.
Der Gen 1 kann damit umgehen. Ich nehme an der Gen 2 schliesst die socket nach wake on lan Paketen tatsächlich nicht.

Mit folgenden zwei Bausteinen - und sonst nichts - ist nach 10 minuten schon schluss.

Danke für Eure Inputs.

[buki]

"faulheit" habe ich geschrieben, ich dachte damit sei das erledigt.

Kurz: Es gab keine technische Notwendigkeit.
Länger: Ich habe irgendwann aufgrund fehlender Resourcen am MS Gen 1 den schlechten Loxone Ping-Baustein und den "und" Baustein "geopfert" (da hatte ich noch keinen node-red am laufen). Dabei habe mich erdreistet, meinem Netz und dem Miniserver ein WOL packet alle 45 sek zu zu muten. Meinem Netz war es egal, Loxone dann wohl nicht
Mit Sarkasmus: Ich wollte Loxone helfen sich zu verbessern ... unterschätze nie die seltsamen Ideen deiner Kunden

[BSiege]

svethi Auch wenn wir jetzt Haare spalten: Stateless: Solange das Protokoll nicht in einer Form auf eine Antwort wartet, kann da eigentlich gar nichts hängen bleiben. Shoot and forget. WOL wird nicht einmal von gängigen Firewalls offen gehalten. Die Praxis sieht hier anders aus. Aber ich glaube wir können uns wohl darauf einigen, dass die verwendete Library vom Azubi am Montagmorgen nach einem Partywochenende erstellt hat, während der Lehrmeister im Urlaub war. ;-)

[svethi]

Die Lehrmeister sind aber oft im Homeoffice

[svethi]

Na da sind wir mal gespannt was Loxone dazu sagt.

[Christian Fenzl]

Sehr cool! Das ist ja mal ein schönes Reproduktionsszenario 🙂

[svethi]

Kann das mal jemand noch mit einer TCP Verbindung prüfen? Ich kann mir nämlich nicht vorstellen, dass das nur WOL betrifft. Wohl eher den kompletten Ausgang.

[buki]

da ich den MS sowieso hier auf dem tisch liegen habe, habe ich das noch kurz angetestet bevor ich den wieder produtiv einbaue:
- tcp ins leere (ohne endpoint) hat nahezu eine Stunde funktioniert. Das habe ich dann abgebrochen.
- tcp mit listener auf der anderen Seite hat auch länger funktioniert. Da werden vom MS die ports bis etwa 60'000 verwendet, dann beginnts wieder bei 2^15, scheint stabil.

[svethi]

Okay, dann scheint es wohl doch nur WOL zu betreffen.

[buki]

Der Vollständigkeit halber. Wurde in 11.1.9.3 gefixed: BG-I6216 Fixed closing socket after WOL command on Miniserver Gen 2