Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[viper]

@UncleSam
DHCP übernimmt die FritzBox Internetprovider ist die Telekom, müsste IPV6 tauglich sein.
Eine resolve.conf kann ich auf meinem Raspi nicht finden.
Aber das mit der IPV6 Adresse beim Ping ist wirklich merkwürdig, Tankerkönig gibt eine IPV4 Adresse zurück:

ping -a creativecommons.tankerkoenig.de

Ping wird ausgeführt für creativecommons.tankerkoenig.de [188.68.35.147] mit 32 Bytes Daten:
Antwort von 188.68.35.147: Bytes=32 Zeit=17ms TTL=58

Aber der Tankerkönig Adapter arbeitet gar nicht mehr, während Telegram sofort alle ausstehenden Messages senden nachdem ich irgendwo im Netz einen ping auf api.telegram.org ausführe.

Ansonsten haut der telegram Adapter mir sekündlich das log mit folgenden Fehlermeldungen zu:

telegram.0	2020-11-02 08:31:10.149	warn	(19369) polling_error:EFATAL, EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org
telegram.0	2020-11-02 08:31:09.827	warn	(19369) polling_error:EFATAL, EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org
telegram.0	2020-11-02 08:31:09.712	info	(19369) Terminated (NO_ERROR): Without reason
telegram.0	2020-11-02 08:31:09.709	info	(19369) terminating
telegram.0	2020-11-02 08:31:09.508	warn	(19369) polling_error:EFATAL, EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org
telegram.0	2020-11-02 08:31:09.222	error	(19369) Cannot send message [chatId - 211350777]: Error: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org
telegram.0	2020-11-02 08:31:09.212	error	(19369) RequestError: Error: getaddrinfo EAI_AGAIN api.telegram.org at new RequestError (/opt/iobroker/node_modules/request-promise-core/lib/errors.js:14:15) at Request.plumbing.callback (/opt
telegram.0	2020-11-02 08:31:09.212	error	(19369) unhandled promise rejection: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org
telegram.0	2020-11-02 08:31:09.211	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
telegram.0	2020-11-02 08:31:09.197	error	(19369) RequestError: Error: getaddrinfo EAI_AGAIN api.telegram.org at new RequestError (/opt/iobroker/node_modules/request-promise-core/lib/errors.js:14:15) at Request.plumbing.callback (/opt
telegram.0	2020-11-02 08:31:09.196	error	(19369) unhandled promise rejection: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org
telegram.0	2020-11-02 08:31:09.195	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
telegram.0	2020-11-02 08:31:09.188	warn	(19369) polling_error:EFATAL, EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org

[UncleSam]

@viper Kannst du mal folgende Befehle auf dem Raspi eingeben:

ifconfig
route
cat /etc/resolv.conf

Die genaue Erklärung von EAI_AGAIN findest du übrigens hier: https://github.com/nodejs/node/issues/15780#issuecomment-334496907

[viper]

@UncleSam
Danke für deine Hilfe!
ifconfig:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.21  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 2003:e0:5f42:3200:260:8202:7c9a:45c6  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::d8e4:f702:7b93:32b  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:18:a3:17  txqueuelen 1000  (Ethernet)
        RX packets 10630887  bytes 1464050587 (1.3 GiB)
        RX errors 0  dropped 4  overruns 0  frame 0
        TX packets 10961784  bytes 1061884727 (1012.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 141536388  bytes 44540763459 (41.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 141536388  bytes 44540763459 (41.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:18:a3:18  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

route:

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    202    0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0

cat /etc/resolv.conf:

# Generated by resolvconf
nameserver 192.168.178.1
nameserver fd00::464e:6dff:fef5:442f

[Thomas Braun]

@viper Die Einstellungen auf dem Pi sind i. O., sehen bei mir auch so aus (außer das bei mir auch noch wlan0 aktiv ist, aber das sollte nichts zur Sache tun).

Da würde ich den Schluckauf auf der FritzBox suchen. Sind da derzeitig alternative DNS-Server eingestellt? Wenn ja, welche?
Zum testen vielleicht mal die vom ISP einstellen, ohne 'Gedöns' drumherum.

Ich hatte mit DoT auch Probleme, seit einiger Zeit läuft das aber mit den DNS Servern von Quad9 ganz unauffällig bei mir.

[viper]

@Thomas-Braun
Ich hatte in einem ähnlichen Beitrag hier gelesen, das es manchmal hilft alternative DNS Server einzustellen, was ich gemacht habe. Das Problem bestand aber auch schon davor.
Es fing aber an als ich die neue FritzBox Firmware installiert und DNS over TLS aktiviert hatte (ist zwischenzeitlich auch wieder deaktiviert). Da das Update und die DNS over TLS am selben Tag gemacht wurden kann ich leider nicht genauer einschränken was von beiden das Problem verursacht.
Hier die aktuellen DNS angaben:

DNSv4-Server
Andere DNSv4-Server verwenden

Bevorzugter DNSv4-Server 8.8.8.8
Alternativer DNSv4-Server 194.150.168.168

DNSv6-Server
Vom Internetanbieter zugewiesene DNSv6-Server verwenden (empfohlen)

[Thomas Braun]

@viper Jaaaaaa, ich würde ja alle vier Server auch aus 'dem selben Haus' nehmen.

Ich habe da
DNSv4:

9.9.9.9
149.112.112.112

DNSv6:

2620:fe::fe: 
2620:fe::9

DNS over TLS:
Die ersten beiden Kästchen aktiv,
Fallback auf unverschlüsselte Namensauflösung im Internet zulassen
deaktiv.

Als Auflösungsnamen dann halt

dns.quad9.net

Das läuft hier ganz rund. Ich setze allerdings kein Telegram ein.
Mit tado hatte ich aber z. B. mit den DoT-verschlüsselten google-DNS auch solche Aussetzer nach einiger Zeit.

[viper]

@Thomas-Braun said in DNS Namensäuflösungs Probleme:

9.9.9.9

Danke für die Antwort, ich habe deine Angaben (bis auf DNS over TLS) mal übernommen und den Pi neu gestartet.
Leider immer noch das gleiche verhalten, Telegramm schreibt das log voll, nach dem Ping von api.telegram.org funktioniert der Telegram Adapter sofort für eine gewisse Zeit bis das gleiche Problem wieder auftritt.

[viper]

So habe auch mal die /etc/resolv.conf angepasst:

# Generated by resolvconf

nameserver 9.9.9.9

nameserver 2620:fe::fe: 

So das die DNS Auflösung nicht über die Fritzbox läuft. Leider keine Änderung...

[viper]

Sehe gerade, dass es keinen Sinn macht diese Datei anzupassen, da Sie von resolvconf neu erzeugt wird.
resolvconf hat die alten Einstellungen wieder rein geschrieben.

[Thomas Braun]

@viper
Steht ja auch da:

Generated by resolvconf

[viper]

Da mein Problem wohl einzigartig ist und es auch keine Ideen mehr gibt, habe ich mir als Workaround ein Blockly Skript geschrieben, welches alle 5min den Ping Befehl aufruft.
Das funktioniert erst einmal.

[liv-in-sky]

@viper ne ist nicht einzigartig - ich habe ähnliches problem - irgendwas wurde beim provider umgestellt - ich habe im moment ip6 in der fritzbox deaktiviert, damit läuft das ganze wieder - ich hatte auch bei einem ping ...eine antwort mit ip6 . bei dem befehl ping -v4 .... bekam ich keine antwort mehr

die fritzbox vergibt keine internen ip6 über dhcp

habe bis jetzt keine lösung bei mir gefunden (aber auch noch nicht richtig danach gesucht)

[viper]

@liv-in-sky
Das Problem, das er V4 nicht auflösen kann habe ich nicht, ein:

ping -4 api.telegram.org

unter Windows ergibt:

ping -4 api.telegram.org

Ping wird ausgeführt für api.telegram.org [149.154.167.220] mit 32 Bytes Daten:
Antwort von 149.154.167.220: Bytes=32 Zeit=26ms TTL=53
Antwort von 149.154.167.220: Bytes=32 Zeit=21ms TTL=53
Antwort von 149.154.167.220: Bytes=32 Zeit=21ms TTL=53
Antwort von 149.154.167.220: Bytes=32 Zeit=27ms TTL=53

Ping-Statistik für 149.154.167.220:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 21ms, Maximum = 27ms, Mittelwert = 23ms

Da scheinen wir doch unterschiedliche probleme zu haben.

[DerDom]

@viper hast Du hier eine Lösung gefunden?

Ich scheine das gleiche Problem zu haben, bekomme immer die folgende Fehlermeldung für mein Java-Skript (nachdem ich vom Vodafone-Kabel-Router zu Fritz-Box und Telekom gewechselt bin):

2022-11-02 05:00:20.074 - error: javascript.0 (771) Request error: Error: getaddrinfo EAI_AGAIN docs.google.com

Andere Adaprter scheinen ohne Probleme ins Internet zu kommen. So werden die Werte von weatherunderground anscheinend noch aktuell aus dem Internet geladen.

[DerDom]

IPv6-Unterstützung in der FritzBox deaktivieren hat geholfen. Besten Dank für den Hint!

Internet > Zugangsdaten > IPv6