DHCP Server gibt falsche Adressen raus!

[Fallaxia]

Hi Leute,

ich habe ein Problem mit einem DHCPd:

dhcpd: DHCPREQUEST for 192.168.100.170 (192.168.100.132) from 00:11:d8:5e:c9:d5 via eth0: lease 192.168.100.170 unavailable.
dhcpd: DHCPREQUEST for 192.168.100.170 (192.168.100.132) from 00:11:d8:5e:c9:d5 via eth0
dhcpd: DHCPACK on 192.168.100.170 to 00:11:d8:5e:c9:d5 via eth0
dhcpd: DHCPNAK on 192.168.100.170 to 00:11:d8:5e:c9:d5 via eth0

Ich habe den Host mit der MAC in die Tabelle des DHCPd eingetragen und er soll eigentlich die 192.168.100.152 bekommen, aber der DHCP bekommt offenbar zwei Anfragen vom Host und beantwortet die erste mit "OK" und die Zweite mit Ablehnung.

Er müsste aber eigentlich beide Anfragen ablehnen und ein OFFER für die 192.168.100.152 geben. Tut er aber nicht.

Was kann da los sein?
Die anderen Hosts erhalten die jeweils passenden Adressen, so wie eingetragen.

Dazu muss ich sagen, dass der Host hier zuvor die 192.168.100.170 hatte, jetzt jedoch auf 192.168.100.152 umgestellt wurde. Aber da weigert er sich einfach.

Neustart von Host und DHCPd wurde ausgeführt.

 

[RickyM]

Steck mal das LAN-Kabel für mindestens 10s ab, steck es wieder rein und prüfe die IP-Vergabe erneut.

 

[Mojo1987]

Du musst den alten Lease aus dem DHCP löschen. Der wird da noch drinstehen und vergibt deswegen die 170, solange wie die Leasetime nicht abgelaufen ist.

 

[Fallaxia]

Ich habe die Lease in der DHCP.leases gesucht, aber nicht gefunden, kein Eintrag zu dieser IP Adresse.
Und selbst wenn, die Lease wäre seit Tagen abgelaufen, da die Zeit auf 30 Minuten gesetzt ist.

Der Host wurde mehrfach komplett herunter gefahren, ausgeschaltet, neu gestartet, aber er fragt stets die .170 an und der blöde DHCPd gibt sie ihm auch noch.

Kann doch nicht wahr sein.

Noch Ideen?

Der Host is im Übrigen ein Debian System und selbst wenn kein DHCP Server ihm antwortet, so nimmt der die .170 nachdem ein DHCP Timeout aufgetreten ist.
Wie kann ich das unterbinden, der soll sich gefälligst eine Zeroconf Adresse zuweisen und nicht eine nehmen die er mal irgendwann gehabt hat...

 

[e-Funktion]

Am Client:

cmd.exe

ipconfig /release
ipconfig /renew

Der Host is im Übrigen ein Debian System

Edit 1: Oh Obiges gilt für Windows, wies bei Debian aussieht...da gibts sicher was vergleichbares. (hab nur bei den aktuellen themen gerade geschaut - mea culpa).


edit 2: http://forum.linuxcareer.com/threads/1635-Linux-ipconfig-equivalent Try this. Der relevante punkt ist "dhclient will release IP address for eth0 network interface and obtain new.".

 

[Fallaxia]

ja, eine neue Lease im Host zu beziehen ist kein Problem, macht er wohl auch, nur nimmt er immer die "alte" Lease wieder und der DHCPd gibt ihm ein OFFER für eine neue Lease.
Das ist ja das Problem.

 

[mensch183]

Vielleicht mal die dhcpd.conf und ggf. eine kurze Beschreibung des Netzes veröffentlichen, damit man nicht nur wild rumspekulieren kann?

Außerdem testen/sicherstellen, ob diese dhcpd.conf, die du für die richtige hältst, auch tatsächlich Verwendung findet.

 

[cbtestarossa]

kannst du für die .170 nicht ne andere mac adresse angeben?
dann die gewünschte mac neu auf die .152?

dann den dienst neustarten?

 

[Fallaxia]

Die DHCP Konfig ist funktional. Jeder andere (auch zum Test neu eingetragene Hosts) verhalten sich wie sie sollen.
Ich habe den "Problem-Host" auch mehrfach neu eingetragen um Fehler ausschließen zu können, z.B. bei der Eingabe der MAC Adresse.

Aber mein Hauptproblem ist wohl am Host selbst zu suchen. Das Debian basierte System nimmt einfach die zuletzt erfolgreich zugeteilte IP Adresse, und das selbst wenn überhaupt kein DHCP Server antwortet, sprich es reicht aus das Lan Kabel einzustecken und nach kurzem Versuch eine Lease zu erhalten (DHCP Server ist off) teilt sich das System selbst die zuletzt genutzte IP zu anstatt keine oder eine Zeroconf zu verwenden, wie es der Standard verlangt.

Wie bekomme ich den Host dazu dieses Verhalten zu unterlassen?

 

[Twostone]

Hast Du ggf. dnsmasq umkonfiguriert? Schau mal nach, ob's läuft und wie es konfiguriert ist.