BackItUp Update hängt

Ist aber leider offensichtlich. Wenn du innerhalb deines LXC IPv6 nicht deaktivierst, so geht ioBroker natürlich davon aus, dass per DNS aufgelöste IPv6 Adressen erreichbar sein müssen. Da die IPv6 Kommunikation außerhalb des Containers durch deine Eingriffe gegen die Wand läuft, kommt es zu den Fehlern.

Du solltest also auch im Container IPv6 abschalten. ioBroker kann für deine Probleme überhaupt nichts.

Thomas Braun

@marc-berg

Genau solche Konstellationen meine ich mit 'handgefrickelt'. Wenn man schon meint, es sei besser sein Netzwerk zu verstümmeln und auf Dienste zu verzichten, dann muss halt jeder andere Netzteilnehmer auch entsprechend richtig passend zu dem Sonderstrick konfiguriert werden.

Wir wird sich der Host wohl selber eine ipv6-Adresse verpasst haben.

myssv

@marc-berg sagte in BackItUp Update hängt:

Du solltest also auch im Container IPv6 abschalten.

Genau das war ich der Meinung hätte ich mit diesen Einstellungen im Proxmox beim ioBroker gemacht:

Marc Berg

@myssv sagte in BackItUp Update hängt:

Genau das war ich der Meinung hätte ich mit diesen Einstellungen im Proxmox beim ioBroker gemacht:

An deiner Liste der offenen Ports kann man sehen: IPv6 ist nicht deaktiviert.

*** Listening Ports ***

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      0          34560      1/init              
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      109        32996      126/redis-server 12 
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          61685      1381/master         
tcp6       0      0 :::111                  :::*                    LISTEN      0          34562      1/init              
tcp6       0      0 :::22                   :::*                    LISTEN      0          23037      1/init              
tcp6       0      0 :::8081                 :::*                    LISTEN      1001       34063654   106519/io.admin.0   
tcp6       0      0 ::1:6379                :::*                    LISTEN      109        32997      126/redis-server 12 
tcp6       0      0 ::1:25                  :::*                    LISTEN      0          61686      1381/master         
udp        0      0 0.0.0.0:111             0.0.0.0:*                           0          34561      1/init              
udp6       0      0 :::111                  :::*                                0          34563      1/init

Wie man das in einem LXC komplett deaktiviert, kann ich dir nicht sagen, kenne Proxmox kaum und habe mich auch nicht dem Kampf gegen IPv6 verschrieben. :-)

Homoran

@myssv sagte in BackItUp Update hängt:

@marc-berg sagte in BackItUp Update hängt:

Du solltest also auch im Container IPv6 abschalten.

Genau das war ich der Meinung hätte ich mit diesen Einstellungen im Proxmox beim ioBroker gemacht:

das sehe ich anders.

das ist nicht deaktiviert, sondern auf feste IP gestellt, die aber nicht vergeben wird, was die Sache nicht besser macht.

@marc-berg sagte in BackItUp Update hängt:

Wie man das in einem LXC komplett deaktiviert, kann ich dir nicht sagen

Wildbill

@homoran @myssv Mit diesem Setting sollte im LXC eine feste IPv4 vergeben werden, für IPv6 aber nur eine link local (fe80:…. ).
Wenn dann vom LXC aus aber DNS-Adressen auf IPv6 anstatt IPv4 aufgelöst werden, so liegt es, meiner Meinung nach, an einer fehlerhaften Konfiguration des DNS-Servers (Router oder Pihole, Adguard oder Ähnliches).

Ansonsten stimmte ich aber zu: Es gibt keinen nachvollziehbaren Grund (für mich) sein Netzwerk künstlich zu kastrieren und auf IPv6 zu verzichten. Wie man sieht, macht es mehr Probleme als es Nutzen bringt (welcher Nutzen wäre hier überhaupt denkbar?).

Gruss, Jürgen

myssv

@wildbill und was passiert, wenn überhaupt kein IPv6 Server im Netz vorhanden ist und die Adressen gar nicht über IPv6 aufgelöst werden können?

Kommen dann solche TimeOuts zustande?

npm ERR! network request to https://registry.npmjs.org/iobroker.ws/-/iobroker.ws-2.5.8.tgz failed, reason: connect ETIMEDOUT 2606:4700::6810:1f22:443

Warum fällt er dann nicht auf IPv4 zurück?

Das ist ja scheinbar genau mein Problem.

Wildbill

@myssv Das Problem ist, dass bei Dir auf die Anfrage von iobroker anscheinend vom DNS-Server eine IPv6-Adresse kommt, mit der Dein iobroker aber eben nix anfangen kann, da er nur IPv4 spricht (sprechen darf, da Du ihm ja IPv6 partout abdrehen willst). Warum da von Deinem DNS-Server (den ich nicht kenne) eine IPv6 kommt und keine IPv4 weiss ich nicht. Dein Netzwerk hast ja Du konfiguriert und nicht ich. Aber, wenn ein Netzwerk sauber konfiguriert ist, dann funktioniert das wunderbar. Und, wenn man es partout will, dann lässt sich auch ein Netzwerk mit IPv4-only sauber konfigurieren. Das fängt dann aber bereits beim Router an, dass man bei diesem IPv6 deaktiviert, so dass er sich erst gar keine IPv6-Präfixe holt. Der DHCP-Server darf dann auch keine IPv6-Präfixe oder Adressen von sich aus verteilen. Der DNS-Server darf auf Anfragen nur mit IPv4 antworten, bzw. wird das dann auch tun, da er auch keine IPv6 kennt.
Vermutlich hast Du IPv4 und IPv6 laufen und nutzt es nur nicht bewusst. Also im Router aktiviert, wenn der Router auch als DHCP-Server und DNS läuft (Fritzbox?) dann laufen auch diese zwei Komponenten mit IPv6. Dann drehst Du aber irgendeinem Gerät in Deinem Netzwerk IPv6 „mit Gewalt“ ab und erwartest, dass dennoch alles funktioniert? Da kann Dir keiner helfen, die Konfiguration Deines Netzwerks musst Du selber vornehmen, aber eben sauber. Das ist eben das, was @Thomas-Braun so treffend mit kaputtkonfiguriert meinte.

Schalte entweder überall IPv6 aus oder schalte es überall ein und lebe mit den Vorteilen. Es gibt keine Nachteile durch IPv6. Und IPv4 und IPv6 laufen wunderbar parallel und stören sich in keinster Weise, sondern ergänzen sich bravurös, wenn alles sauber konfiguriert ist. Aber so halbe Sachen machen halt nur Probleme, wie man sieht.

Gruss, Jürgen

myssv

@wildbill sagte in BackItUp Update hängt:

Vermutlich hast Du IPv4 und IPv6 laufen und nutzt es nur nicht bewusst. Also im Router aktiviert, wenn der Router auch als DHCP-Server und DNS läuft (Fritzbox?) dann laufen auch diese zwei Komponenten mit IPv6.

Vermutlich?

Mit Sicherheit nicht !!

Sowohl in der FritzBox

Als auch im Adguard

Der Adguard ist der einzige DNS-Server im Netz! (für IPv4)

Aber lassen wir es jetzt gut sein. Da bis auf den ioBroker alles (in meinen Augen) sauber funktioniert und ich keine sonstigen Probleme habe, werde ich mit meinen Workaround von oben leben und alles ist gut. Legt Eure Glaskugeln zurück und dgenießt den Abend!

Wildbill

@myssv Wie gesagt. In der heutigen zeit sollte man IPv6 einfach aktivieren und gut. Es gibt Seiten, die sind nur noch per IPv6 erreichbar, in Mobilfunknetzen hat man das standardmäßig und bekommt da schon keine IPv4 mehr. Es gibt einfach keinen (für mich nachvollziehbaren) Grund, es bewusst zu deaktivieren. Wenn Du es in der Fritzbox und im Adguard aktivierst hast Du vermutlich alle Deine Probleme bei iobroker sofort behoben.
Aber lebe, wie Du magst und genieße das Leben.
Schönen Abend noch.

Gruss, Jürgen

myssv

So, ich habe nun mal IPv6 im Netz aktiviert und es scheint auch auf dem ioBroker zu laufen, wie ein Ping zeigt:

Volker@ioBroker:~$ ping rtl.de
PING rtl.de (194.36.43.29) 56(84) bytes of data.
64 bytes from ip-194-36-43-29.ips.cbc.de (194.36.43.29): icmp_seq=1 ttl=248 time=12.4 ms
64 bytes from ip-194-36-43-29.ips.cbc.de (194.36.43.29): icmp_seq=2 ttl=248 time=12.0 ms
64 bytes from ip-194-36-43-29.ips.cbc.de (194.36.43.29): icmp_seq=3 ttl=248 time=12.0 ms
64 bytes from ip-194-36-43-29.ips.cbc.de (194.36.43.29): icmp_seq=4 ttl=248 time=12.1 ms
64 bytes from ip-194-36-43-29.ips.cbc.de (194.36.43.29): icmp_seq=5 ttl=248 time=12.2 ms
^C
--- rtl.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms

Ein Ping auf einen anderen Rechner im Netz läuft auch über IPv6:

Volker@ioBroker:~$ ping pc9999
PING pc9999(PC9999.fritz.box (2a11:fb80:1025:6500:507d:4f4e:218a:2c20)) 56 data bytes
64 bytes from PC9999.fritz.box (2a11:fb80:1025:6500:507d:4f4e:218a:2c20): icmp_seq=1 ttl=64 time=0.849 ms
64 bytes from PC9999.fritz.box (2a11:fb80:1025:6500:507d:4f4e:218a:2c20): icmp_seq=2 ttl=64 time=0.504 ms
64 bytes from PC9999.fritz.box (2a11:fb80:1025:6500:507d:4f4e:218a:2c20): icmp_seq=3 ttl=64 time=0.433 ms
^C
--- pc9999 ping statistics ---

Beim Updaten hängt er aber immer noch:

Volker@ioBroker:~$ iob upgrade ws@2.5.8 --debug 
Would you like to reinstall version 2.5.8 of ws now? [(y)es, (n)o]: y
Update ws from @2.5.8 to @2.5.8
NPM version: 9.8.1
Installing iobroker.ws@2.5.8... (System call)

Marc Berg

@myssv sagte in BackItUp Update hängt:

Ein Ping auf einen anderen Rechner im Netz läuft auch über IPv6:

mach mal ein IPv6 Ping auf einen externen Server

ping -6 heise.de

oder

ping -6 registry.npmjs.org

myssv

@marc-berg ok da hängt er

Volker@ioBroker:~$ ping heise.de
PING heise.de(redirector.heise.de (2a02:2e0:3fe:1001:302::)) 56 data bytes

bei IPv4 würde ich sagen: Gateway nicht vorhanden, bei IPv6 habe ich keine Ahnung .....

Marc Berg

@myssv sagte in BackItUp Update hängt:

bei IPv4 würde ich sagen: Gateway nicht vorhanden, bei IPv6 habe ich keine Ahnung

Es bleibt leider dabei, deine IPv6 Kommunikation läuft nicht.

Auf einem normalen Betriebssystem könnte man die IPv4 Kommunikation noch priorisieren, ob das bei einem LXC funktioniert, weiß ich nicht.
Ist aber alles Gefrickel und Doktern an Symptomen statt Ursachen.

Edit: Irreführendes gelöscht.

myssv

@marc-berg sagte in BackItUp Update hängt:

Es bleibt leider dabei, deine IPv6 Kommunikation läuft nicht.

Da gab es bisher ja auch überhaupt keine Notwendigkeit für. Es war alles sauber auf IPv4 und es lief auch alles bisher.

Community Forum

NEWS

BackItUp Update hängt

Support us

770

32.4k

81.5k

1.3m