Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

Lange Antwortzeit bei Vergabe der IP-Adresse via DHCP

Alles rund um das Internet, Internet-Anwendungen (E-Mail, Surfen, Cloud usw.) und das Einrichten von Netzwerken einschl. VPN unter Linux

Moderator: Moderatoren

Antworten
Mauggel
Newbie
Newbie
Beiträge: 4
Registriert: 11. Nov 2004, 15:46

Lange Antwortzeit bei Vergabe der IP-Adresse via DHCP

Beitrag von Mauggel »

Hallo,

ich habe ein Problem mit meinem unter Suse 9.1 betriebenem DHCP-Server (feste IP 192.168.2.100). Das Problem ist, dass einer meiner zwei Arbeitsplatzrechner „ewig“ braucht, bis er die Adresse zugeteilt bekommt. Zunächst möchte ich aber ein paar Angaben zu meinem kleinen Netzwerk tätigen: Mein zentraler Server (mit Samba, Apache, … und eben DHCP) läuft unter Suse 9.1. Dann habe ich noch zwei Arbeitsplatzrechner, die ich unter Windows XP betreibe. Der komplette Netzverkehr wird drahtlos abgewickelt. Der W-LAN-Router hat die Adresse 192.168.2.1. Dieser war früher für die dynamische Vergabe der IP-Adressen zuständig. Vor ein paar Tagen habe ich mal versucht, meinen Suse-Server die Adressvergabe via DHCP durchführen zu lassen. In der dhcpd.conf vergebe ich meinen zwei Rechnern feste Adressen, da ich aber oft kurzzeitig andere Rechner ans Netz nehme, möchte ich, dass diese ihre Adresse dynamisch beziehen (ab IP 192.168.2.110). Die dhcpd.conf hat folgenden Inhalt:

option domain-name-servers 192.168.2.1; #W-LAN-Router
option netbios-name-servers 192.168.2.1; #W-LAN-Router
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.2.255;
option routers 192.168.2.1;
authoritative;
ddns-update-style none;
default-lease-time 259200;
max-lease-time 604800;
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.110 192.168.2.200;
}
#Im folgenden Abschnitt wird definiert, welche Rechner eine feste IP-Adresse erhalten
host chef {
hardware ethernet 00:0e:a6:6e:51:e9;
fixed-address 192.168.2.101;
}

host duke {
hardware ethernet 00:40:f4:94:5d:a2;
fixed-address 192.168.2.102;
}


Wenn ich nun beide Rechner einschalte, bekommt der Rechner „chef“ nach relativ kurzer Zeit seine IP-Adresse, der Rechner „duke“ wartet im Prinzip vergeblich darauf. Laut /var/log/messages wird ihm zwar immer wieder eine Adresse angeboten, er akzeptiert diese aber immer erst nach sehr, sehr langer Anlaufzeit (5 Minuten und länger). Hier der entsprechende Ausschnitt aus der Datei /var/log/messages:

Nov 11 18:54:35 beuter dhcpd: DHCPDISCOVER from 00:40:f4:94:5d:a2 via eth0
Nov 11 18:54:35 beuter dhcpd: DHCPOFFER on 192.168.2.102 to 00:40:f4:94:5d:a2 via eth0
Nov 11 18:54:35 beuter dhcpd: DHCPDISCOVER from 00:40:f4:94:5d:a2 via eth0
Nov 11 18:54:35 beuter dhcpd: DHCPOFFER on 192.168.2.102 to 00:40:f4:94:5d:a2 via eth0
Nov 11 18:54:47 beuter dhcpd: DHCPDISCOVER from 00:40:f4:94:5d:a2 via eth0
Nov 11 18:54:47 beuter dhcpd: DHCPOFFER on 192.168.2.102 to 00:40:f4:94:5d:a2 via eth0
Nov 11 18:55:39 beuter dhcpd: DHCPDISCOVER from 00:40:f4:94:5d:a2 via eth0
Nov 11 18:55:39 beuter dhcpd: DHCPOFFER on 192.168.2.102 to 00:40:f4:94:5d:a2 via eth0
Nov 11 18:59:09 beuter dhcpd: DHCPREQUEST for 192.168.2.101 from 00:0e:a6:6e:51:e9 via eth0
Nov 11 18:59:09 beuter dhcpd: DHCPACK on 192.168.2.101 to 00:0e:a6:6e:51:e9 via eth0
Nov 11 19:01:35 beuter dhcpd: DHCPDISCOVER from 00:40:f4:94:5d:a2 via eth0
Nov 11 19:01:35 beuter dhcpd: DHCPOFFER on 192.168.2.102 to 00:40:f4:94:5d:a2 via eth0
Nov 11 19:01:36 beuter dhcpd: DHCPREQUEST for 192.168.2.102 (192.168.2.100) from 00:40:f4:94:5d:a2 via eth0
Nov 11 19:01:36 beuter dhcpd: DHCPACK on 192.168.2.102 to 00:40:f4:94:5d:a2 via eth0


Ich hoffe, ihr könnt mit meiner Problemschilderung etwas anfangen und mir weiterhelfen. Vorab schon mal besten Dank.

Mauggel
switcher51
Member
Member
Beiträge: 142
Registriert: 1. Okt 2004, 19:18

Beitrag von switcher51 »

Leider habe ich noch keine Idee. Daher ein paar Fragen:
Gibt es Unterschiede in der Netzwerkkonfiguation der WIN-PC?
(Routing, Nameserver, Netzwerkmaske,... - sollte alles leer sein)
Ist DHCP auf dem WLAN-Router deakiviert?
Was passiert, wenn die feste IP-Zuodnung vorübergehend auskommentiert wird?
Was passiert, wenn die IP-Adressen in der DHCP-Konfig. auf dem Server vertauscht werden?
Wenn Server und PC nur über ein Crossover-Kabel (allein) verbunden sind, was passiert dann?
Bei den Tests bitte umsichtig vorgehen, d.h
1. PCs und DHCP-Server stoppen
2. Leases-Datei löschen
3. umkonfigurieren
4. DHCP-Server starten
5. Test durchführen
Vielleicht hilft auch ein Protokoll der Ethernet-Schnittstelle mit tcpdump.

Gruß switcher51
Mauggel
Newbie
Newbie
Beiträge: 4
Registriert: 11. Nov 2004, 15:46

Beitrag von Mauggel »

Hallo switcher51,

Die WIN-PCs sind bei den Netzwerkeinstellungen gleich konfiguriert. Beide Rechner sind auf DHCP eingestellt, so dass ich manuell keine Einträge getätigt habe. DHCP auf dem WLAN-Router ist deaktiviert.
Ich habe nun mal gemäß deinen Vorschlägen folgenden Test durchgeführt: die feste IP-Zuordnung in der dhcpd.conf für den Rechner „chef“ auskommentiert.
Das Ergebnis ist, dass ich auf dem Rechner keine IP-Adresse erhalte. Komischerweise wird jedoch eine dreimalige Adressvergabe innerhalb kürzerster Zeit in der dhcpd.leases festgehalten:

lease 192.168.2.200 {
starts 6 2004/11/13 05:40:57;
ends 2 2004/11/16 05:40:57;
binding state active;
next binding state free;
hardware ethernet 00:0e:a6:6e:51:e9;
uid "\001\000\016\246nQ\351";
client-hostname "chef";
}
lease 192.168.2.200 {
starts 6 2004/11/13 05:41:05;
ends 2 2004/11/16 05:41:05;
binding state active;
next binding state free;
hardware ethernet 00:0e:a6:6e:51:e9;
uid "\001\000\016\246nQ\351";
client-hostname "chef";
}
lease 192.168.2.200 {
starts 6 2004/11/13 05:41:22;
ends 2 2004/11/16 05:41:22;
binding state active;
next binding state free;
hardware ethernet 00:0e:a6:6e:51:e9;
uid "\001\000\016\246nQ\351";
client-hostname "chef";
}


Die Datei /var/log/messages hat folgenden Inhalt:

Nov 13 06:40:23 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 via eth0
Nov 13 06:40:24 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:40:35 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:40:35 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:40:52 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:40:52 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:40:57 beuter dhcpd: DHCPREQUEST for 192.168.2.200 (192.168.2.100) from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:40:57 beuter dhcpd: DHCPACK on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:41:05 beuter dhcpd: DHCPREQUEST for 192.168.2.200 (192.168.2.100) from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:41:05 beuter dhcpd: DHCPACK on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:41:22 beuter dhcpd: DHCPREQUEST for 192.168.2.200 (192.168.2.100) from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:41:22 beuter dhcpd: DHCPACK on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:41:55 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:41:55 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:42:06 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:42:06 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:42:22 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:42:22 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:42:45 beuter smbd[4533]: [2004/11/13 06:42:45, 0] lib/util_sock.c:read_socket_data(367)
Nov 13 06:42:45 beuter smbd[4533]: read_socket_data: recv failure for 4. Error = No route to host
Nov 13 06:42:59 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:42:59 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:43:27 beuter dhcpd: DHCPDISCOVER from 00:0e:a6:6e:51:e9 (chef) via eth0
Nov 13 06:43:27 beuter dhcpd: DHCPOFFER on 192.168.2.200 to 00:0e:a6:6e:51:e9 (chef) via eth0


Immer wenn ein DHCPACK erfolgt, wird auch ein Eintrag in der dhcpd.leases vorgenommen.
Bei dem x-ten DHCPACK wird dann vielleicht vom WIN-PC übernommen.
Ich hoffe, ich konnte dir neue Anhaltspunkte liefern. Weitere Resultate teile ich dir gerne mit.
Vielen Dank für deine Hilfe,

Gruß

Mauggel
switcher51
Member
Member
Beiträge: 142
Registriert: 1. Okt 2004, 19:18

Beitrag von switcher51 »

Es ist wohl normal, dass da 3 mal um die IP-Adresse verhandel wird. Hier ein Auszug aus meinem Log:

Code: Alles auswählen

Nov 13 10:30:24 tux dhcpd: DHCPDISCOVER from 00:50:bf:6a:96:85 via eth1
Nov 13 10:30:24 tux dhcpd: DHCPOFFER on 192.168.42.54 to 00:50:bf:6a:96:85 via eth1
Nov 13 10:30:24 tux dhcpd: DHCPREQUEST for 192.168.42.54 (192.168.42.10) from 00:50:bf:6a:96:85 via eth1
Nov 13 10:30:24 tux dhcpd: DHCPACK on 192.168.42.54 to 00:50:bf:6a:96:85 via eth1
Nov 13 10:31:29 tux dhcpd: DHCPINFORM from 192.168.42.54 via eth1
Nov 13 10:31:29 tux dhcpd: DHCPACK to 192.168.42.54
Nov 13 10:31:32 tux dhcpd: DHCPINFORM from 192.168.42.54 via eth1
Nov 13 10:31:32 tux dhcpd: DHCPACK to 192.168.42.54
Mir sieht es danach aus, dass der PC den Lease nicht annimmt - aber warum????
Welches Windows läuft auf den Rechnern?
Hat DHCP mit einem anderen PC schon einmal funktioniert?

Man kann den DHCP-Server Debuggen:

Code: Alles auswählen

dhcpd -d -f 
Vielleicht bringt das neue Erkenntnisse.

Gruß switcher51
Mauggel
Newbie
Newbie
Beiträge: 4
Registriert: 11. Nov 2004, 15:46

Beitrag von Mauggel »

hallo switcher!

nach langer zeit wolte ich das thema doch nochmals aufgreifen, um dich über den derzeitgigen stand der dinge aufzuklären:
momentan läuft die sache wirklich super. es lag wohl daran. daß mein server, den ich momentan noch über wlan betreibe, eine äußerst instabile verbindung zum funknetz hatte. seitdem ich den rechner vor ein paar tagen in eine andere räumlichkeit gestellt habe und nun immer konstante übertragungsraten von 12 mbit oder höher und ein gutes signal habe, funktioniert alles bestens. das freut mich auf jeden fall riesig.
in naher zukunft (d.h. um weihnachten) werde ich den server aber dann eh wieder "verkabeln", so daß eine nahezu einwandfreie stabilität der netzverbindung gewährleistet ist. die clients werden natürlich weiterhin kabellos betrieben, da läuft es sowieso bestens.

nochmals danke für deine mithilfe!

mauggel
Antworten