fheminfo send: timeout beim Senden

[Otto123]

bei dem traceroute von betateilchen fällt mir folgendes auf:
Die funktionierenden Instanz hat längere Pingzeiten zur Fritzbox als die nicht funktionierende - ist die anders angebunden?
Die funktionierende Instanz hat kürzere Pingzeiten zum be6.core2.ams2.he.net als die nicht funktionierende.

Keine Idee warum das so ist.

Ist fheminfo send sensibel mit dem Timeout und update vom svn.fhem.de ist toleranter?

[betateilchen]

Die funktionierenden Instanz hat längere Pingzeiten zur Fritzbox als die nicht funktionierende - ist die anders angebunden?

Beide Container laufen auf dem gleichen Proxmox host.

Den Timeout habe ich testweise auf 10 Sekunden gestellt, das hat keine Änderung gebracht.
Wie gesagt - es funktionieren sehr viele Verbindungen über IPv6, aber das fheminfo scheitert.

[Otto123]

Nur am Rande:
Als ich jetzt in einer Instanz useInet6 setzen wollte und IO::Socket::INET6 noch nicht installiert war, sah ich bei dem debian Paket libio-socket-inet6-perl die Info:

Bitte beachten Sie, dass IO-Socket-INET6 als veraltet gilt. Es wurde von IO::Socket::IP abgelöst. Bitte ziehen Sie in Erwägung, alten Code von IO-Socket-INET6 zu IO-Socket-IP zu konvertieren.

Ich habe jetzt bei mir alle möglichen Geräte mit traceroute -6 getestet: bei allen per LAN (egal ob auch bloß mit 100 Mbit) angebundenen Geräten liegen die Responsezeiten zum ersten Router um die 0,5 ms. Responsezeiten über 1 ms habe ich bei Wlan Geräten, aber selbst da unter 5 ms.

Mich (oder den Monk in mir ) stören irgendwie die 5 ms zur Fritzbox bei Deiner funktionierenden Instanz...
Die Zwischen Hops werden bei Dir vom Namen her nicht aufgelöst.
Die Ping Zeit zum be6.core2.ams2.he.net ist bei der nicht funktionierenden Instanz sehr hoch. Wie ist denn die ping Zeit zu fhem.de? Bei mir ist die immer um die 34 ms.

Ich weiß, das ist alles nur laut nachgedacht und kein Lösungsansatz. Ich könnte gerne, wenn ich wüßte wie und wenn es hilft, auf dem backend für fhem.de etwas loggen.

[betateilchen]

Also grundsätzlich kann die "nicht funktionierende" Instanz per IPv6 nach draußen telefonieren.
Ein MQTT2_CLIENT verbindet sich mit einem meiner beiden mqtt Server, der bei AWS läuft und dort ausschließlich per IPv6 erreichbar ist.

Code Auswählen Erweitern

2026.05.31 18:11:25 5: HttpUtils url=https://mqtt.xxx.de:8883/ NonBlocking via https
2026.05.31 18:11:25 4: IP: mqtt.xxx.de -> [2a05:d018:796:5200:...]
2026.05.31 18:11:27 5: mqtt2_AWS: sending CONNECT (16)(27)(0)(6)MQIsdp(3)(2)(0)(30)(0)(13)fhem_HOME_tls
2026.05.31 18:11:27 5: DevIo_SimpleWrite mqtt2_AWS: 101...
2026.05.31 18:11:27 1: mqtt.xxx.de:8883 reappeared (mqtt2_AWS)
2026.05.31 18:11:29 4: mqtt2_AWS received CONNACK
2026.05.31 18:11:29 5: mqtt2_AWS: received CONNACK (0)(0)

An ein generelles lokales IPv6 Problem hier glaube ich deshalb nicht.

Die Ping Zeit zum be6.core2.ams2.he.net ist bei der nicht funktionierenden Instanz sehr hoch. Wie ist denn die ping Zeit zu fhem.de? Bei mir ist die immer um die 34 ms.

Ich kann fhem.de über IPv6 nicht anpingen.

Aber ich kann auch be6.core2.ams2.he.net nicht anpingen, der Name wird nicht aufgelöst:

Code Auswählen Erweitern

root@fhem:~# ping4 be6.core2.ams2.he.net
ping4: be6.core2.ams2.he.net: Name or service not known
root@fhem:~# ping6 be6.core2.ams2.he.net
ping6: be6.core2.ams2.he.net: Name or service not known
root@fhem:~#

Code Auswählen Erweitern

root@fhem:~# ping6 fhem.de
PING fhem.de (2a01:4f8:221:1b5a::b2) 56 data bytes

--- fhem.de ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6130ms


IPv4 funktioniert:

Code Auswählen Erweitern

root@fhem:~# ping fhem.de
PING fhem.de (188.40.131.57) 56(84) bytes of data.
64 bytes from vmhost.fhem.de (188.40.131.57): icmp_seq=1 ttl=55 time=23.9 ms
64 bytes from vmhost.fhem.de (188.40.131.57): icmp_seq=2 ttl=55 time=45.7 ms
64 bytes from vmhost.fhem.de (188.40.131.57): icmp_seq=3 ttl=55 time=23.4 ms

--- fhem.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 23.409/31.017/45.729/10.404 ms

Zum Thema "ping Zeiten zur Fritzbox":

Code Auswählen Erweitern

root@fhem:~# ping6 fritz.box
PING fritz.box (fddc:7b04:1a06:0:7642:...) 56 data bytes
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=1 ttl=64 time=1.39 ms
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=2 ttl=64 time=0.532 ms
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=3 ttl=64 time=0.555 ms
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=4 ttl=64 time=0.676 ms
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=5 ttl=64 time=0.572 ms
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=6 ttl=64 time=0.568 ms
64 bytes from fritz.box (fddc:7b04:1a06:0:7642:...): icmp_seq=7 ttl=64 time=0.569 ms

--- fritz.box ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6153ms
rtt min/avg/max/mdev = 0.532/0.694/1.391/0.287 ms


root@fhem:~# ping4 fritz.box
PING fritz.box (192.168.123.254) 56(84) bytes of data.
64 bytes from fritz.box (192.168.123.254): icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=2 ttl=64 time=0.508 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=3 ttl=64 time=0.513 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=4 ttl=64 time=0.509 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=5 ttl=64 time=0.600 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=6 ttl=64 time=0.728 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=7 ttl=64 time=0.634 ms
64 bytes from fritz.box (192.168.123.254): icmp_seq=8 ttl=64 time=0.482 ms

--- fritz.box ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7144ms
rtt min/avg/max/mdev = 0.482/0.559/0.728/0.080 ms


[betateilchen]

Auf meinem mac-mini komme ich per traceroute6 auch nicht bis zu fhem.de durch.

Code Auswählen Erweitern

traceroute6 to fhem.de (2a01:4f8:221:1b5a::b2) from 2002:5bf8:ee97:0:4c39:..., 64 hops max, 28 byte packets
 1  fritz.box  0.882 ms  0.798 ms  0.669 ms
 2  2002:c058:6301::1  16.731 ms  17.100 ms  17.179 ms
 3  * * *
 4  be6.core2.ams2.he.net  675.343 ms  579.687 ms  558.446 ms
 5  * * *
 6  * * *
 7  * * *
... wiederholt sich bis zum manuellen Abbruch ...

In IPv4 sieht das anders aus:

Code Auswählen Erweitern

1  fritz.box (192.168.123.254)  1.342 ms  0.825 ms  0.530 ms
 2  85.16.121.248 (85.16.121.248)  6.351 ms  6.224 ms  5.957 ms
 3  76730200-20.ewe-ip-backbone.de (85.16.253.36)  18.946 ms  19.031 ms  18.818 ms
 4  * * *
 5  * * *
 6  23730200-31.ewe-ip-backbone.de (212.6.115.196)  19.257 ms  19.258 ms  19.242 ms
 7  ae10-0.fra20.core-backbone.com (5.56.21.129)  19.030 ms  19.022 ms  22.125 ms
 8  ae6-2011.nbg40.core-backbone.com (80.255.14.246)  21.492 ms  21.690 ms  21.542 ms
 9  core-backbone.hetzner.com (81.95.15.6)  21.824 ms
    core-backbone.hetzner.com (5.56.20.254)  21.872 ms  33.170 ms
10  core24.fsn1.hetzner.com (213.239.252.234)  23.586 ms  24.072 ms
    core24.fsn1.hetzner.com (213.239.252.250)  30.627 ms
11  ex9k1.dc13.fsn1.hetzner.com (213.239.245.242)  24.714 ms  23.787 ms  23.810 ms
12  vmhost.fhem.de (188.40.131.57)  23.959 ms  23.925 ms  24.096 ms


[betateilchen]

Zum Thema "svn.fhem.de funktioniert" ist mir noch was eingefallen.

Das wird nicht aus FHEM heraus ausgeführt, sondern per cmdalias als Befehl auf der Betriebssystemebene. D.h. die Verbindung zu svn.fhem.de erfolgt dann aus dem Container auch per IPv4.