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

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

... ich muss mich korrigieren. Die neuesten Aenderungen sind auf github:
https://github.com/ioBroker/ioBroker.js-controller/pull/1354/files

main.js von js-controller entsprechend angepasst, Problem beseitigt. Danke!

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

... 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

Meinst Du diese Änderung im file "main.js"??

// Collect statistics (only if license has been confirmed - user agreed)
if (systemConfig && systemConfig.common && systemConfig.common.diag && systemConfig.common.licenseConfirmed) { ... }

Ja, habs im changelog gesehen und auch ausprobiert ... leider keine Besserung

ok, sorry for that:
ich meinte folgenden Post: https://forum.iobroker.net/topic/45023/iobroker-telefoniert-nach-hause/1

Hallo,

ich habe folgendes zwar schon im "Allgemein" - Bereich gepostet, aber evtl. ist das hier besser aufgehoben:

(...)
Ich bin zwar neu hier im Forum aber ein langjähriger Mitleser und Nutzer von iobroker. Vorher bin ich 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 verbunden mit notorischem Speichermangel 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 + 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

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

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

... 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.