DHCP-Server Antworten kommen nicht an

[balou84]

Hallo zusammen,
ich habe seit ein paar Tagen ein Problem mit meinem DHCP-Server. Seit neuestem klappt die Kommunikation zwischen meinem DHCP-Server und den Clients nicht mehr richtig. Clients fragen nach einer Adresse, aber die Antwort kommt nicht an. Auf dem Server sehe ich im Log folgendes:

Code: Alles auswählen

Sep  6 22:09:04 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:04 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:04 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:04 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:07 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:07 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:07 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:07 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:12 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:12 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:12 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:12 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:22 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:22 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0
Sep  6 22:09:22 glassbox dhcpd: DHCPDISCOVER from 94:de:80:c6:32:41 via eth0
Sep  6 22:09:22 glassbox dhcpd: DHCPOFFER on 192.168.0.7 to 94:de:80:c6:32:41 via eth0

Ich bin vorher noch nie in die Verlegenheit gekommen mir logs vom DHCP anzusehen, aber fragen die Clients immer so ungeduldig oft nach?

Ein dhcpdump am Server sagt folgendes:

Code: Alles auswählen

  TIME: 2014-09-06 22:20:46.903
    IP: 0.0.0.0 (94:de:80:c6:32:41) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: b57eca74
  SECS: 3
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 94:de:80:c6:32:41:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         1 (DHCPDISCOVER)
OPTION:  12 ( 12) Host name                 TheChosenOne
OPTION:  55 ( 18) Parameter Request List      1 (Subnet mask)
					     28 (Broadcast address)
					      2 (Time offset)
					      3 (Routers)
					     15 (Domainname)
					      6 (DNS server)
					    119 (Domain Search)
					     12 (Host name)
					     44 (NetBIOS name server)
					     47 (NetBIOS scope)
					     26 (Interface MTU)
					    121 (Classless Static Route)
					     42 (NTP servers)
					    121 (Classless Static Route)
					    249 (MSFT - Classless route)
					     33 (Static route)
					    252 (MSFT - WinSock Proxy Auto Detect)
					     42 (NTP servers)
					    
---------------------------------------------------------------------------

  TIME: 2014-09-06 22:20:46.903
    IP: 192.168.0.1 (70:71:bc:5c:be:ac) > 192.168.0.7 (94:de:80:c6:32:41)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: b57eca74
  SECS: 3
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.0.7
SIADDR: 192.168.0.1
GIADDR: 0.0.0.0
CHADDR: 94:de:80:c6:32:41:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier         192.168.0.1
OPTION:  51 (  4) IP address leasetime      1800 (30m)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   192.168.0.1
OPTION:  15 ( 14) Domainname                wiechers.local
OPTION:   6 (  4) DNS server                192.168.0.1
OPTION:  12 ( 12) Host name                 TheChosenOne
---------------------------------------------------------------------------

Müsste die Antwort des DHCP-Servers nicht auch an 255.255.255.255 gehen? Warum geht die Antwort schon an die IP und MAC des Clients der gerade fragt? Der Client müsste doch erst mal das Angebot annehmen... oder hab ich DHCP falsch verstanden?

Am Client kommen die DHCP-OFFER übrigens überhaupt nicht an. IPtables schaut auf beiden Systemen ok aus. Noch andere Möglichkeiten wo die Antworten hängen bleiben können?

Wenn jemand einen Hinweis für mich hat wo ich suchen muss... her damit und vielen Dank!

Viele Grüße

PS: DHCP Server 4.1-ESV-R4 auf Ubuntu 12.04 (3.2.0-29-generic-pae)

[dufty2]

Müsste die Antwort des DHCP-Servers nicht auch an 255.255.255.255 gehen? Warum geht die Antwort schon an die IP und MAC des Clients der gerade fragt? Der Client müsste doch erst mal das Angebot annehmen... oder hab ich DHCP falsch verstanden?

Nö, passt schon so: Es soll ja nur der eine client die .7 bekommen, alle anderen würden ja mit dieser Antwort unnötig "belästigt".

Am Client kommen die DHCP-OFFER übrigens überhaupt nicht an. IPtables schaut auf beiden Systemen ok aus. Noch andere Möglichkeiten wo die Antworten hängen bleiben können?

Wir kennen Dein Netzwerk nicht
Du kannst am Server ein tcpdump machen, um zu sehen, ob die dhcpoffers tatsächlich (nach iptables) den Server verlassen und dann ebenso am client ein tcpdump, ob jene Pakete - noch vor iptables - ankommen.

[rendegast]

Die Client-Maschinen?
Bei windows-Clients funktioniert der Vorgang wohl nur komplett, wenn auch der dhcp-(client)-Dienst läuft, 'services.msc'.

Bei netbios-Freigaben gibt es Probleme, wenn die Zeiten Server-Client stark abweichen.
(Obwohl diese Clients dabei nie Probleme hatten, von meinem dnsmasq eine IP zu bekommen)

[balou84]

Hi,
ich habe keine Windows-Clients Aber danke.

ich habe das Problem jetzt auf meinen Switch eingrenzen können. Ich habe einen TP-Link SG3216 und nutze auch die VLAN Funktion. Die Abgrenzung der VLANs funktioniert. Heute nochmal durch getestet. Die vergabe der IP-Adressen klappt aber sofort wenn ich den Switch durch nen klapprigen alten 100MBit switch ersetze.
Wie kann mein Switch darauf kommen UDP-Pakete nicht weiter zu geben? Habe keine Änderungen am Switch vorgenommen die letzten Tage...

Vielen Dank!

[dufty2]

Ich habe einen TP-Link SG3216

Ein kurzer Blick auf TP-Link-website und man sieht, dass das Teil "DHCP Snooping" kann
und könnte ergo dadurch DCHP Requests blocken.
Ob es auch tut, mmh, müsste mal anschauen

[balou84]

Hi,
also DHCP snooping kann er in der Tat. Habe ich aber nie aktiviert und (hab eben nachgesehen) auch jetzt ist es noch deaktiviert.
Ich Frage mich gerade ob sich ein FactoryReset vom Switch lohnen könnte. Andererseits bekomme ich nie raus welche Einstellung schuld war wenn der Reset hilft. Würde gern wissen was das Problem ist...
Danke!

[hec_tech]

Soviel ich sehe kann das Teil Spanning Tree.

Ist das der einzige Switch oder noch mehrere? Schalte mal die Access Ports auf Portfast. Wie das bei TP-Link heißt musst du dir anschaun.

Spanning Tree mit suboptimaler Konfiguration in Verbindung mit DHCP kann oft zu Problemen führen.

[balou84]

Hallo,
spanning tree habe ich ebenfalls nicht aktiviert. Habe das eben auch nochmal geprüft. Ich hatte es allerdings vor einigen Wochen testweise für ein paar Tage aktiv. Es kann natürlich sein das bei so einem günstigen Switch wie bei meinem die Software nicht ganz ok ist und Einstellungen nicht zuverlässig übernommen werden. Ich glaube ich sollte doch einmal einen Reset des Switches machen. Auch wenn es mir irgendwie nicht so richtig gefällt. Vielleicht hilft es ja.
Werde mal bescheid geben ob es geholfen hat. Hoffe ich komme bald mal dazu.

Viele Grüße

[balou84]

Moin,
ein Reset des Switches hat nicht weiter geholfen. Nachdem ich allerdings einen WLAN-Accesspoint vom Switch abgezogen habe funktioniert nun wieder alles bestens. Ich habe noch keine Erklärung dafür warum ein Accesspoint der Grund dafür sein kann das DHCP im Netzwerk nicht mehr funktioniert. Ein anderer DHCP-Server war auf dem Accesspoint zumindest nicht aktiv.

Viele Grüße und Danke für Eure Hilfe