2026.05.29 20:39:17 4: fheminfo send (nonblocking): {...}
2026.05.29 20:39:17 4: IP: fhem.de -> [2a01:4f8:221:1b5a::b2]
2026.05.29 20:39:21 1: fheminfo send: Server ERROR: connect to https://fhem.de:443 timed out
Das Problem tritt nur bei einer meiner drei FHEM-Instanzen auf.
Eine der beiden anderen Instanzen läuft hier im gleichen Netzwerk und funktioniert, ein generelles Netzwerkproblem schließe ich deshalb aus.
Hat jemand einen Tipp, wie ich das Problem weiter eingrenzen kann? Bauchgefühl sagt mir, ich könnte mal wieder ein IPv6 Problem haben. Denn die andere Instanz, die hier im Netzwerk funktioniert, verwendet eine IPv4 Adresse von fhem.de
2026.05.29 16:18:30.998 4: fheminfo send (nonblocking): {...}
2026.05.29 16:18:30.999 4: IP: fhem.de -> 188.40.131.57
2026.05.29 16:18:31.510 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.29 16:18:31.510 4: fheminfo send: Server RESPONSE: ==> ok
Wie ist denn Instanz 1 und wie Instanz 2 an dein Netzwerk angebunden?
Haben die Instanzen ggf. mehrere Netzwerkadapter?
Grüße Sidey
- Beide Instanzen laufen als Proxmox Container.
- Die nicht funktionierende Instanz hat das globale Attribut useInet6 gesetzt, die andere Instanz nicht.
- Die "nicht funktionierende" Instanz ist meine Produktivinstanz, auf der ansonsten netzwerktechnisch alle Verbindungen funktionieren, nur das fheminfo send klappt nicht.
Funktionierende Instanz:
udo@fhem-sip:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:ba:0b:06 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.123.219/24 brd 192.168.123.255 scope global dynamic eth0
valid_lft 79650sec preferred_lft 79650sec
inet6 fddc:7b04:1a06:0:be24:11ff:feba:b06/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 7200sec preferred_lft 3600sec
inet6 2002:5510:9940:0:be24:11ff:feba:b06/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 7199sec preferred_lft 3599sec
inet6 fe80::be24:11ff:feba:b06/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Nicht funktionierende Instanz:
udo@fhem:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:46:b6:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.123.111/24 brd 192.168.123.255 scope global dynamic eth0
valid_lft 75883sec preferred_lft 75883sec
inet6 fddc:7b04:1a06:0:be24:11ff:fe46:b6a4/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 6643sec preferred_lft 3043sec
inet6 2002:5510:9940:0:be24:11ff:fe46:b6a4/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 6642sec preferred_lft 3042sec
inet6 fe80::be24:11ff:fe46:b6a4/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Zitat von: betateilchen am 29 Mai 2026, 21:07:44- Die nicht funktionierende Instanz hat das globale Attribut useInet6 gesetzt, die andere Instanz nicht.
Wenn ich das Attribut entferne, funktioniert das Senden auch auf der Produktivinstanz:
2026.05.29 21:09:31 4: fheminfo send (nonblocking): {...}
2026.05.29 21:09:31 4: IP: fhem.de -> 188.40.131.57
2026.05.29 21:09:32 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.29 21:09:32 4: fheminfo send: Server RESPONSE: ==> ok
Dann funktionieren allerdings viele andere Dinge nicht mehr...
Du hast sehr wahrscheinlich ein IP V6 Problem.
Könnte das Problem außerhalb des Containers liegen? Vielleicht eine Firewall?
Grüße Sidey
Außerhalb des Containers: könnte sein, vielleicht sogar außerhalb meines Einflußbereichs?
Meine FHEM Installation holt sich updates über svn, und svn.fhem.de wird problemlos auch bei gesetztem useInet6 erreicht.
Edit: inzwischen wurde das Problem auch von anderen Usern bestätigt, wenn sie IPv6 verwenden.
Ich beteilige mich mal hier und schaue später nach, ob IPv6 in der fhem.de Umgebung richtig behandelt wird.
Ich muss noch rausfinden wo fheminfo wirklich zugreift, habe ich irgendwo schon mal notiert ;)
In letzter Zeit wurde aber nichts geändert, wenn es an der fhem Umgebung liegt sollte das Problem schon lange existieren.
Probiert doch mal folgenden Befehl in deiner Instanz:
curl -6 --connect-timeout 10 -v --trace-time --trace-ascii - 'https://fhem.de/stats/statistics2.cgi'
Zitat von: Otto123 am 30 Mai 2026, 09:54:44wenn es an der fhem Umgebung liegt sollte das Problem schon lange existieren.
Das kann durchaus sein, es ist mir aber gestern erst aufgefallen.
Zitat von: Sidey am 30 Mai 2026, 09:56:11Probiert doch mal folgenden Befehl in deiner Instanz:
curl -6 --connect-timeout 10 -v --trace-time --trace-ascii - 'https://fhem.de/stats/statistics2.cgi'
$ curl -6 --connect-timeout 10 -v --trace-time --trace-ascii - 'https://fhem.de/stats/statistics2.cgi'
Warning: --trace-ascii overrides an earlier trace/verbose option
10:24:32.803945 == Info: Host fhem.de:443 was resolved.
10:24:32.803982 == Info: IPv6: 2a01:4f8:221:1b5a::b2
10:24:32.803985 == Info: IPv4: (none)
10:24:32.804013 == Info: Trying [2a01:4f8:221:1b5a::b2]:443...
10:24:42.796647 == Info: Connection timed out after 10002 milliseconds
10:24:42.796680 == Info: closing connection #0
Edit: auf der funktionierenden Instanz hier im Netzwerk sieht das übrigens identisch aus:
# curl -6 --connect-timeout 10 -v --trace-time --trace-ascii - 'https://fhem.de/stats/statistics2.cgi'
Warning: --trace-ascii overrides an earlier trace/verbose option
10:31:01.291763 == Info: Host fhem.de:443 was resolved.
10:31:01.291795 == Info: IPv6: 2a01:4f8:221:1b5a::b2
10:31:01.291798 == Info: IPv4: (none)
10:31:01.291827 == Info: Trying [2a01:4f8:221:1b5a::b2]:443...
10:31:11.292928 == Info: Connection timed out after 10002 milliseconds
10:31:11.292963 == Info: closing connection #0
Edit 2: einen hab ich noch... FHEM auf einem Server bei AWS:
$ curl -6 --connect-timeout 10 -v --trace-time --trace-ascii - 'https://fhem.de/stats/statistics2.cgi'
Warning: --trace-ascii overrides an earlier trace/verbose option
10:34:48.534877 == Info: Trying [2a01:4f8:221:1b5a::b2]:443...
10:34:48.559384 == Info: Connected to fhem.de (2a01:4f8:221:1b5a::b2) port 443 (#0)
10:34:48.561544 == Info: ALPN: offers h2,http/1.1
10:34:48.561796 => Send SSL data, 5 bytes (0x5)
10:34:48.561827 == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
10:34:48.561835 => Send SSL data, 512 bytes (0x200)
10:34:48.599193 == Info: CAfile: /etc/ssl/certs/ca-certificates.crt
10:34:48.599234 == Info: CApath: /etc/ssl/certs
10:34:48.599284 <= Recv SSL data, 5 bytes (0x5)
10:34:48.599314 == Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
10:34:48.599325 <= Recv SSL data, 122 bytes (0x7a)
10:34:48.599584 <= Recv SSL data, 5 bytes (0x5)
10:34:48.599604 <= Recv SSL data, 5 bytes (0x5)
10:34:48.599638 <= Recv SSL data, 1 bytes (0x1)
10:34:48.599674 == Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
10:34:48.599703 <= Recv SSL data, 19 bytes (0x13)
10:34:48.599742 <= Recv SSL data, 5 bytes (0x5)
10:34:48.599776 <= Recv SSL data, 1 bytes (0x1)
10:34:48.599802 == Info: TLSv1.3 (IN), TLS handshake, Certificate (11):
10:34:48.599814 <= Recv SSL data, 2025 bytes (0x7e9)
10:34:48.602145 <= Recv SSL data, 5 bytes (0x5)
10:34:48.602188 <= Recv SSL data, 1 bytes (0x1)
10:34:48.602208 == Info: TLSv1.3 (IN), TLS handshake, CERT verify (15):
10:34:48.602220 <= Recv SSL data, 80 bytes (0x50)
10:34:48.602404 <= Recv SSL data, 5 bytes (0x5)
10:34:48.602430 <= Recv SSL data, 1 bytes (0x1)
10:34:48.602466 == Info: TLSv1.3 (IN), TLS handshake, Finished (20):
10:34:48.602477 <= Recv SSL data, 36 bytes (0x24)
10:34:48.602548 => Send SSL data, 5 bytes (0x5)
10:34:48.602564 == Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
10:34:48.602576 => Send SSL data, 1 bytes (0x1)
10:34:48.602633 => Send SSL data, 5 bytes (0x5)
10:34:48.602645 => Send SSL data, 1 bytes (0x1)
10:34:48.602663 == Info: TLSv1.3 (OUT), TLS handshake, Finished (20):
10:34:48.602675 => Send SSL data, 36 bytes (0x24)
10:34:48.602750 == Info: SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
10:34:48.602765 == Info: ALPN: server accepted h2
10:34:48.602780 == Info: Server certificate:
10:34:48.602798 == Info: subject: CN=fhem.de
10:34:48.602813 == Info: start date: May 23 21:47:54 2026 GMT
10:34:48.602826 == Info: expire date: Aug 21 21:47:53 2026 GMT
10:34:48.602847 == Info: subjectAltName: host "fhem.de" matched cert's "fhem.de"
10:34:48.602867 == Info: issuer: C=US; O=Let's Encrypt; CN=E8
10:34:48.602880 == Info: SSL certificate verify ok.
10:34:48.602945 => Send SSL data, 5 bytes (0x5)
10:34:48.602959 => Send SSL data, 1 bytes (0x1)
10:34:48.602988 == Info: using HTTP/2
10:34:48.603032 == Info: h2h3 [:method: GET]
10:34:48.603044 == Info: h2h3 [:path: /stats/statistics2.cgi]
10:34:48.603055 == Info: h2h3 [:scheme: https]
10:34:48.603066 == Info: h2h3 [:authority: fhem.de]
10:34:48.603076 == Info: h2h3 [user-agent: curl/7.88.1]
10:34:48.603087 == Info: h2h3 [accept: */*]
10:34:48.603103 == Info: Using Stream ID: 1 (easy handle 0x55bb778c7470)
10:34:48.603164 => Send SSL data, 5 bytes (0x5)
10:34:48.603177 => Send SSL data, 1 bytes (0x1)
10:34:48.603203 => Send header, 90 bytes (0x5a)
0000: GET /stats/statistics2.cgi HTTP/2
0023: Host: fhem.de
0032: user-agent: curl/7.88.1
004b: accept: */*
0058:
10:34:48.627331 <= Recv SSL data, 5 bytes (0x5)
10:34:48.627412 <= Recv SSL data, 1 bytes (0x1)
10:34:48.627490 == Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
10:34:48.627502 <= Recv SSL data, 57 bytes (0x39)
10:34:48.627580 <= Recv SSL data, 5 bytes (0x5)
10:34:48.627599 <= Recv SSL data, 1 bytes (0x1)
10:34:48.627620 == Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
10:34:48.627632 <= Recv SSL data, 57 bytes (0x39)
10:34:48.627674 == Info: old SSL session ID is stale, removing
10:34:48.627713 <= Recv SSL data, 5 bytes (0x5)
10:34:48.627752 <= Recv SSL data, 1 bytes (0x1)
10:34:48.627789 => Send SSL data, 5 bytes (0x5)
10:34:48.627805 => Send SSL data, 1 bytes (0x1)
10:34:48.697751 <= Recv SSL data, 5 bytes (0x5)
10:34:48.697845 <= Recv SSL data, 1 bytes (0x1)
10:34:48.697919 <= Recv header, 13 bytes (0xd)
0000: HTTP/2 302
10:34:48.697940 <= Recv header, 37 bytes (0x25)
0000: date: Sat, 30 May 2026 08:34:49 GMT
10:34:48.697963 <= Recv header, 32 bytes (0x20)
0000: server: Apache/2.4.52 (Ubuntu)
10:34:48.697986 <= Recv header, 27 bytes (0x1b)
0000: location: statistics.html
10:34:48.698033 <= Recv header, 2 bytes (0x2)
0000:
10:34:48.699513 <= Recv SSL data, 5 bytes (0x5)
10:34:48.699566 <= Recv SSL data, 1 bytes (0x1)
10:34:48.699595 <= Recv data, 0 bytes (0x0)
10:34:48.699632 == Info: Connection #0 to host fhem.de left intact
(die umfangreichen ssl-payloads habe ich entfernt)
Ich hatte mal das Problem, dass mein Provider (oder jemand dahinter) jeden dritten IPv6 Paket falsch geroutet hat, IPv4 war OK.
Ich wuerde als Naechstes traceroute probieren.
Zitat von: rudolfkoenig am 30 Mai 2026, 11:38:39Ich wuerde als Naechstes traceroute probieren.
kann ich gerne machen, aber wenn von zwei Instanzen aus dem gleichen lokalen Netz eine funktioniert und die zweite nicht, und bei der "nicht funktionierenden" die IPv6 Verbindung zu svn.fhem trotzdem funktioniert, vermute ich erstmal nicht den Provider als Ursache :)
traceroute to fhem.de (188.40.131.57), 30 hops max, 60 byte packets
1 fritz.box (192.168.123.254) 0.609 ms 5.517 ms 5.480 ms
2 85.16.121.248 (85.16.121.248) 6.431 ms 6.421 ms 6.878 ms
3 76730200-20.ewe-ip-backbone.de (85.16.253.36) 19.689 ms 19.667 ms 20.314 ms
4 213.170.165.2 (213.170.165.2) 20.416 ms 213.170.165.0 (213.170.165.0) 21.042 ms 20.997 ms
5 55730800-5.ewe-ip-backbone.de (212.6.115.141) 21.373 ms 21.579 ms 21.543 ms
6 23730200-31.ewe-ip-backbone.de (212.6.115.196) 21.699 ms 18.609 ms 18.990 ms
7 ae10-0.fra20.core-backbone.com (5.56.21.129) 19.247 ms 18.653 ms 18.757 ms
8 ae6-2011.nbg40.core-backbone.com (80.255.14.246) 21.199 ms 21.164 ms 21.362 ms
9 core-backbone.hetzner.com (81.95.15.6) 22.326 ms 22.337 ms 22.388 ms
10 core23.fsn1.hetzner.com (213.239.252.246) 25.183 ms core23.fsn1.hetzner.com (213.239.252.230) 38.298 ms core23.fsn1.hetzner.com (213.239.252.246) 31.936 ms
11 ex9k1.dc13.fsn1.hetzner.com (213.239.254.194) 25.149 ms ex9k1.dc13.fsn1.hetzner.com (213.239.245.242) 25.187 ms ex9k1.dc13.fsn1.hetzner.com (213.239.254.194) 25.589 ms
12 vmhost.fhem.de (188.40.131.57) 25.422 ms 23.370 ms 23.752 ms
und hier für IPv6:
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2002:5f21:38b3:0:7642:7fff:fe07:4e16) 0.678 ms 0.814 ms 1.025 ms
2 2002:c058:6301::1 (2002:c058:6301::1) 17.221 ms 17.868 ms 18.298 ms
3 * * *
4 be6.core2.ams2.he.net (2001:470:0:61c::2) 95.224 ms 95.179 ms 96.678 ms
5 * * *
... wiederholt sich bis 30 ...
beim mir für IPv6
traceroute -6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 2a02:6d40:3bad:cbfc::1 (2a02:6d40:3bad:cbfc::1) 0.468 ms 0.449 ms 0.375 ms
2 fritz.box (2a02:6d40:3bad:cb00:2e91:abff:fef7:a480) 1.762 ms 3.096 ms 3.633 ms
3 2a01:5c0:1:2::38 (2a01:5c0:1:2::38) 19.361 ms 19.281 ms 19.231 ms
4 * * *
5 ::ffff:172.16.128.8 (::ffff:172.16.128.8) 35.308 ms 38.626 ms 38.562 ms
6 * * *
7 decix-gw.hetzner.com (2001:7f8::616c:0:1) 33.021 ms 32.997 ms 30.086 ms
8 core21.fsn1.hetzner.com (2a01:4f8:0:3::4d1) 37.157 ms core24.fsn1.hetzner.com (2a01:4f8:0:3::4c1) 37.396 ms core22.fsn1.hetzner.com (2a01:4f8:0:3::4e1) 39.954 ms
9 ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::ea) 39.811 ms 41.124 ms 43.554 ms
10 vmhost2.fhem.de (2a01:4f8:221:1b5a::2) 43.414 ms 44.165 ms 47.079 ms
11 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2) 35.258 ms 34.181 ms 36.210 mswarum unterscheidet sich Zeile 5 so sehr von Zeile 4 bei betateilchen?
Von einem anderen PC anderes Netzwerk (allerdings gleicher Provider)
tracert -6 fhem.de
Routenverfolgung zu fhem.de [2a01:4f8:221:1b5a::b2]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms fritz.box [2a02:6d40:3bb8:1:1eed:6fff:fe83:d51]
2 24 ms 22 ms 23 ms 2a01:5c0:1:2::38
3 * * * Zeitüberschreitung der Anforderung.
4 36 ms 35 ms 35 ms ::ffff:172.16.128.8
5 42 ms 41 ms 48 ms 2a01:5c0:6::93
6 41 ms 40 ms 41 ms decix-gw.hetzner.com [2001:7f8::616c:0:1]
7 45 ms 45 ms 44 ms core24.fsn1.hetzner.com [2a01:4f8:0:3::4c1]
8 46 ms 45 ms 45 ms ex9k1.dc13.fsn1.hetzner.com [2a01:4f8:0:3::ea]
9 46 ms 45 ms 45 ms vmhost2.fhem.de [2a01:4f8:221:1b5a::2]
10 47 ms 45 ms 45 ms 2a01:4f8:221:1b5a::b2
anderes Netz, anderer Provider
traceroute -6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2003:c1:671c:6700:de39:6fff:fec9:a649) 5.725 ms 5.399 ms 5.064 ms
2 2003:0:8700:2000::1 (2003:0:8700:2000::1) 12.049 ms 11.866 ms 11.869 ms
3 * * *
4 2003:0:f00::a1d (2003:0:f00::a1d) 18.201 ms 20.473 ms 20.305 ms
5 core21.fsn1.hetzner.com (2a01:4f8:0:3::4d5) 23.990 ms core23.fsn1.hetzner.com (2a01:4f8:0:3::4b5) 23.090 ms core24.fsn1.hetzner.com (2a01:4f8:0:3::4c5) 24.081 ms
6 ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::5e2) 26.539 ms ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::ea) 23.408 ms ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::e6) 23.507 ms
7 vmhost2.fhem.de (2a01:4f8:221:1b5a::2) 19.679 ms 18.527 ms 21.709 ms
8 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2) 24.176 ms 23.421 ms 23.768 ms
Ich weiß nicht ob das irgendwie bei der Analyse hilft?
fhem.de und svn.fhem.de haben die gleiche IPv6 und landen auf einem Proxy, url (domain) abhängig landen sie dann bei einem anderen backend.
Zitatkann ich gerne machen, aber wenn von zwei Instanzen aus dem gleichen lokalen Netz eine funktioniert und die zweite nicht, und bei der "nicht funktionierenden" die IPv6 Verbindung zu svn.fhem trotzdem funktioniert, vermute ich erstmal nicht den Provider als Ursache :)
Provider kann man auch enger fassen: wie schaut traceroute aus dem jeweiligen Proxmox Container aus?
Zitat von: betateilchen am 30 Mai 2026, 09:32:15Edit: inzwischen wurde das Problem auch von anderen Usern bestätigt, wenn sie IPv6 verwenden.
Hinweis:
Mein FHEM Container kann auch nicht mit IPv6 nach draußen telefonieren.
Das liegt aber daran, dass ich keine globale v6 Adresse in meinen Containern haben sonder nur lokale.
Ipv6 nat habe ich auch nicht im Einsatz, also geht es per Definition nicht.
Sieht von der Auswirkung so aus wie dein Problem aber ein anderes.
Grüße Sidey
Zitat von: rudolfkoenig am 30 Mai 2026, 12:37:14wie schaut traceroute aus dem jeweiligen Proxmox Container aus?
Funktionierende Instanz:
udo@fhem-sip:~$ traceroute -6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2002:5f21:38b3:0:7642:7fff:fe07:4e16) 5.018 ms 4.979 ms 4.944 ms
2 2002:c058:6301::1 (2002:c058:6301::1) 17.724 ms 17.691 ms 17.880 ms
3 * * *
4 be6.core2.ams2.he.net (2001:470:0:61c::2) 32.982 ms 32.950 ms 32.878 ms
5 * * *
6 * * *
7 * * *
... wiederholt sich bis 30 ...
Nicht funktionierende Instanz:
udo@fhem:~$ traceroute -6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2002:5f21:38b3:0:7642:7fff:fe07:4e16) 0.628 ms 0.681 ms 0.814 ms
2 2002:c058:6301::1 (2002:c058:6301::1) 17.305 ms 17.370 ms 17.787 ms
3 * * *
4 be6.core2.ams2.he.net (2001:470:0:61c::2) 174.833 ms 174.816 ms 174.815 ms
5 * * *
6 * * *
7 * * *
... wiederholt sich bis 30 ...
Der Vollständigkeit halber auch noch traceroute zu svn.fhem.de
udo@fhem:~$ traceroute -6 svn.fhem.de
traceroute to svn.fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2002:5f21:38b3:0:7642:7fff:fe07:4e16) 0.719 ms 0.827 ms 0.962 ms
2 2002:c058:6301::1 (2002:c058:6301::1) 17.435 ms 17.372 ms 18.330 ms
3 * * *
4 be6.core2.ams2.he.net (2001:470:0:61c::2) 139.519 ms 140.867 ms 140.877 ms
5 * * *
6 * * *
7 * * *
... wiederholt sich bis 30 ...
(auf beiden Instanzen)
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?
Zitat von: Otto123 am 30 Mai 2026, 22:45:34Die 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.
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:
ZitatBitte 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.
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.
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.
Zitat von: Otto123 am 31 Mai 2026, 11:09:45Die 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:
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:~# 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:
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":
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
Auf meinem mac-mini komme ich per traceroute6 auch nicht bis zu fhem.de durch.
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:
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
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.
Zitat von: betateilchen am 31 Mai 2026, 18:30:17Zum Thema "ping Zeiten zur Fritzbox":
Ich meinte den hier:
Zitatudo@fhem-sip:~$ traceroute -6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2002:5f21:38b3:0:7642:7fff:fe07:4e16) 5.018 ms 4.979 ms 4.944 ms
Wie komme ich auf be6.core2.ams2.he.net ? Steht bei Dir im Traceroute. Ich habe keine Ahnung wie Traceroute die hops im Namen auflöst. So per Ping löst er diesen Namen bei mir auch nicht auf.
Aber ein ping IPv6 auf fhem.de sollte ohne Probleme funktionieren:
Zitatping6 fhem.de
PING fhem.de(2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2)) 56 data bytes
64 bytes from 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2): icmp_seq=1 ttl=57 time=18.7 ms
64 bytes from 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2): icmp_seq=2 ttl=57 time=17.8 ms
64 bytes from 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2): icmp_seq=3 ttl=57 time=18.1 ms
64 bytes from 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2): icmp_seq=4 ttl=57 time=17.8 ms
64 bytes from 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2): icmp_seq=5 ttl=57 time=18.1 ms
In der Tat ist aber IPv6 einen Hop länger, weil der Proxmox Host dort nochmal weiter routet:
Zitattraceroute -6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2003:c1:671c:6700:de39:6fff:fec9:a649) 1.350 ms 1.875 ms 2.006 ms
2 2003:0:8700:2000::1 (2003:0:8700:2000::1) 13.424 ms 13.296 ms 13.381 ms
3 * * *
4 2003:0:f00::a1d (2003:0:f00::a1d) 18.285 ms 20.742 ms 20.612 ms
5 core22.fsn1.hetzner.com (2a01:4f8:0:3::4e5) 25.185 ms 26.736 ms core23.fsn1.hetzner.com (2a01:4f8:0:3::4b5) 25.137 ms
6 ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::5e2) 28.607 ms ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::5fa) 19.353 ms 21.705 ms
7 vmhost2.fhem.de (2a01:4f8:221:1b5a::2) 17.525 ms 19.971 ms 19.820 ms
8 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2) 22.292 ms 23.210 ms 23.064 ms
Zitattraceroute -4 fhem.de
traceroute to fhem.de (188.40.131.57), 30 hops max, 60 byte packets
1 fritz.box (192.168.178.1) 0.925 ms 0.444 ms 0.541 ms
2 p3e9bf789.dip0.t-ipconnect.de (62.155.247.137) 8.304 ms 8.018 ms 7.798 ms
3 f-ed12-i.F.DE.NET.DTAG.DE (193.158.121.90) 14.443 ms 14.277 ms f-ed12-i.F.DE.NET.DTAG.DE (62.154.4.234) 16.132 ms
4 62.157.248.241 (62.157.248.241) 15.765 ms 15.773 ms 15.776 ms
5 core21.fsn1.hetzner.com (213.239.224.101) 21.636 ms core23.fsn1.hetzner.com (213.239.224.69) 21.440 ms 21.573 ms
6 ex9k1.dc13.fsn1.hetzner.com (213.239.245.242) 21.309 ms ex9k1.dc13.fsn1.hetzner.com (213.239.254.170) 18.675 ms ex9k1.dc13.fsn1.hetzner.com (213.239.245.242) 18.989 ms
7 vmhost.fhem.de (188.40.131.57) 18.165 ms 17.724 ms 17.970 ms
Habe irgendwie keine Idee wie ich dir helfen kann. Sieht für mich so aus, als existiert zwar der Weg zu deinem AWS, aber kein Weg in die Welt?
na da schau her...
# traceroute6 fhem.de
traceroute to fhem.de (2a01:4f8:221:1b5a::b2), 30 hops max, 80 byte packets
1 fritz.box (2a02:8206:52af:8000:7642:7fff:fe07:4e16) 0.596 ms 0.728 ms 0.817 ms
2 2a02:8200::4:1de0 (2a02:8200::4:1de0) 29.622 ms 29.601 ms 29.668 ms
3 * * *
4 2a02:8200::1:9 (2a02:8200::1:9) 20.899 ms 20.852 ms 20.804 ms
5 2a02:8200::101:34:0:101 (2a02:8200::101:34:0:101) 20.772 ms 20.756 ms 20.942 ms
6 2a02:8200::102:42:0:100 (2a02:8200::102:42:0:100) 20.776 ms 18.445 ms 18.689 ms
7 decix-gw.hetzner.com (2001:7f8::616c:0:1) 18.615 ms 18.295 ms 18.416 ms
8 core22.fsn1.hetzner.com (2a01:4f8:0:3::4e1) 23.783 ms core23.fsn1.hetzner.com (2a01:4f8:0:3::4b1) 23.629 ms 23.788 ms
9 ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::e6) 30.079 ms ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::ea) 29.971 ms ex9k1.dc13.fsn1.hetzner.com (2a01:4f8:0:3::5fa) 23.678 ms
10 vmhost2.fhem.de (2a01:4f8:221:1b5a::2) 22.965 ms 23.011 ms 23.247 ms
11 2a01:4f8:221:1b5a::b2 (2a01:4f8:221:1b5a::b2) 23.563 ms 24.185 ms 24.129 ms
In der Fritzbox habe ich in den IPv6 Einstellungen
von "IPv6-Anbindung mit Tunnelprotokoll verwenden"
auf "IPv4-Anbindung über DS-Lite herstellen"
umgestellt. Dann klappts auch mit "fheminfo send"
2026.05.31 20:36:42 4: fheminfo send (nonblocking): {...}
2026.05.31 20:36:42 4: IP: fhem.de -> [2a01:4f8:221:1b5a::b2]
2026.05.31 20:36:42 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.31 20:36:42 4: fheminfo send: Server RESPONSE: ==> ok
Danke an alle fürs Mitdenken und den einen oder anderen Hinweis, der mir letztlich weitergeholfen hat!
Mal schauen, ob sich die Umstellung irgendwo anders negativ auswirkt.
Nochmal was generelles zum Theme fheminfo / FHEM-statistics
number of submissions today: 33
number of submissions (last 12 months, used for statistics): 2017
Gestern Abend waren ca. 100 submissions für den Tag registriert, aber warum sind das in den letzten 12 Monaten (angeblich) nur 2017 submissions?
Früher waren pro Jahr submissions im 5-stelligen Bereich.
Entweder, da gehen/gingen irgendwo submissions verloren oder wir sollten mal dringend die Werbetrommel für "fheminfo send" rühren. Sonst können wir uns den Aufwand mit der Statistik auch komplett sparen.