Problem mit DLink DIR300 und DHCP

[Roemer2201]

Hallo Leute,

ich habe bei DLink ein Supportticket aufgemacht, da bei meinem Dlink Dir300 das DHCP nicht mehr richtig zu funktionieren scheint.

Hier mal auszugsweise meine Anfrage:

ich habe ein Problem mit folgendem Gerät:

DLink DIR-300

Hardware Version : B1

Firmware Version : 2.05

Das Problem betrifft die DHCP-Adressverteilung:

Nach einer gewissen Zeit verteilt das Gerät keine Adressen mehr im Netzwerk. Ein Ein-/Ausschalten des Gerätes hilft, aber je nach dem wie viele Geräte sich eine neue Adresse holen wollen, geht es unterschiedlich schnell, bis keine Adressen mehr verteilt werden. Alternativ kann ich auch von einem Client, der Netzwerkzugrff hat auf die Weboberfläche gehen: "Enable DHCP Server" abwählen, speichern, das Häkchen neu setzen und wieder speichern. Auffällig ist, dass es besonders schnell nicht mehr funktioniert, wenn ich unter Windows "ipconfig /release" und danach "ipconfig /renew" ausführe.

Folgende Parameter sind in der Weboberfläche des Gerätes definiert:

Router IP Address : 192.168.0.1

Default Subnet Mask : 255.255.255.0

Local Domain Name : (leer)

Enable DNS Relay : (ja)

Enable DHCP Server : (ja)

DHCP IP Address Range : 110 to 199 (addresses within the LAN subnet)

DHCP Lease Time : 1440 (minutes)

Statische Adressvergabe:

'Computer Name','IP Address','MAC Address'

'HeimPC','192.168.0.100','00:23:54:16:78:62'

'VAIO-Laptop','192.168.0.16','00:24:D6:1B:AD:7A'

'EEE-WLAN','192.168.0.102','00:22:43:42:78:3B'

'EEE-LAN','192.168.0.101','00:23:54:36:EA:A5'

'Homeserver','192.168.0.200','00:1C:C0:C0:66:98']

'VNet','192.168.0.254','08:00:27:E5:30:8B']

'p3-laptop','192.168.0.201','00:1F:1F:6E:32:50']

'iPod','192.168.0.104','90:84:0D:06:59:22']

'iPhone','192.168.0.103','60:FB:42:B2:2F:5B']

'Xperia','192.168.0.9','B8:F9:34:1C:81:36']

'Test-XP','192.168.0.150','08:00:27:F5:14:A7']

Jetzt ist vom Support folgende Antwort gekommen:

Wundert mich nicht sonderlich, da keiner der Statischen DHCP Einträge außer einer, ist innerhalb des DHCP-Bereiches, in dem Ihr DIR-300 IPs vergeben soll.

Den DHCP-Bereich haben Sie auf 110 bis 199 vergeben.

Doch soll er die IP .100, .16, .102, .101, .200, .254, 201, .104, .103, und .9 vergeben.

Ein DHCP Server kann immer nur innerhalb seines DHCP Bereiches IPs vergeben. Ein Statisches DHCP ändert daran nichts.

Ist das wirklich so, dass die statischen DHCP-Einträge innerhalb des DHCP-Bereichs sein müssen? Oder ist das eine Eigenart von dem Gerät? Ich möchte meinen, dass der dynamische Bereich für wechselnde Clients gedacht ist und alles was außerhalb dieses Bereichs ist, kann ein DHCP-Server durch statische Einträge ebenfalls verteilen. Zumindest ist das bei ISC-DHCPD unter Ubuntu so.

Seht ihr das genau so, oder liege ich mit meinen Annahmen falsch?

[axxis]

Hi,

man möge mich korrigieren, aber ich bilde mir ein, dass DHCP Pools für dynamic allocation gedacht sind. Die festen Adressen für die manual allocation sollten/können außerhalb dieses Bereichs liegen.

RFC 2131 - Dynamic Host Configuration Protocol (RFC2131)

Was DLink da implementiert ist jedoch wieder ne völlig andere Geschichte

Gruß

axxis

[Roemer2201]

Ich habe folgendes geantwortet:

Das wäre mir aber neu, dass man die statischen IP's innerhalb des Bereichs für dynamische Adressverteilung legen muss. Das macht den dynamischen Bereich nahezu oboslet. Ist das also eine Eigenart des DHCP-Servers im DIR300?

Und dies ist als Antwort zurückgekommen:

Nein, ist bei jedem (normalen) DHCP Server und bei ALLEN unseren Router daher auch so.

Dass es überhaupt möglich ist, Statische DHCP Einstellungen außerhalb der DHCP-Range zu setzen, ist m.E. ein Bug. Der DIR-300 müsste da dann meckern.

Bitte setzen Sie daher die Statischen IP-Vergaben innerhalb der DHCP-Range oder passen die DHCP-Range des DIR-300 an.

Vielen Dank für deinen Link, jedoch konnte ich nicht zu 100% herauslesen, dass statische Adressen außerhalb des dynamischen Bereichs können. Ich muss aber zugeben, ich habe mir nur den 2. Abschnitt durchgelesen (2.1 / 2.2). Gibt es in den weiteren Abschnitten noch nähere Definitionen dazu?

ich würde mich über eine weitere Antwort freuen.

[axxis]

Im Abschnitt 1 erklären das im Prinzip die zwei Absätze nach

DHCP supports three mechanisms[...]

Im TCP/IP Guide ist das auch nochmal ziemlich gut beschrieben The TCP/IP Guide - DHCP Address Assignment and Allocation Mechanisms

Der eigentliche DHCP "Pool" ist für die dynamische IP-Vergabe gedacht.

[Roemer2201]

Ich habe mal noch ein paar Tests gemacht mit einer virtuellen XP-Maschine auf meinem normalen Rechner. Bild 1 ist mit den Adressbereich außerhalb der statischen Clients und bei Bild 2 hat der Router den Adressbereich von 192.168.0.2 - 254.

Meine Fragen sind in den Screenshots verzeichnet.

Sind diese beiden Screenshots aussagekräftig genug, sodass ich diese dem Support zukommen lassen kann?

Vielen Dank für deinen zweiten Link

EDIT:/

Danke für den Hinweis auf Abschnitt 1, ich denke dieser Satz trifft mein Problem ganz gut:

Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

Bearbeitet 5. August 2011 von Roemer2201

[Chief Wiggum]

Sind diese beiden Screenshots aussagekräftig genug, sodass ich diese dem Support zukommen lassen kann?

Was willst du erreichen?

DLink hat die DHCP Funktionalität nun einmal so und nicht anders implementiert.

Nach meinem Verständnis liegt der Fehler bei dir, wenn du den DHCP zwingen willst, ausserhalb des verteilbaren Bereiches IP Adressen zu verteilen.

Unter Windows Server hast du deshalb den DHCP-Bereich und in in diesem Bereich den Adresspool. Der Adresspool innerhalb des Bereiches ist für die freie Verteilung zuständig, die Adressen, die im Bereich, aber ausserhalb des Pools liegen, werden nur verwendet, wenn du eine Reservierung einträgst.

[axxis]

zu Bild1: NAK bedeutet hier, dass der Client nicht im richtigen Netz ist (falsche Subnetzmaske etc.) oder dass die Lease abgelaufen ist.

zu Bild2: Wenn der Client im Netz einen DHCP-Server kennt und er gerne die IP-Adresse, die er zuvor zugewiesen bekommen hat, wieder nutzen möchte, dann sendet er nach dem DISCOVER direkt ein REQUEST. Das NAK bedeutet in dem Fall, dass der Client die von ihm vorher verwendete IP nicht benutzen kann.

Irgendwie ist das schon ziemlich krank, was DLINK dort macht, man sollte das vielleicht mal mit einem anderen DHCP-Server testen (würd ich morgen mal machen, wenn es dir was bringt).

[axxis]

@Chief: Ja, und genauso soll das auch sein.

Beim Linux dhcpd ist das nicht anders, der Server kennt sein Subnetz und innerhalb dieses Subnetzes sind Ranges für die dynamische Adress-Vergabe konfiguriert.

Statische Hosts können/sollten davon losgelöst konfiguriert werden (innerhalb des Subnetzes aber außerhalb der Ranges).

[Chief Wiggum]

Erstens: du kannst einen 20-Euro-Router nicht mit einem ausgewachsenen Serversystem vergleichen.

Zweitens scheint es so zu sein, dass Dlink den DHCP-Bereich gleichsetzt mit dem dynamischen Adresspool.

Wenn du genau diese Funktionalität brauchst, hol dir einen anderen Router.

[Roemer2201]

zu Bild2: [...] Das NAK bedeutet in dem Fall, dass der Client die von ihm vorher verwendete IP nicht benutzen kann.

Aber warum macht das der Client dann trotzdem? Er nimmt trotz NAK wieder die 150 als IP.

[axxis]

Dann hat der DLink Supporter wohl Recht gehabt, wird ein Bug in deren Implementierung sein.

Nach einem NAK versucht ein Client normalerweise n-mal erneut eine IP-Adresse zu bekommen, schluss endlich landet er aber im Link-Local Netz (169.254.0.0./16)

[Roemer2201]

Was willst du erreichen?

Ursprünglich habe ich gedacht, dass die Firmware oder das Gerät selbst einen Schaden hat. Jetzt, wo wir tiefer in diese Problematik eingedrungen sind, weis ich nicht mehr was ich will: zumindest will ich die Fakten klären.

Und geklärt haben wir, dass die statischen Clients außerhalb des dynamischen Bereichs gelegt werden können und sollten, scheinbar jedoch nicht bei DLink.

Ich werde jetzt den dynamischen Bereich von .2 - .254 einstellen und schauen, ob und wie lang meine Geräte Adressen bekommen. Denn so sollte es ja auch laut DLink-Support funktionieren. Wenn dann jedoch der DHCP-Dienst wieder den Dienst verweigert, weis ich nicht, wie es weitergeht.

Leider werde ich es dieses Wochenende nicht weiter testen können. Ihr werdet von mir diesbezüglich am Montag wieder hören.

Bearbeitet 5. August 2011 von Roemer2201

[Roemer2201]

Dann hat der DLink Supporter wohl Recht gehabt, wird ein Bug in deren Implementierung sein.

Den Bug, den der DLink-Supporter ansprach, bezieht sich nur darauf, dass der Router meckern müsste, wenn ein statischer Eintrag außerhalb den dynamischen Bereichs eingestellt werden soll.

Nach einem NAK versucht ein Client normalerweise n-mal erneut eine IP-Adresse zu bekommen, schluss endlich landet er aber im Link-Local Netz (169.254.0.0./16)

Ja, was der XP-Client aber nicht macht ich wüsste auch nicht, wo ich dieses Verhalten im Windows umstellen kann.

EDIT\

Ich habe noch das PCAP-File vom Mitschnitt des Bild 2 angehängt, falls jemand einen genaueren Bild darauf werfen möchte.

Bild2_WinXP-Discover_Request_NAK.zip

Bearbeitet 5. August 2011 von Roemer2201

[axxis]

Jap, du wirst abwarten und Tee trinken müssen.

Wir z.B. lassen unsere IPs von einerAstaro Firewall vergeben, die hatte (ich glaube in der v8.101) auch massive Probleme mit statischen Hosts. Wenn ich also etwas später kam und Pech hatte, hat die Astaro meine (eigentliche feste) IP dynamisch an einen andren Client vergeben.

An sich verschmerzbar, aber da meine MAC-Adresse in der Static Leases Table ist/war, habe ich die Adresse ebenso bekommen und das war eher unschön.:cool:

[Roemer2201]

Noch ein finales Update für diesen Thread:

Ich hab die DHCP-Range ausgeweitet von .2 bis .254, einfach um sicher zu gehen. Es hat wie üblich ein paar Tage funktioniert, aber ich habe mich zu früh gefreut. Das Problem tauchte wieder auf und meine Geräte bekamen keine Adresse. Ich habe daraufhin das Ticket bei DLink wieder eröffnet, jedoch habe ich seit über einer Woche keine Antwort erhalten.

Nachdem ich mich schon fast entschlossen hatte, etwas Geld in die Hand zu nehmen und einen neuen Router zu kaufen, fiel mir ein, dass ich doch schon immer einmal OpenWRT ausprobieren wollte. Und genau das habe ich jetzt getan. OpenWRT läuft jetzt seit 5 Stunden, verteilt statische IP's ohne zu murren und die WLAN-Performance scheint auch gestiegen zu sein. Damit bin ich sehr zufrieden, zumal ich jetzt SSH-Zugriff auf das Gerät habe und es z.B. zum Tunneln nehmen kann, ohne einen zusätzlichen Rechner zu Hause laufen zu haben.