harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
... und da (also am Router = FritzBox 6591 Cable) habe ich weitergesucht.
Nachdem ich den DHCPv6 deaktiviert habe, sendet der Router auch die RA-Nachrichten. Den DNS kann ich ebenfalls über das RA bekannt geben, also kein Bedarf für DHCPv6.
Jetzt bekommt der Rechner unmittelbar nach dem Booten seine link-local- und global-Adressen. Ich hoffe, dass das die Ursache war! Vielen Dank für die superschnelle Hilfe!
|
harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
... und leider: Kommando zurück: Nach einem Reboot warte ich jetzt wieder auf die RA, die nicht kommt. Supportticket bei AVM ist erstellt, ich halte Euch hier auf dem Laufenden (außerdem sollte RA bei IPv6 immer aktiv sein, auch wenn nebenbei noch ein DHCPv6 läuft).
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
harteknut schrieb: Nach einem Reboot warte ich jetzt wieder auf die RA, die nicht kommt.
Kommt die RA auch dann nicht, wenn Du vom Client (mit z. B. ndptool) eine RS sendest? apt-cache show libndp-tools
http://manpages.ubuntu.com/manpages/impish/man8/ndptool.8.html
|
harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
Das ist es, was mich so wundert (oder eigentlich: nervt): Jetzt aktuell ist alles tiptop! Gerade gebootet, drei IPv6-Adressen bekommen (linklocal, global-dynamisch und global-temporär-dynamisch). Präfix und DNS-Server wird mit der RA-Nachricht übergeben, DHCPv6 vermisse ich nicht. Mit Wireshark kann ich die RA-Nachricht auslesen. Auf jede RS-Nachricht, die ich mit
| sudo ndptool -i wlp3s0 -t rs send
|
provoziere, bekomme ich auch eine RA-Antwort. Ich konnte noch nicht rausfinden, wann und warum der Router diesen Service einstellt. Evtl. können die Kollegen von AVM da was zu sagen...
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
harteknut schrieb: Mit Wireshark kann ich die RA-Nachricht auslesen. Auf jede RS-Nachricht, die ich mit
sudo ndptool -i wlp3s0 -t rs send
provoziere, bekomme ich auch eine RA-Antwort.
BTW: Du kannst die RA-Nachricht auch mit einer 2. ndptool-Instanz (im monitor/verbose modus) auslesen. Oder mit tcpdump (statt Wireshark). Denn vergleiche mal die Abhängigkeiten von Wireshark bzw. tshark mit den Abhängigkeiten von tcpdump bzw. von ndptool. Nur so als Info wenn man mal einen Server betreibt (... was hier aber jetzt nicht der Fall ist). tcpdump-Filter für RS/RA:
sudo tcpdump -v -ni wlp3s0 'icmp6 and (ip6[40] == 134)' # RA vom router
sudo tcpdump -v -ni wlp3s0 'icmp6 and (ip6[40] == 133)' # RS zum router BTW2: Hast Du schon mit dhcpcd5 als v6-dhcp-Client versucht? EDIT: Als temporärer workaround, kannst Du mit ndptool und einem cronjob bzw. mit einer timer-unit, auch schon beim Booten und danach regelmäßig, RS' an den Router senden.
|
harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
Danke für die Tips!
ndptool und tcpdump schaue ich mir auf jeden Fall mal an, beim Thema Trafficmonitoring bin ich echt noch recht blank. Das “manuelle” Senden der RS-Nachrichten ist aber gar nicht nötig, die werden vom Client ja regelmäßig abgesetzt. Das Problem ist, dass vom Router sporadisch keine RA-Antworten kommen. Und da es sich dabei um eine Cable-FritzBox handelt, sind meine Analysemöglichkeiten leider begrenzt. dhcpcd5 habe ich noch nicht probiert, den DHCPv6-Server im Router habe ich aber inzwischen abgeschaltet (nur noch SLAAC im LAN) und sehe dafür auch keinen Bedarf. Danke nochmal für die Hinweise! Macht Spaß hier im Forum!
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
harteknut schrieb: Das “manuelle” Senden der RS-Nachrichten ist aber gar nicht nötig, die werden vom Client ja regelmäßig abgesetzt. Das Problem ist, dass vom Router sporadisch keine RA-Antworten kommen.
Wenn Du eine RS mit dem ndptool sendest, kommt immer eine RA vom Router, aber wenn der Client das macht, kommt die RA nicht immer?
Gibt es evtl. einen Unterschied in den RS' vom Client bzw. vom ndptool? Siehe z. B. mit Wireshark/ndptool/tcpdump nach. harteknut schrieb: dhcpcd5 habe ich noch nicht probiert, den DHCPv6-Server im Router habe ich aber inzwischen abgeschaltet (nur noch SLAAC im LAN) und sehe dafür auch keinen Bedarf.
OK, ... btw., nur als INFO: Mit dem dhcpcd5 kannst Du auch "SLAAC im LAN" machen (falls mal erforderlich).
|
harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
Ich hatte die Situation hier:
harteknut schrieb: Das ist es, was mich so wundert (oder eigentlich: nervt): Jetzt aktuell ist alles tiptop! Gerade gebootet, drei IPv6-Adressen bekommen (linklocal, global-dynamisch und global-temporär-dynamisch). Präfix und DNS-Server wird mit der RA-Nachricht übergeben, DHCPv6 vermisse ich nicht. Mit Wireshark kann ich die RA-Nachricht auslesen. Auf jede RS-Nachricht, die ich mit
| sudo ndptool -i wlp3s0 -t rs send
|
provoziere, bekomme ich auch eine RA-Antwort. Ich konnte noch nicht rausfinden, wann und warum der Router diesen Service einstellt. Evtl. können die Kollegen von AVM da was zu sagen...
wahrscheinlich nicht eindeutig beschrieben, ich konkretisiere es daher nochmal:
Mein Ubuntu-Rechner sendet immer nach der Anmeldung am WLAN seine RS-Nachrichten. In der Regel erhält er vom Router auch RA-Antworten mit Präfix und DNS und baut sich dann via SLAAC die drei IPv6-Adressen auf. Wenn ich in dieser Situation einfach mal zwischendurch zusätzlich eine RA-Nachricht "manuell" über ndptool absetze, kommt ebenfalls unmittelbar eine RA-Antwort vom Router. Sporadisch sehe ich nach dem Booten oder neu-Verbinden zwar die RS-Abfragen, aber keine RA-Antworten. Der Rechner gibt sich dann zwar eine linklocal-Adresse, aber aufgrund fehlendem Präfix keine globalen Adressen. In dieser Situation habe ich noch nicht versucht, eine RS manuell zu schicken. Ich warte auf die nächsten "RA-Aussetzer"...
Ich werde jetzt mal prüfen, ob sich die RS-Nachrichten, die automatisch versendet werden von denen unterscheiden, die ich per ndptool schicke.
|
harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
Hier ein Update, falls andere User mal ein ähnliches Thema feststellen, ich konnte ein bisschen weiter eingrenzen:
Ich gehe aktuell davon aus, dass es weder an Router / Fritzbox, noch am Ubuntu-Rechner liegt, sondern an den Access Points, an die ich bislang nicht gedacht hatte (und von denen ich ja auch noch nix geschrieben hatte): Ich nutze in meinem Haus ausschließlich Unifi-APs, das FritzBox-eigene WLAN ist deaktiviert. Jetzt scheint es aber so zu sein, dass die APs immer mal wieder die Weitergabe der RA-Broadcastnachrichten verweigern. Dazu habe ich ein paar Berichte im Netz gefunden, außerdem folgende Beobachtung gemacht: Wenn mein Rechner wieder mal keine IPv6 erhält und ich den nächsten AP (Unifi AP AC pro) mal einfach vom LAN abziehe und mein Rechner sich in Folge mit dem nächstbesten AP verbindet (kann ich alles im Unifi Controller beobachten), sehe ich sofort RA Botschaften im Wiresark-Log und bekomme auch sofort eine IPv6-Adresse. Gleiches gilt, wenn ich den Rechner in dieser Situation einfach am AP per LAN stecke. (Der AP AC Pro hat einen zweiten LAN-Anschluss.) Wieso und warum der AP das macht ist aber noch ein Rätsel.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Dein AP sollte aber keine Firewall sein und das blockieren. Prüfe mal, ob man das sowas einstellen kann.
|
harteknut
(Themenstarter)
Anmeldungsdatum: 9. Oktober 2007
Beiträge: 213
|
Ja, das kann man einstellen:
Es gibt die Option "Sperrung von LAN zu WLAN Multicast- und Broadcastverkehr", um die Performance des WLANs zu optimieren. Das Gateway ist allerdings grundsätzlich von dieser Sperrung ausgeschlossen, außerdem lässt sich eine Whitelist anlegen, um weitere Geräte von der Sperrung auszunehmen. Ich hatte die Option bislang aber nicht aktiviert. Habe verschiedene Optionen probiert. Der Fehler tritt (sporadisch, meistens nach wenigen Tagen) auf, wenn...
die Option nicht aktiv ist die Option aktiviert ist (aber das Gateway "automatisch" von der Sperrung ausgeschlossen ist) die Option aktiviert ist und der Router nochmal explizit in die Whitelist eingetragen wurde.
Das Verhalten wird auch von verschiedenen anderen Anwendern für den UAP AC pro und die SW 4.3.28 im Unifi-Forum beschrieben. Ich habe es dort ebenfalls gemeldet und hoffe, dass das in der AP-SW gefixed wird.
|