iobroker telefoniert "nach Hause"?

[berti7]

Hallo Miteinander,

ich bin zwar neu hier im Forum aber ein langjähriger Mitleser und Nutzer von iobroker. Vorher bin lange Jahre begeisterter Nutzer von ccu.io gewesen, bis ich dann wg. der Ablösung der CCU1 zu iobroker wechseln musste.
Seit 2019 betreibe ich eine umfangreiche iobroker-Installation. Sämtliche Bereiche in meinem Neubau wird von Homematic mit dem darübergestülpten iobroker verwaltet.

An dieser Stelle muss ich mich auch bei den Entwicklern für die tolle Arbeit bedanken. Absolut sensationell!

Die ständig wachsende Zahl von JS-Scripten sowie der Wunsch nach zusätzlichen Adaptern zwang mich irgendwann von dem zuverlässigen Raspi2 mit js-controller 1.4.2 auf einen aktuellen Raspi 4 mit 8 GB zu migrieren. Bis auf Änderungen an den JS-Scripten hab ich das System in Ruhe gelassen, und es lief ohne Zwischenfälle 2 Jahre durch.

Wegen der Wichtigkeit bevorzuge ich "saubere" Systeme, sämtliche "wichtigen" Host laufen in einem abgeschotteten "Prozess-VLAN" (CCU, iobroker, Wärmepumpensteuerung, Wallbox, Wechselrichter, SolarLog, ISG, vzlogger usw usw.). Sämtlicher Traffic inbound oder outbound aus diesem VLAN wird von einer Firewall kontrolliert.
Ich habe also den neuen Raspi4 komplett neu aufgesetzt, mit aktuellem Buster und der aktuellen "stable" iobroker Installation (js-controller 3.2.16).
Bis auf minimale Änderungen an den .vis-views (wg. den Pfaden zu den Bilder) sowie marginale Änderungen an den JS-Scripten lief auch alles auf Anhieb.

Leider stelle ich fest, dass die aktuelle Installation bei jedem Aufruf der Admin-Oberfläche eine Verbindung zu 79.143.182.215 (m0855.contabo.host) mit tcp80 aufbaue möchte. Ich habe schon alles abgeschaltet was die Oberfläche hergibt (Statistik, den Sentry-Plugin disabled), aber trotzdem will das Ding ständig nach Hause telefonieren. Ich habe verstanden, dass die Reporting Funktionen neu aufgesetzt sind und versucht über common.disableDataReporting:true im host-Objekt das Verhalten zu Ändern.
Das syslog spuckt auch ständig folgende Meldungen aus:

May 14 12:29:08 [xxx] bash[2927]: Send diag info: null
May 14 12:29:10 [xxx] bash[2927]: Cannot send diag info: ETIMEDOUT

Vielleicht mach ich auch einfach was falsch.

Ich verstehe natürlich das berechtigte Interesse an statistischen Daten zur Fehleranalyse, und bin auch bereit diese vom Testsystem bereitzustellen (ich betreibe eine 2. identische Installation für Test und Entwicklungszwecke), aber das Produktivsystem ist bewusst "cloud-free" konzipiert.

Hat jemand eine Idee, wie ich dem Produktivsystem sämtliche Verbindungsversuche Richtung Internet abgewöhnen kann?

Vielen Dank schon mal im Voraus

berti

[Homoran]

@berti7 sagte in iobroker telefoniert "nach Hause"?:

Hat jemand eine Idee, wie ich dem Produktivsystem sämtliche Verbindungsversuche Richtung Internet abgewöhnen kann?

Ja!

Systemeinstellungen - Statistik - Pulldown auf "nichts" stellen

EDIT:
du hattest ja "sämtliche" geschrieben.
Das wird etwas schwieriger. Schließlich sucht dein ioBroker ja auch immer wieder nach Adapterupdates.
den Info-Adapter wirst du wohl auch deinstalliert haben, oder?

[berti7]

... das wäre zu einfach.
diese Einstellung in der webGUI war natürlich das Erste was ich durchgeführt habe...

Weiterhin:
STATE system.host.x.plugins.sentry.enabled auf false
STATE system.adapter.x.plugins.sentry.enabled auf false
iobroker plugin disable sentry

schon mal Danke für die Mühe.

[berti7]

ja, info-Adapter ist deinstalliert, und auch die automatische Suche nach Updates auf "manuell" gestellt ... hat alles nichts geholfen

[berti7]

Kurzer Nachtrag: Die Meldung im syslog kommt immer dann wenn man auf die GUI im Browser neu aufruft, oder wenn man auf "hosts" klickt ... Und dann kann man auch im Firewall-Log sehen, dass ein Verbindungsversuch zu der oben angegebenen Adresse kommt

[apollon77]

Bitte GitHub issue im js-Controller anlegen. Prüfen wir natürlich.

[berti7]

... ihr seid der Hammer: ich sehe im github, dass der Fall schon eingekippt und bearbeitet wurde.

Ich habe die 6 Zeilen in main.js der Version 3.2.16 angepasst (gemaess https://github.com/ioBroker/ioBroker.js-controller/pull/1354/files) und was soll ich sagen: ALLES PRIMA. Getestet, alle Varianten durchprobiert und tcpdump gibt jetzt auch Ruhe

Vielen Dank für die tolle Arbeit

foxriver76 created this issue in ioBroker/ioBroker.js-controller

closed do not send null as diag info in error cases or if user has selected … #1354

[berti7]

Hm, ich muss leider nochmal nachhaken...

Beim Start versucht iobroker auch diese Adresse zu erreichen: s21181212.onlinehome-server.info

tcpdump:
17:19:57.311012 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842676723 ecr 0,nop,wscale 7], length 0
17:19:58.325227 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842677738 ecr 0,nop,wscale 7], length 0
17:20:00.405177 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842679818 ecr 0,nop,wscale 7], length 0
17:20:04.485193 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842683898 ecr 0,nop,wscale 7], length 0
17:20:12.885207 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842692298 ecr 0,nop,wscale 7], length 0
17:20:29.525208 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842708938 ecr 0,nop,wscale 7], length 0
17:21:02.165214 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842741578 ecr 0,nop,wscale 7], length 0

Passiert nur beim Start von iobroker und gibt dann Ruhe.
Verständnisfrage: was passiert da? Und gibts Langzeitfolgen wenn ich den Connect per Firewall unterbinde? Sorry wenn ich nochmal nerve, aber ich muss das wissen bevor das System in Produktivbetrieb geht.

Gruesse

[berti7]

... hab ein wenig geforscht: scheint vom vis-Adapter zu stammen ... Lizenzabfrage? Hm...

[apollon77]

@berti7 Es ist korrekt das

• vis und ggf andere Adapter die eine Lizenz benötigen (auch wenn es bei vis die "Private Use Lizenz" ist diese Online prüfen - ohne Zugriff kann vis bzw Lizenz-Adapter nicht genutzt werden
• Admin bzw CLI Kommandos das Adapter-Repository Online lädt - ohne Zugriff keine Adapter Updates u.ä.
• Admin zB ab Admin5 Adater-Ratings Online lädt - ohne Zugriff ggf keine Rating-Anzeige im Admin (ich hoffe es geht nicht mehr kaputt)
• Cloud bzw iot Adapter verbinden sich aus extern um Ihre Funktion anzubieten

Am Ende hat es die genannten Auswirkungen wenn diese Abfragen nicht zugelassen werden.

[apollon77]

@berti7 Wird in js-controller 3.3.10 behoben sein