Unitymedia Finde mein NAS nicht im Heimnetz nach Umstieg auf Um

[Tuxtom007]

@SpaceRat: wenn das deine Probleme mit ynetzkonfigs sind, tust mir leid für dich


Gesendet mit Tapatalk

 

[koax]

Insbesonders wenn Du statische IPs hast, kannst Du die ja einfach in /etc/hosts eintragen und bist fertig

Oder beispielsweise bei einer Fritzbox dort eintragen.

 

[SpaceRat]

Verlust der lokalen Namensauflösung

Das hat ja nun wirklich nichts mit DHCP oder nicht DHCP zu tun.

Äh, doch.

Ausgehend von den im Haushalt üblichen Routern basiert die lokale Namensauflösung nun einmal darauf, daß der DNS-Proxy die vorhandenen DHCP leases auswertet.
Wenn da keine sind, kann er auch keine auswerten.

Insbesonders wenn Du statische IPs hast, kannst Du die ja einfach in /etc/hosts eintragen und bist fertig

Top.
Da steht dann wohl das drin, was Du reingeschrieben hast und nicht unbedingt die Wahrheit, womit wir wieder beim Thema Fehleranfälligkeit wären.

• Geräte booten schneller
• Geräte booten mit ordentlicher Konfiguration, auch wenn keine Netzverbindung besteht
• Gerät ist problemlos im Netz erreichbar, wenn DHCP Server ausfällt/nicht verfügbar

1. Und wieder eine Millisekunde kostbare Lebenszeit gespart ... wenn's hochkommt.
Welches Gerät wartet in einem ansonsten benutzbaren Zustand blockierend auf ein DHCP lease?

Wenn ich "ifdown eth0 ; ifup eth0" auf der Konsole ausführe und vorher den DHCP-Server beende, dann kann ich diesen Vorgang sehen.
Ansonsten läuft er im Hintergrund ab, ob das 4,5 Sekunden oder 5,3 Sekunden nach Drücken des Power-Knopfs Erfolg hat wirkt sich auf die Bootzeit genau gar nicht aus.

Zu 2+3, letztendlich ja das selbe:
Windows ist da clever, es benutzt das letzte bekannte lease weiter.
Linux auch, allerdings nicht bei Reboot ... insofern ein halber Punkt für Dich.

Nur ein halber, weil
1. der Ausfall des DHCP-Servers in einem normalen Router extrem unwahrscheinlich ist
bzw.
2. das Fehlen des riesengroßen Internets in der Situation für die meisten Nutzer eh viel schwerer wiegt als einzelne Geräte im LAN, die auf ein neues Lease warten
und
3. schon die Kombination "Ausfall des DHCP-Servers" und "Neustart des Gerätes während der Ausfallphase" nötig ist.
und
4. das DHCP lease dann einfach nachbezogen wird, sobald der DHCP-Server wieder verfügbar ist, eine blöde Kombination aus "Neustart Router" + "Neustart Gerät X" hat also nicht wirklich ernsthafte Auswirkungen

Ansich ist die Diskussion aber nicht sinnvoll. Es gibt Szenarien und Anforderungen, die in jedem Netz vorliegen, und die definitiv Einfluss auf die Konfiguration haben sollten. Und gerade bei DHCP oder nicht gibt es ja auch noch Mischbetrieb. Mein Fileserver z.B. macht kein DHCP, alle mobilen Geräte logischerweise komplett.

Ich bin der Ansicht, daß es in Firmennetzen udgl. mit abgestellter IT-Abteilung (In e-technischen Normen heißt das "wirksame Überwachung") mit Sicherheit gute Gründe für statische IPs geben kann und geben wird.
Diese Gründe treffen aber erstens im privaten LAN eher selten zu und zweitens gibt es dort eben auch seltenst eine professionelle IT-Abteilung.
Normaluser sind einfach besser mit einer Lösung bedient, bei der sich die unwahrscheinlichen Probleme mit der Zeit, spätestens aber durch Neustart, von selber heilen, als mit einem Setup das zwar exotische Problemfälle ausschließt, dafür aber mehr als ein halbes Dutzend wahrscheinliche Probleme provoziert, bei denen eben dieser Normaluser dann den Wald vor lauter Bäumen nicht mehr sieht bzw. das ihm ansonsten das Leben schwer macht.

Die Existenz dieses Threads alleine untermauert meinen Standpunkt schon genug und es war nicht der erste dieser Art und es wird auch nicht der letzte sein.

 

[SpaceRat]

Insbesonders wenn Du statische IPs hast, kannst Du die ja einfach in /etc/hosts eintragen und bist fertig

Oder beispielsweise bei einer Fritzbox dort eintragen.

Eine solche Funktion hat die Fritz!Box nicht ... zumindest nicht ungefreetzt.

Was sie aber wohl hat ist "lease reservation" (Auch "DHCP reservation" oder "address reservation" genannt) und das hat heutzutage fast jeder Router für den Heimgebrauch (Unrühmliche Ausnahmen sind eigentlich nur die SpeedRotz-Reihe der Telekom (Sofern nicht von AVM stammend, aber das ist ja schon 'ne Weile her, daß die SpeedRotz von AVM kamen), die Hitron "Modemrouter" und der Technikkoller TC7200).

Im privaten Umfeld ist diese lease reservation statischen IPs eigentlich immer vorzuziehen:

• Die Geräte behalten dauerhaft ihre IP
• lokale Namensauflösung funktioniert
• die Geräte bleiben trotzdem "portabel"
• die IPs werden zentral verwaltet
• der DHCP-Server verhindert Kollisionen
• deutlich geringere Fehlerträchtigkeit, da nicht an x Geräten einzeln konfiguriert wird

 

[koax]

Insbesonders wenn Du statische IPs hast, kannst Du die ja einfach in /etc/hosts eintragen und bist fertig

Oder beispielsweise bei einer Fritzbox dort eintragen.

Eine solche Funktion hat die Fritz!Box nicht ... zumindest nicht ungefreetzt.

Nix Freetz. Meine 7490 hat die Funktion und wahrscheinlich doch auch andere.
Der mit statischer IP im Bereich Heimnetzwerk angezeigten Clients kann man über "Details" einen Namen zuweisen.

]Im privaten Umfeld ist diese lease reservation statischen IPs eigentlich immer vorzuziehen

Ich sehe schon: Du hast außerhalb Deiner gefreetzen Box noch nie versucht, einem Client auf diese Weise eine ganz bestimmte IP zu verpassen. Spiels mal im Web-Interface durch. Ich rede nicht von der festen Zuweisung der IP, die der Client ohnehin per DHCP bekommen hat sondern von einer Änderung auf eine gewünschte IP, die ich für ein bestimmtes Gerät gerne verwenden möchte und schon immer verwendet habe.

 

[SpaceRat]

Ich rede nicht von der festen Zuweisung der IP, die der Client ohnehin per DHCP bekommen hat sondern von einer Änderung auf eine gewünschte IP, die ich für ein bestimmtes Gerät gerne verwenden möchte und schon immer verwendet habe.

Das macht es aber nicht zu einer "statischen" IP.

Im sprachlichen Sinne zwar schon, aber im technischen Sinne stellt man "statische" IPs am Client ein und sonst nirgends.
Wovon Du redest sind immer noch "lease reservations" oder auf Deutsch "Adressreservierungen".

Und wie ich schon sagte: Das ist genau das, was ich fürs Heimnetz statt statischer IPs immer empfehlen würde.

 

[koax]

Ich rede nicht von der festen Zuweisung der IP, die der Client ohnehin per DHCP bekommen hat sondern von einer Änderung auf eine gewünschte IP, die ich für ein bestimmtes Gerät gerne verwenden möchte und schon immer verwendet habe.

Das macht es aber nicht zu einer "statischen" IP.

Wo habe ich das behauptet?
Es ist eine Antwort auf Deine Meinung, dass Adressreservierungen doch "so einfach" sind und meine Meinung, dass Du wahrscheinlich mit einer Fritzbox keine prakitschen Erfahrungen außerhalb Deiner Freetz-Umgebung hast.

Ich habe einzelnen Clients durchaus statische IPs vergeben, weil ich um die Nachteile der Adressreservierungen für bestimmte Zwecke weiß.

 

[SpaceRat]

Es ist eine Antwort auf Deine Meinung, dass Adressreservierungen doch "so einfach" sind

Sind sie ja auch.

Vor allem kann man damit viele Fehler vermeiden.

meine Meinung, dass Du wahrscheinlich mit einer Fritzbox keine prakitschen Erfahrungen außerhalb Deiner Freetz-Umgebung hast.

Die meisten Fritz!Boxen mit denen ich noch zu tun habe sind ungefreetzt.

Ich habe einzelnen Clients durchaus statische IPs vergeben, weil ich um die Nachteile der Adressreservierungen für bestimmte Zwecke weiß.

Bleibt Dir unbenommen.
Genauso wie es mir unbenommen bleibt, davon nix zu halten.

Ich verwende auf keinem einzigen Gerät statische IPs und dennoch habe ich umgekehrt auch kein einziges Gerät, das seine IP wechselt.
Da bin ich neurotisch, ich will einfach nicht, daß ein Smartphone auf einmal zwischen meinen VMs auftaucht oder ein Receiver zwischen den PCs, ...

 

[tq1199]

Der mit statischer IP im Bereich Heimnetzwerk angezeigten Clients kann man über "Details" einen Namen zuweisen.

Ja, aber damit funktioniert mit meiner FB6360-cable (FW 6.50) noch keine lokale Namensauflösung mit dem DNS-Server der FB6360.

Erst wenn ich mit nsupdate (oder gleichwertig) den Namen update, ist die lokale Namensauflösung möglich.

EDIT:

BTW: ... und bei den (statischen bzw. nicht statischen) IPv6-Adressen der Clients im (W)LAN der FritzBox, geht es auch mit DHCP(v6) nicht. Da muss ich auch ein externes "DNS update utility" verwenden.

 

[tq1199]

Windows ist da clever, es benutzt das letzte bekannte lease weiter.
Linux auch, allerdings nicht bei Reboot ...

Doch Linux kann das auch, mit dem letzten bekannten lease, bei Reboot. Z. B.:

<i>
</i>-y, --reboot seconds Allow reboot seconds before moving to the discover phase, if we have an old lease, to use.

 

[tq1199]

[*] Geräte booten mit ordentlicher Konfiguration, auch wenn keine Netzverbindung besteht
[*] Gerät ist problemlos im Netz erreichbar, wenn DHCP Server ausfällt/nicht verfügbar[/list]

Es gibt (inzwischen) dhcp-Clients bei denen man ein fallback-Profil konfigurieren kann. D. h., wenn der dhcp-Client den dhcp-Server nicht erreichen kann, dann weist der dhcp-Client dem Interface (Gerät) eine (konfigurierbare, von außerhalb des DHCP-Pools) feste IP-Adresse zu. Damit ist das Gerät auch immer im Netz erreichbar.

 

[SpaceRat]

BTW: ... und bei den (statischen bzw. nicht statischen) IPv6-Adressen der Clients im (W)LAN der FritzBox, geht es auch mit DHCP(v6) nicht. Da muss ich auch ein externes "DNS update utility" verwenden.

Da stimmt aber was nicht.

Ebenfalls eine Fritz!Box 6360 bei Unitymedia, ebenfalls 6.50:

root@RaspberryPi ~ # host vuduo2
vuduo2.fritz.box has address 192.168.3.15
vuduo2.fritz.box has IPv6 address 2001:db8:1234:fedc:21d:ecff:fe05:5678
vuduo2.fritz.box has IPv6 address fd02:abcd:ef09:c0c0:21d:ecff:fe05:5678

Und umgekehrt auf der Vu+ Duo²:

root@vuduo2:~# nslookup RaspberryPi
Server: 192.168.3.1
Address 1: 192.168.3.1 fritz.box
Name: RaspberryPi
Address 1: fd02:abcd:ef09:c0c0:ba27:ebff:fea6:6789 RaspberryPi.fritz.box
Address 2: 2001:db8:1234:fedc:ba27:ebff:fea6:6789 RaspberryPi.fritz.box
Address 3: 192.168.3.10 RaspberryPi.fritz.box

 

[tq1199]

BTW: ... und bei den (statischen bzw. nicht statischen) IPv6-Adressen der Clients im (W)LAN der FritzBox, geht es auch mit DHCP(v6) nicht. Da muss ich auch ein externes "DNS update utility" verwenden.

Da stimmt aber was nicht.

Ebenfalls eine Fritz!Box 6360 bei Unitymedia, ebenfalls 6.50:

Ja, da stimmt etwas nicht. Aber was, stimmt nicht?

Hast Du in deiner FB6360 (support-Datei) betr. deinen Raspi, bei den landevices, auch diese Einstellung/Konfiguration für " staticlease = yes;"? Z. B.:

<i>
</i>{ ip = 192.168.178.43; name = "raspberrypi"; neighbour_name = "raspberrypi"; mac = B8:27:EB:##:##:##; auto_etherwake = no; ifaceid = ::ba27:ebff:fe##:####; staticlease = yes; ipv6firewall { enabled = yes; exposed_host = no; ping6_allowed = yes; rules = "UDP xxxxx-yyyyy"; }

und in der Section "dns-server:", nur bei den IPv6-Adressen des Raspi, auch die Ergänzung "(dynamic)"? Z. B.:

<i>
</i>raspberrypi.fritz.box (none): 192.168.178.43 fe80::ba27:ebff:fe##:#### (dynamic) 2###:####:####::ba27:ebff:fe##:#### (dynamic)

 

[SpaceRat]

Ja, da stimmt etwas nicht. Aber was, stimmt nicht?

Hast Du in deiner FB6360 (support-Datei) betr. deinen Raspi, bei den landevices, auch diese Einstellung/Konfiguration für " staticlease = yes;"? Z. B.:

 } { ip = 192.168.3.10; name = "RaspberryPi"; neighbour_name = "RaspberryPi"; mac = B8:27:EB:A6:56:78; auto_etherwake = no; ifaceid = ::ba27:ebff:fea6:5678; staticlease = yes; ipv4forwardrules = "# tcp 0.0.0.0:54090 192.168.3.10:54090 0 # Blah-Pi"; ipv6firewall { enabled = yes; exposed_host = no; ping6_allowed = yes; rules = "TCP 54090", "TCP 22"; } allow_pcp_and_upnp = no; } {

Sieht ziemlich ähnlich aus.

und in der Section "dns-server:", nur bei den IPv6-Adressen des Raspi, auch die Ergänzung "(dynamic)"?

Ja, aber ich habe was anderes...

Achte mal auf das "none" bei Dir und was da bei mir steht:
raspberrypi.fritz.box (none):

Nun bei mir (Die Adressen habe ich direkt weggelassen, weil irrelevant):
RaspverryPi.fritz.box (mdns):
vuduo2.fritz.box (mdns):
DESKTOP-BSBJSEM.fritz.box (llmnr):
DESKTOP-BSBJSEM-2.fritz.box (mdns):
iPad.fritz.box (mdns):
iPhone-2.fritz.box (mdns):
NAS.fritz.box (none):

Zur Klarstellung: Das ist die Fritz!Box eines Bekannten! Ich habe keinen kleinen Pim... und dementsprechend kein einziges CrApple-Gerät!

Ich hab's vorher nie über die Support-Datei nachgewiesen, aber gewußt habe ich es schon lange:
Die IPv6-Namensauflösung mit der Fritz!Box klappt am zuverlässigsten, wenn auf dem Client avahi-daemon (Linux zeroconf), Bumsoir (CrApple zeroconf) oder llmnrd (Windows zeroconf) läuft.

Der Grund liegt darin, daß ja eben kein DHCP(v6) zum Tragen kommt, sondern SLAAC/zustandslose Adress-Autokonfiguration.
Der Router (Die Fritz!Box) advertised das Präfix, die Geräte konfigurieren sich selbst und das war's, eigentlich kann die Fritz!Box überhaupt nicht wissen, mit welcher IPv6 die Geräte sich konfiguriert haben.

DNSMasq nutzt an dieser Stelle für solche Clients für die es auch eine IPv4-Adressreservierung gibt einen Trick und errechnet einfach selber die IPv6, die das Gerät sich ohne Bullshit Extensions zulegen würde. Wann immer sich ein solches Gerät dann per DHCPv4 ein neues Lease zulegt überprüft DNSMasq, ob sich der Client diese spekulative IPv6 tatsächlich zugelegt hat.
Das klappt natürlich wirklich nur ohne Bullshit Extensions.

Die Fritz!Box ist da offensichtlich etwas cleverer und verknüpft auch die Informationen aus mDNS- (avahi/bumsoir) und llmnr- (Windows) Broadcasts mit den gespeicherten Hosts.

Und tatsächlich ging für das Gerät "NAS" zum Zeitpunkt der Erstellung keine IPv6-Namensauflösung ...

root@RaspberryPi ~ # host nas
nas.fritz.box has address 192.168.3.16

... aber kaum habe ich dort den avahi-daemon umkonfiguriert (Publishing war deaktiviert):

root@RaspberryPi ~ # host nas
nas.fritz.box has address 192.168.3.16
nas.fritz.box has IPv6 address 2001:db8:1234:fedc:290:a9ff:fe37:cdef
nas.fritz.box has IPv6 address fd02:abcd:ef09:c0c0:290:a9ff:fe37:cdef

An anderer Stelle ist die Fritz!Box nämlich dümmer als DNSMasq:
Sie wendet zwar ebenfalls das Verfahren "Berechnen und Überprüfen der IPv6 ohne Bullshit Extensions" an, vergißt das aber nach einer gewissen Zeit wieder, wenn das Gerät nicht immer wieder ausgehenden Traffic verursacht, was ein NAS ja besser nicht tut.


Langer Rede, kurzer Sinn:
Wenn auch die lokale Namensauflösung für IPv6 störungsfrei klappen soll, sollten die Linux-Clients den avahi-daemon laufen haben.

 

[F-orced-customer]

... aber kaum habe ich dort den avahi-daemon umkonfiguriert (Publishing war deaktiviert):

man avahi-daemon.conf

SECTION [PUBLISH]
disable-publishing= Takes a boolean value ("yes" or "no"). If set to "yes", no record will be published by Avahi, not even address records for the local host. Avahi will be started in a querying-only mode. Use this is a security measure. This option defaults to "no"

? :kratz:

 

[SpaceRat]

... aber kaum habe ich dort den avahi-daemon umkonfiguriert (Publishing war deaktiviert):

man avahi-daemon.conf

SECTION [PUBLISH]
disable-publishing= Takes a boolean value ("yes" or "no"). If set to "yes", no record will be published by Avahi, not even address records for the local host. Avahi will be started in a querying-only mode. Use this is a security measure. This option defaults to "no"

? :kratz:

Aber was avahi ist/macht, ist Dir schon klar?
Ohne Publishing kannste den eigentlich auch gleich wieder deinstallieren (Deshalb ist ja auch der default "no").

Der avahi-daemon teilt der Broadcast-/Multicast-Domäne mit "Hallo, hier bin ich, ich bin $IPv4 bzw. $IPv6, und ich kann $(Liste der zu veröffentlichenden Dienste)".
Erst avahi/Bumsoir bzw. LLMNR/WS-D ermöglichen es einem Client heutzutage, Netzwerkfreigaben, Netzwerkdrucker, Netzwerkscanner, usw. usf. schmerzlos aufzufinden.

Publishing auszuschalten ist für ein Gerät im LAN völlig sinnleer, denn wenn alle Geräte nur noch im "querying-only"-Modus laufen, dann gibt es nix mehr zu querien ...
... in einem fremden Netz (Stichwort: Smartphone/Tablet im offenen WLAN) hingegen macht das Sinn.

Der Grund, wieso das auf dem NAS ausgeschaltet war, war oder ist schlichtweg der, daß da noch ein zweiter mDNS/Zeroconf-Daemon läuft, der eigentlich für's Publishing zuständig ist, aber der macht kein IPv6.
Das ist so ein mittelaltes WD NAS, das kann "schon" IPv6 im Kernel, im Samba, im SSH, usw., nur im Apache ist es kaputtkonfiguriert.

Ach ja: In Debian, Raspbian und Ubuntu ist Publishing auch standardmäßig AN.

 

[F-orced-customer]

Jo, ist auch in meinem Posting default oder was wolltest Du mir sagen?

 

[SpaceRat]

Jo, ist auch in meinem Posting default oder was wolltest Du mir sagen?

Du hattest "security" fett markiert, so als hätte ich soeben verkündet, daß ich einen SMB-Server einfach so in ein öffentliches WLAN gehängt und ihn über alle erdenklichen Wege dies auch mitteilen gelassen hätte.

 

[F-orced-customer]

Ich dachte dabei an einen Fehler in der manpage von jessie.

 

[Andreas1969]

:kiss:

 

[SpaceRat]

Ich dachte dabei an einen Fehler in der manpage von jessie.

Wieso?

Es ist ja auch richtig, nur eben im eigenen LAN sinnfrei.

 

[tq1199]

Der Grund liegt darin, daß ja eben kein DHCP(v6) zum Tragen kommt, sondern SLAAC/zustandslose Adress-Autokonfiguration.
Der Router (Die Fritz!Box) advertised das Präfix, die Geräte konfigurieren sich selbst und das war's, eigentlich kann die Fritz!Box überhaupt nicht wissen, mit welcher IPv6 die Geräte sich konfiguriert haben.

Nein, das ist falsch und das war's nicht. Die FritzBox weiß ganz genau mit welchen IPv6-Adressen sich die Geräte konfiguriert haben, denn unter Heimnetzwerk (Details) in der FB, werden diese IPv6-Adressen die das Gerät (dhcpcd) mit:

<i>
</i>slaac hwaddr

generiert/konfiguriert hat, auch angezeigt. Der dhcpcd des Raspi teilt der FritzBox diese generierten IPv6-Adressen mit. Das kann man z, B, mit:

<i>
</i>sudo tcpdump -vvveni <Interface> udp portrange 546-547
sudo systemctl restart dhcpcd

anzeigen lassen bzw. sehen. D. h. ein "dhcp6 confirm" vom Client (hier der Raspi) und ein "dhcp6 reply" von der FritzBox.

Mit:

<i>
</i>sudo tcpdump -vvveni <Interface> icmp6
sudo ndptool -v -i <Interface> monitor
sudo systemctl restart dhcpcd

, kann man auch das "router solicitation" des dhcpcd (Raspi) und das "router advertisement" der FritzBox, anzeigen lassen.

Langer Rede, kurzer Sinn:
Wenn auch die lokale Namensauflösung für IPv6 störungsfrei klappen soll, sollten die Linux-Clients den avahi-daemon laufen haben.

Der avahi-daemon ist das erste, was von meinen Linuxgeräten (gleich nach der Installation) runter fliegt und das bleibt auch so.

Dann bleibe ich lieber beim nsupdate, das mit einer service- und timer-unit leicht verzögert, nach dem (re)booten gestartet wird und für richtige statische IPv4-Adressen (d. h. ohne avahi, zeroconf, mDNS, samba, etc. auf den Geräten) und alle IPv6-Adressen, das DNS-update zuverlässig ausführt:

<i>
</i>server <IPv6-Adresse-FritzBox>
zone fritz.box
ttl 864000
del raspberrypi.fritz.box AAAA
add raspberrypi.fritz.box 864000 AAAA <IPv6-Adresse-Raspi>
send

 

[SpaceRat]

eigentlich kann die Fritz!Box überhaupt nicht wissen, mit welcher IPv6 die Geräte sich konfiguriert haben.

Nein, das ist falsch und das war's nicht. Die FritzBox weiß ganz genau mit welchen IPv6-Adressen sich die Geräte konfiguriert haben, denn unter Heimnetzwerk (Details) in der FB, werden diese IPv6-Adressen die das Gerät (dhcpcd) mit:

<i>
</i>slaac hwaddr

generiert/konfiguriert hat, auch angezeigt.

Daß die Fritz!Box die IPv6-Adressen der Clients trotzdem anzeigt habe ich ja gesagt, es beruht nur eben nicht auf einer normalen Bestätigung des Clients.
Die Fritz!Box "rät" die IPv6 der Clients.

anzeigen lassen bzw. sehen. D. h. ein "dhcp6 confirm" vom Client (hier der Raspi) und ein "dhcp6 reply" von der FritzBox.

In Deinem Dump wird auch nichts anderes angezeigt als ich oben gesagt habe.
Es würde was anderes angezeigt, wenn Du bei Dir die Fritz!Box so umkonfiguriert hättest, daß sie zusätzlich auch Adressen per DHCPv6 verteilt.

Standardeinstellung für den DHCPv6 der Fritz!Box ist ja, nur zusätzliche Informationen (z.B. die zu verwendenden DNS-Server) zu verteilen, zweite Einstellung dann, daß auch Präfixe delegiert werden können und erst die dritte, daß auch IPv6-Adressen per DHCPv6 verteilt werden sollen.

Langer Rede, kurzer Sinn:
Wenn auch die lokale Namensauflösung für IPv6 störungsfrei klappen soll, sollten die Linux-Clients den avahi-daemon laufen haben.

Der avahi-daemon ist das erste, was von meinen Linuxgeräten (gleich nach der Installation) runter fliegt und das bleibt auch so.

Dein Bier.

Dann bleibe ich lieber beim nsupdate, das mit einer service- und timer-unit leicht verzögert, nach dem (re)booten gestartet wird und für richtige statische IPv4-Adressen (d. h. ohne avahi, zeroconf, mDNS, samba, etc. auf den Geräten) und alle IPv6-Adressen, das DNS-update zuverlässig ausführt:

Bleibt Dir ebenfalls unbenommen.
Meines Wissens funktioniert aber die IPv6-Namensauflösung bei Dir nicht oder nicht zuverlässig.

Ich hatte das selbe Problem und es mit avahi am zuverlässigsten lösen können.
Begrenzten Erfolg hatte es auch, gelegentlich Traffic vom Client zur Außenwelt zu provozieren. Vielleicht hilft es ja, das nsupdate einfach häufiger auszuführen.

 

[tq1199]

Es würde was anderes angezeigt, wenn Du bei Dir die Fritz!Box so umkonfiguriert hättest, daß sie zusätzlich auch Adressen per DHCPv6 verteilt.

Meine FritzBox generiert/verteilt (da so konfiguriert) auch selber, DHCPv6-Adressen für den Linux-Client. Diese IPv6-Adressen werden (... zusätzlich zu den vom Linux-Client generierten IPv6-Adressen) auch im WEB-IF der FritzBox (im Heimnetzwerk, bei den IPv6-Adressen) auch so angezeigt. Nur akzeptiert der Linux-Client richtigerweise diese von der FritzBox "verteilten" IPv6-Adressen nicht, weil er inzwischen so konfiguriert (d. h. mit "slaac hwaddr") ist. D. h., auf dem Linux-Client werden diese von der FritzBox verteilen IPv6-Adressen, mit

<i>
</i>ip a

nicht angezeigt.

BTW: Als im Linux-Client (dhcpcd.conf) noch "slaac private" konfiguriert war, hat der Linux-Client mit "ip a", auch die von der FritzBox für ihn verteilten/generierten IPv6-Adressen angezeigt, d. h. angenommen.

Der Witz ist aber, dass selbst die von der FritzBox für den Linux-Client generierten (aber vom Client nicht genutzte bzw. nicht akzeptierte) IPv6-Adressen, vom DNS-Server der FritzBox lokal (... ohne ein dns-update oder gleichwertig) nicht aufgelöst werden können.

... erst die dritte, daß auch IPv6-Adressen per DHCPv6 verteilt werden sollen.

Genau so war bzw. ist meine FritzBox konfiguriert (d. h. ich hatte die default-Einstellung schon geändert).


EDIT:

Meines Wissens funktioniert aber die IPv6-Namensauflösung bei Dir nicht oder nicht zuverlässig.

Doch, die (IPv6-)Namensauflösung funktioniert inzwischen, sogar sehr zuverlässig. Ich habe ja schon geschrieben, dass ich nsupdate auf dem Linux-Geräten nutze.

BTW: Das gleiche gilt auch bei IPv4, mit statischen IPv4-Adressen (von außerhalb des DHCP-Pools) und ohne avahi (oder gleichwertig) auf den Geräten. D. h., das ist nicht ipv6-spezifisch.

 

[SpaceRat]

Meine FritzBox generiert/verteilt (da so konfiguriert) auch selber, DHCPv6-Adressen für den Linux-Client. Diese IPv6-Adressen werden (... zusätzlich zu den vom Linux-Client generierten IPv6-Adressen) auch im WEB-IF der FritzBox (im Heimnetzwerk, bei den IPv6-Adressen) auch so angezeigt. Nur akzeptiert der Linux-Client richtigerweise diese von der FritzBox "verteilten" IPv6-Adressen nicht, weil er inzwischen so konfiguriert (d. h. mit "slaac hwaddr") ist.

Ah, Dein Konzept ist also "maximum complication".

Frage: Wieso schaltest Du das Verteilen von Adressen per DHCPv6 erst umständlich in der Fritz!Box ein, um sie dann auf den Clients doch nicht zu akzeptieren?

Der Witz ist aber, dass selbst die von der FritzBox für den Linux-Client generierten (aber vom Client nicht genutzte bzw. nicht akzeptierte) IPv6-Adressen, vom DNS-Server der FritzBox lokal (... ohne ein dns-update oder gleichwertig) nicht aufgelöst werden können.

Was ist daran ein Witz?
Der DHCPv6-Server der Fritz!Box sendet ein Lease Offer, vom Client kommt aber kein REQUEST über eine dieser IPs.
Wieso sollte die Fritz!Box dann trotzdem annehmen die IPv6 würde genutzt, wenn sie mehr oder minder explizit zurückgewiesen wurde?

Doch, die (IPv6-)Namensauflösung funktioniert inzwischen, sogar sehr zuverlässig. Ich habe ja schon geschrieben, dass ich nsupdate auf dem Linux-Geräten nutze.
BTW: Das gleiche gilt auch bei IPv4, mit statischen IPv4-Adressen (von außerhalb des DHCP-Pools) und ohne avahi (oder gleichwertig) auf den Geräten. D. h., das ist nicht ipv6-spezifisch.

Jor, es gibt immer auch einen umständlichen Weg und manchmal führt der sogar zum Ziel.

Der Normaluser erreicht das selbe Ergebnis, indem er einfach die Standardeinstellungen der Fritz!Box beibehält und ggf. DHCP lease reservations nutzt.