IPv6: keine Antwort auf DHCPv6 solicits

[PeterP]

Hallo,

ich habe in den letzten Tagen auf meinem Netgear WNDR3700v2 Router OpenWRT für nativen IPv6 Zugang konfiguriert. Dabei bin ich über ein Phänomen gestolpert, von dem ich langsam glaube, dass es auf der M-Net Seite liegt:

Wenn ich die Router-Firmware neu flashe, mich in den Router einlogge, die Zugangsdaten und IPv6 konfiguriere und anschließend neu boote, bekommt mein wide-dhcpv6-client lange Zeit keine Antwort auf seine Anfrage nach Zuteilung eines IPv6-Subnetzes. Im Logfile kommt alle zwei Minuten

Code: Alles auswählen

dhcp6c[1440]: copy_option: set client ID (len 10)
 dhcp6c[1440]: copy_option: set rapid commit (len 0)
 dhcp6c[1440]: copy_option: set elapsed time (len 2)
 dhcp6c[1440]: copy_option: set option request (len 2)
 dhcp6c[1440]: copyout_option: set IA_PD
 dhcp6c[1440]: client6_send: send solicit to ff02::1:2
 dhcp6c[1440]: dhcp6_reset_timer: reset a timer on pppoe-wan, state=SOLICIT, timeo=171, retrans=127548
 

Teilweise erst viele Stunden später kommt dann eine Antwort:

Code: Alles auswählen

dhcp6c[1440]: client6_recv: receive reply from fe80::90:1a00:2a0:ee52 on pppoe-wan
dhcp6c[1440]: dhcp6_get_options: get DHCP option server ID, len 27
dhcp6c[1440]:   DUID: 00:02:00:00:0a:4c:45:52:58:2d:31:34:34:30:2f:37:34:35:41:43:33:33:45:58:32:2f:02


das Subnetz wird zugeteilt und ab da funktioniert plötzlich alles wunderbar.

Aus Anwendersicht ist dieses Verhalten extrem unangenehm, da ich auf Anhieb nicht erkennen kann, ob ich bei meiner Client-Konfiguration einen Fehler gemacht habe, oder ob der Server gerade keine Lust hat.

Ich habe mit tcpdump den Datenverkehr auf dem pppoe-wan-Device mitgeloggt, sehe aber nicht mehr, als der dhcp-Client ins Log schreibt.
Die Firewall ist so konfiguriert, dass sie abgelehnte Pakete im Logfile protokolliert. Resultat: es tauchen keine abgelehnten Pakete zwischen Client und Server auf.

Aufgefallen ist mir folgende Meldung, die im Zuge der Auswertung einer erfolgreichen Antwort geschrieben wird:

Code: Alles auswählen

  dhcp6c[1440]: dhcp6_get_options: unknown or unexpected DHCP6 option opt_20, len 0

Option 20 ist lt. RFC3315 Reconfigure Accept Option. Könnte es sein, dass der Server so konfiguriert ist, dass er sagt 'ich habe dem Client jetzt sein Subnetz mit einer Gültigkeitsdauer von N Stunden zugewiesen, also stelle ich mich für alle anderen Anfragen in dieser Zeit taub' ?

[dv]

Könnte es sein, dass der Server so konfiguriert ist, dass er sagt 'ich habe dem Client jetzt sein Subnetz mit einer Gültigkeitsdauer von N Stunden zugewiesen, also stelle ich mich für alle anderen Anfragen in dieser Zeit taub' ?

Die Vermutung kam mir bei meinen Tests mit wide-dhcp6-client auch schon in den Sinn. Wenn kein DHCP6-Release vor dem Verbindungsabbruch gesendet werden kann, scheint der Server in einen langen Timeout zu laufen und keine weiteren Anfragen mehr zu beantworten. Um das Problem zu vermeiden, könntest du vor dem flashen das KILL Signal an dhcp6c senden.

Für ungeplante Verbindungsabbrüche ist das natürlich keine Lösung. Mal sehen, ob wir das noch vor dem World IPv6 Day in den Griff bekommen.

[PeterP]

Ich hatte gerade noch eine zweite Idee:
Ich habe es bisher nicht mitprotokolliert, bin mir aber relativ sicher, dass der Router sich nach jedem Neuflashen mit einer neuen DUID meldet.

Das würde bedeuten, dass wenn jemand nach Problemen mit einem bekannt guten Ersatzgerät online geht, dieses jetzt auch spinnen würde.

[deckel]

Ich vermute es liegt daran:
https://dev.openwrt.org/ticket/9503

Alle openwrt router nutzen die selbe DUID

Der patch funktioniert bei mir (10.03.1-rc5-testing) zwar nicht, aber wenn ich die meine mac fest ins /etc/init.d/dhcp6c kodiere bekomme ich sofort eine Antwort.

[wutz]

Ich vermute es liegt daran:
https://dev.openwrt.org/ticket/9503

Alle openwrt router nutzen die selbe DUID

Der patch funktioniert bei mir (10.03.1-rc5-testing) zwar nicht, aber wenn ich die meine mac fest ins /etc/init.d/dhcp6c kodiere bekomme ich sofort eine Antwort.

Mit dem patch funktioniert es hier... zumindest schon mal auf dem router.

Code: Alles auswählen

root@OpenWrt:~# ping6 sixxs.net
PING sixxs.net (2001:838:2:1::30:67): 56 data bytes
64 bytes from 2001:838:2:1::30:67: seq=0 ttl=56 time=63.248 ms
64 bytes from 2001:838:2:1::30:67: seq=1 ttl=56 time=64.924 ms

Danke für's herausfinden.

[PeterP]

Der Bug wurde in Bleeding Edge inzwischen gefixt, hier ist der offizielle Patch: https://dev.openwrt.org/changeset/27140

[madduck]

Ich habe das gleiche Problem mit wide-dhcpv6-client auf Debian (Version 20080615-8squeeze1). Die DUID wird jedoch zufällig generiert und ist deshalb vermutlich einzigartig.

Die LL-Verbindung via PPPoE-Link klappt, der Router beantwortet ping6. Es gibt jedoch keine Antwort auf die Solicitations:

Code: Alles auswählen

# tshark -ni ppp0 port dhcpv6-server &
# dhcp6c -df -Pdefault ppp0
  0.000000 fe80::7d50:cd65:8b2f:dee8 -> ff02::1:2    DHCPv6 Solicit
  2.132170 fe80::7d50:cd65:8b2f:dee8 -> ff02::1:2    DHCPv6 Solicit
  […]

  Jun 27 11:13:51 wall dhcp6c: copy_option: set client ID (len 14)
  Jun 27 11:13:51 wall dhcp6c: copyout_option: set identity association
  Jun 27 11:13:51 wall dhcp6c: copy_option: set rapid commit (len 0)
  Jun 27 11:13:51 wall dhcp6c: copy_option: set elapsed time (len 2)
  Jun 27 11:13:51 wall dhcp6c: client6_send: send solicit to ff02::1:2%ppp0
  Jun 27 11:13:51 wall dhcp6c: dhcp6_reset_timer: reset a timer on ppp0, state=SOLICIT, timeo=2, retrans=4250
  […]


Das geht über Stunden und Tage so weiter, ohne daß jemals eine Antwort kommt.

Ping6 auf ff02::1:2 geht nicht. Ich habe auch keine andere ff02::* Adresse gefunden, die gepingt werden kann.

[4ke]

Ich habe das gleiche Problem mit wide-dhcpv6-client auf Debian (Version 20080615-8squeeze1). Die DUID wird jedoch zufällig generiert und ist deshalb vermutlich einzigartig.

Sie sollte dann aber fest bleiben. Ansonsten dürfte es Probleme mit dem DHCPv6-Server geben.

Das geht über Stunden und Tage so weiter, ohne daß jemals eine Antwort kommt.

Die Solicit-Message enthält keine IA-PD option. Deshalb verwirft unser System die Nachricht. Unter viewtopic.php?f=1&t=6255&start=30 wurde schon mal was zur Konfiguration des wide-dhcpv6-clients geschrieben.

[madduck]

Besten Dank für Ihre/Deine Antwort!

[Die DUID] sollte dann aber fest bleiben. Ansonsten dürfte es Probleme mit dem DHCPv6-Server geben.

Ja, natürlich, die anfangs generierte DUID wird in /var/lib/dhcpv6/dhcp6c_duid gespeichert.

Die Solicit-Message enthält keine IA-PD option. Deshalb verwirft unser System die Nachricht.

Damit habe ich es in der Tat geschafft — leider aber nur genau einmal. Seitdem bekomme ich wieder keine Antworten auf die Solicitations:

Code: Alles auswählen

Jun/28/2011 10:28:57: copy_option: set client ID (len 14)
Jun/28/2011 10:28:57: copy_option: set rapid commit (len 0)
Jun/28/2011 10:28:57: copy_option: set elapsed time (len 2)
Jun/28/2011 10:28:57: copyout_option: set IA_PD
Jun/28/2011 10:28:57: client6_send: send solicit to ff02::1:2%ppp0
Jun/28/2011 10:28:57: dhcp6_reset_timer: reset a timer on ppp0, state=SOLICIT, timeo=8, retrans=120240


[4ke]

Damit habe ich es in der Tat geschafft — leider aber nur genau einmal. Seitdem bekomme ich wieder keine Antworten auf die Solicitations:

Für mich schaut das so aus, als ob dein Client jetzt mit einer anderen DUID kommt. So wie die Prefix-Vergabe derzeit funktioniert führt das zu Problemen. Die Zuweisung hat mit <LLT 1/362390702/**********B0> funktioniert, jetzt kommst du mit <LLT 1/362566045/**********B1>.

[madduck]

Für mich schaut das so aus, als ob dein Client jetzt mit einer anderen DUID kommt.

Danke, daß Du Dir so viel Zeit für mich nimmst. Ich bin DHCPv6-Neuling,
deswegen mache ich so dumme Sachen wie DUID-ändern:

Ich habe in der Tat die letzten paar Stunden dibbler versucht, aber nur weil
es auch mit wide-dhcp-client nicht mehr ging (also auch mit der alten DUID).

Nun habe ich die beiden DUIDs auf den ursprünglichen Wert synchronisiert und
mir das per tshark bestätigen lassen. Die DUID ist also wieder auf dem alten
Wert, das Problem besteht aber nach wie vor.

Code: Alles auswählen

Client Identifier
    option type: 1
    option length: 14
    DUID type: link-layer address plus time (1)
    Hardware type: Ethernet (1)
    Time: 362390702
    Link-layer address: **:**:**:**:**:b0


Ich lasse das mal so laufen.

Wieso macht eine neue DUID Probleme? Woher weiß Euer Server denn, daß ich eine
neue DUID habe und nicht etwa ein anderer Benutzer bin?

[madduck]

Die DUID ist also wieder auf dem alten Wert, das Problem besteht aber nach wie vor.

… und nun geht auf einmal alles!

Danke!