LyDjane Posted October 7, 2022 Share Posted October 7, 2022 (edited) Guten Morgen zusammen, ich hatte in der Vergangenheit immer mal wieder Probleme, dass nach dem Start des PC ich nicht auf die Freigaben gekommen bin (welche im PC eingebunden sind) und auch unRAID sowie meine Docker nicht via Webbrowser aufrufen konnte. Weiterhin konnte ich den Server auch nicht via ping erreichen. Es gab immer die Fehlermeldung "Zeitüberschreitung". Nachdem ich den PC neu starte oder einfach eine Zeit X gewartet habe, funktionierte es plötzlich wieder problemlos. Heute habe ich an einem Docker gearbeitet und wurde plötzlich wieder "ausgesperrt". Sowohl mit dem Handy als auch mit dem Tablet erreiche ich alles problemlos. Folgendes habe ich nun in den Logs entdeckt: Oct 7 10:22:50 unRAID-Server avahi-daemon[13014]: New relevant interface veth77cad04.IPv6 for mDNS. Oct 7 10:22:50 unRAID-Server avahi-daemon[13014]: Registering new address record for XXXX::XXXX:XXXX:feb2:864c on veth77cad04.*. Oct 7 10:23:54 unRAID-Server vsftpd[29474]: connect from XXX.XXX.XXX.49 (XXX.XXX.XXX.49) Oct 7 10:23:54 unRAID-Server vsftpd[29474]: [root] OK LOGIN: Client "XXX.XXX.XXX.49" Oct 7 10:24:20 unRAID-Server kernel: veth64c6cd8: renamed from eth0 Oct 7 10:24:20 unRAID-Server kernel: docker0: port 10(veth77cad04) entered disabled state Oct 7 10:24:20 unRAID-Server avahi-daemon[13014]: Interface veth77cad04.IPv6 no longer relevant for mDNS. Oct 7 10:24:20 unRAID-Server avahi-daemon[13014]: Leaving mDNS multicast group on interface veth77cad04.IPv6 with address XXXX::XXXX:XXXX:feb2:864c. Oct 7 10:24:20 unRAID-Server kernel: docker0: port 10(veth77cad04) entered disabled state Oct 7 10:24:20 unRAID-Server kernel: device veth77cad04 left promiscuous mode Oct 7 10:24:20 unRAID-Server kernel: docker0: port 10(veth77cad04) entered disabled state Oct 7 10:24:20 unRAID-Server avahi-daemon[13014]: Withdrawing address record for XXXX::XXXX:XXXX:feb2:864c on veth77cad04. Oct 7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered blocking state Oct 7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state Oct 7 10:24:28 unRAID-Server kernel: device vetha188847 entered promiscuous mode Oct 7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered blocking state Oct 7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered forwarding state Oct 7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state Oct 7 10:24:29 unRAID-Server kernel: eth0: renamed from veth90b18bf Oct 7 10:24:29 unRAID-Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha188847: link becomes ready Oct 7 10:24:29 unRAID-Server kernel: docker0: port 10(vetha188847) entered blocking state Oct 7 10:24:29 unRAID-Server kernel: docker0: port 10(vetha188847) entered forwarding state Oct 7 10:24:31 unRAID-Server avahi-daemon[13014]: Joining mDNS multicast group on interface vetha188847.IPv6 with address XXXX::XXXX:XXX:fef1:e898. Oct 7 10:24:31 unRAID-Server avahi-daemon[13014]: New relevant interface vetha188847.IPv6 for mDNS. Oct 7 10:24:31 unRAID-Server avahi-daemon[13014]: Registering new address record for XXXX::XXXX:XXX:fef1:e898 on vetha188847.*. Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state Oct 7 10:26:03 unRAID-Server kernel: veth90b18bf: renamed from eth0 Oct 7 10:26:03 unRAID-Server avahi-daemon[13014]: Interface vetha188847.IPv6 no longer relevant for mDNS. Oct 7 10:26:03 unRAID-Server avahi-daemon[13014]: Leaving mDNS multicast group on interface vetha188847.IPv6 with address XXXX::XXXX:XXX:fef1:e898. Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state Oct 7 10:26:03 unRAID-Server kernel: device vetha188847 left promiscuous mode Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state Oct 7 10:26:03 unRAID-Server avahi-daemon[13014]: Withdrawing address record for XXXX::XXXX:XXX:fef1:e898 on vetha188847. Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered blocking state Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state Oct 7 10:26:03 unRAID-Server kernel: device veth2984986 entered promiscuous mode Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered blocking state Oct 7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered forwarding state Oct 7 10:26:03 unRAID-Server kernel: eth0: renamed from veth6ea744c Oct 7 10:26:03 unRAID-Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2984986: link becomes ready Oct 7 10:26:05 unRAID-Server avahi-daemon[13014]: Joining mDNS multicast group on interface veth2984986.IPv6 with address XXXX::XXXX:XXXX:XXXX:d0c8. Oct 7 10:26:05 unRAID-Server avahi-daemon[13014]: New relevant interface veth2984986.IPv6 for mDNS. Oct 7 10:26:05 unRAID-Server avahi-daemon[13014]: Registering new address record for XXXX::XXXX:XXXX:XXXX:d0c8 on veth2984986.*. Oct 7 10:26:34 unRAID-Server kernel: veth6ea744c: renamed from eth0 Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state Oct 7 10:26:34 unRAID-Server avahi-daemon[13014]: Interface veth2984986.IPv6 no longer relevant for mDNS. Oct 7 10:26:34 unRAID-Server avahi-daemon[13014]: Leaving mDNS multicast group on interface veth2984986.IPv6 with address XXXX::XXXX:XXXX:XXXX:d0c8. Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state Oct 7 10:26:34 unRAID-Server kernel: device veth2984986 left promiscuous mode Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state Oct 7 10:26:34 unRAID-Server avahi-daemon[13014]: Withdrawing address record for XXXX::XXXX:XXXX:XXXX:d0c8 on veth2984986. Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered blocking state Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered disabled state Oct 7 10:26:34 unRAID-Server kernel: device vethcbac438 entered promiscuous mode Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered blocking state Oct 7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered forwarding state Oct 7 10:26:34 unRAID-Server kernel: eth0: renamed from vethf54458d unter Port 10 vom Docker läuft Heimdall (https://hub.docker.com/r/linuxserver/heimdall). Entsteht der Fehler durch diesen Docker? Und wenn ja wieso sperrt er mich aus? Die IP von meinem PC ist immer die gleiche, wieso klappt es nach einem Neustart sofort problemlos? Viele Grüße und vielen Dank vorab! Edited October 7, 2022 by LyDjane Quote Link to comment
mgutt Posted October 7, 2022 Share Posted October 7, 2022 In welchem Netzwerk läuft heimdall? Das ständige "entered disabled state" ist nicht normal. Kannst du Netzwerkprobleme ansonsten ausschließen? Gibt es Drops / Error bei der Ausgabe von ifconfig? Quote Link to comment
LyDjane Posted November 13, 2022 Author Share Posted November 13, 2022 (edited) Sorry für die späte Rückmeldung, ich war selbst sehr lange noch auf der Suche nach dem Fehler, aber bin mit meinem Latein am Ende. Folgendes habe ich herausfinden können in der Zwischenzeit: mein ESET meldet regelmäßig, dass im Netzwerk eine IP-Adresse doppelt vergeben ist. die doppelte IP-Adresse stammt anscheinend vom unRAID-Server (Screenshot aus der Frizbox) der unRAID-Server selbst hat in den Netzwerkeinstellungen die MAC-Adresse XYZ, diese stimmt auch mit der in der Fritzbox unter unRAID-Server überein. die IP-Adresse .41 (also die zweite) hat allerdings eine völlig andere MAC-Adresse, die ich nicht zuordnen kann. Ich bin alle Docker durchgegangen, welche auf dem unRAID-Server laufen und habe die MAC Adressen kontrolliert, es ist kein Docker. Ich habe zur Vorsicht auch alle Docker deaktiviert und dann die Fritzbox neu gestartet, ohne einen laufenden Docker war die doppelte IP-Adresse trotzdem wieder vorhanden. In der Fritzbox ist der unRAID-Server als statisch mit der .41 hinterlegt. In den unRAID Einstellungen als "automatisch". Die zweite .41 IP-Adresse kann ich auch nicht auf eine andere ändern in der Fritzbox. Viele Grüße Edited November 13, 2022 by LyDjane Quote Link to comment
alturismo Posted November 13, 2022 Share Posted November 13, 2022 13 minutes ago, LyDjane said: die doppelte IP-Adresse stammt anscheinend vom unRAID-Server (Screenshot aus der Frizbox) wenn du host access in den docker Einstellungen aktiviert hast, ist der doppelte Eintrag normal und kein Fehler. dann wäre noch zu beachten, wie dein docker Netzwerk setup steht macvlan verträgt die Fritz ipvlan nicht ... da spielt alles verrückt wegen den mac adressen Quote Link to comment
mgutt Posted November 13, 2022 Share Posted November 13, 2022 4 minutes ago, alturismo said: macvlan verträgt die Fritz ipvlan nicht Gilt das auch für die Laborversion? Ich habe jetzt mittlerweile die, weil mir diverse Bugs rund um IPv6 und VPN Tunnel auf den Keks gegangen sind. Jetzt bin ich wieder zufrieden. Quote Link to comment
LyDjane Posted November 13, 2022 Author Share Posted November 13, 2022 53 minutes ago, alturismo said: Einstellungen sind bei mir exakt genau so. Heißt die zweite "IP" ist der Docker Host access dann an der Stelle? Danke!! Quote Link to comment
alturismo Posted November 13, 2022 Share Posted November 13, 2022 2 minutes ago, LyDjane said: Heißt die zweite "IP" ist der Docker Host access dann an der Stelle? genau so in etwa schalte den host access aus und der 2. Eintrag (shim bridge) ist inaktiv. 53 minutes ago, mgutt said: Gilt das auch für die Laborversion? Ich habe jetzt mittlerweile die, weil mir diverse Bugs rund um IPv6 und VPN Tunnel auf den Keks gegangen sind. Jetzt bin ich wieder zufrieden. sprich, du hast es getestet und die Geräte "springen" nicht mehr wild umher oder war die Frage an mich gemünzt ob ich das nochmals getestet habe ? wenn, Nope, den Spaß tue ich mir nicht mehr an da ich mit macvlan keine Probleme habe ... und ja, ich hab die labor drauf nur wie geschrieben, danach wieder alles sauber zuordnen macht mir keinen Spaß 1 Quote Link to comment
mgutt Posted November 13, 2022 Share Posted November 13, 2022 3 hours ago, alturismo said: ob ich das nochmals getestet habe ? Ja, weil ich hab alles als Bridge laufen. Daher weiß ich es auch nicht, ob es mittlerweile geht. 1 Quote Link to comment
alturismo Posted November 13, 2022 Share Posted November 13, 2022 in einer ruhigen Minute mache ich das mal, aber heute nicht mehr ... und ich glaube auch eher das ist "by design" ... da dann alles die gleiche mac hat ... und dazu habe ich auch nichts im changelog der Fritz Labor gesehen. Quote Link to comment
LyDjane Posted November 13, 2022 Author Share Posted November 13, 2022 4 hours ago, alturismo said: 4 hours ago, LyDjane said: Heißt die zweite "IP" ist der Docker Host access dann an der Stelle? genau so in etwa schalte den host access aus und der 2. Eintrag (shim bridge) ist inaktiv. Bedeutet aber auch, dass die Docker die als "host" laufen, dann nicht mehr funktionieren? Quote Link to comment
alturismo Posted November 13, 2022 Share Posted November 13, 2022 11 minutes ago, LyDjane said: Bedeutet aber auch, dass die Docker die als "host" laufen, dann nicht mehr funktionieren? wieso, das hat nichts damit zu tun ... und host würde ich eh vermeiden, aber wie gesagt, shim br0 (docker host access) hat nichts mit docker host zu tun und dadurch ist auch der 2. Eintrag in der Fritz normal. ich wollte damit nur klar machen dass dies nicht das Problem ist wenn ... Quote Link to comment
HGWBLN Posted May 16, 2023 Share Posted May 16, 2023 On 11/13/2022 at 1:17 PM, alturismo said: macvlan verträgt die Fritz ipvlan nicht ... da spielt alles verrückt wegen den mac adressen Moin zusammen, ich weiß nicht ob ihr mittlerweile ipvlan mit einer Fritzbix ausprobiert habt, aber ich habe eine FRITZ!Box 6591 Cable von Vodafone und nutze damit ipvlan. Ich hatte in Unraid bis vor kurzem macvlan in den Dockereinstellungen. Ich habe 6 Dockercontainer, jeder hat seine eigene feste IP-Adresse bekommen. Dann gab es vor ein paar Tagen eine Warnung in Unraid, dass ich lieber ipvlan verwenden soll. Warum weiß ich leider nicht mehr genau. Ich habe daher auf ipvlan umgestellt. In den Dockercontainer selbst habe ich nichts geändert, alle haben ihre jeweiligen IP-Adressen behalten. Ergebnis: Ich kann weiterhin alle Dockercontainer via IP-Adresse erreichen. Der einzige Unterschied ist, dass ich die IP-Adressen der Dockercontainer nicht mehr in er Fritzbox sehen kann, was mit macvlan vorher der Fall war. Ansonsten kann ich bisher nichts negatives berichten. Als FritzOS nutze ich Version 07.29 Quote Link to comment
alturismo Posted May 16, 2023 Share Posted May 16, 2023 9 hours ago, HGWBLN said: Ergebnis: Ich kann weiterhin alle Dockercontainer via IP-Adresse erreichen. Der einzige Unterschied ist, dass ich die IP-Adressen der Dockercontainer nicht mehr in er Fritzbox sehen kann, was mit macvlan vorher der Fall war. Ansonsten kann ich bisher nichts negatives berichten. Als FritzOS nutze ich Version 07.29 dann hoffe dass dies so bleibt IP Adressen ... jetzt haben alle Geräte (Dockers im IPVlan) die gleiche mac Adresse und damit hat die Fritz Probleme, bei mir sah ich alle geräte, jedoch "sprangen" die wild durch ... Beispiel, swag hat die IP 192.168.1.80, guacamole .....90, usw ... mit IPVLAN springen die jetzt durch weil die Fritz unter der mac alle anspricht, mal geht etwas, mal dauert es etwas länger da ja die IP gerade wohin auch immer will ... ich schätze du wirst es merken wenn es ab und an etwas dauert bis sich ein webui eines Dockers öffnet, oder du aktualiseren müsstest usw usw ... Nachfrage bei AVM ergab auch dass dies klar ist und seitens AVM jetzt aber auch keine Änderung geben wird, was ich verstehe ... die bauen auf mac und da ist 1 x mac für xxx Geräte nun mal nicht förderlich ... ich hatte dies auch mit der 7.29 getestet und einmalig noch mit einer 7.39 Labor (heute 7.5). Ebenfalls auf einer 6591 und einer 6660, denke bei einem Neustart Router, Server, Docker ... kann es passieren das dann nicht mehr alles so wirklich will, nur dann bitte zuerst ipvlan deaktivieren bevor hier Anfragen dazu kommen ... 1 Quote Link to comment
HGWBLN Posted May 16, 2023 Share Posted May 16, 2023 Wäre es dann aber nicht sinnvoll bei macvaln zu bleiben? Wie gesagt, hatte ich das dursprünglich auch, bis Unraid selber meinte, ich solle lieber ipvlan verwenden. Quote Link to comment
alturismo Posted May 17, 2023 Share Posted May 17, 2023 8 hours ago, HGWBLN said: Wäre es dann aber nicht sinnvoll bei macvaln zu bleiben? Wie gesagt, hatte ich das dursprünglich auch, bis Unraid selber meinte, ich solle lieber ipvlan verwenden. Limetech ist sich bewusst dass dies kritisch ist ... daher die Empfehlung zu IPVlan zu wechseln "wo es geht" ... Fritz ist halt ein Szenario wo es nicht so toll ist ... und es gibt sicherlich noch mehr Szenarien kannst Dich ja hier mal einlesen ... mit 6.12 war/ist aktuell hier halt Ende mit macvlan ... https://forums.unraid.net/bug-reports/prereleases/6120-rc4-macvlan-call-traces-found-but-not-on-r2379/page/3/?tab=comments#comment-23852 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.