Windows-Clients erhalten keine DHCP IP vom Server

[obstbauer]

Hallo Forum,

ich kann mir das Problem grade nicht erklären: Einfaches Setup: fritz.box -> mac mini Server (10.10)

Auf dem Server läuft ein DHCP Dienst welcher an alle Clients die sich über die fritz.box (feste IP, DHCP aus) verbinden eine IP ausgibt, die fritz.box hat nur die Aufgabe WLAN & DSL Verbindung bereitzustellen.

Das funktioniert mit allen "Apple" clients soweit wunderbar (MacBooks, imacs, iphones, ipads, etc.) doch sobald ein Windows Client (z.B. Win7) versucht eine Verbindung herzustellen wird das Netzwerk als "undefined" gekennzeichnet und windows bezieht keine IP / keine Zugang zum Netz / selbst zugewiesene IP, dies ist bei mehreren (allen) Windows PCs so die sich in diesem Netz verbinden wollen.

Wenn man dem Win-Client aber eine feste IP am Gerät zuweist funktioniert es natürlich.

Woran scheitert Windows da?

Danke für kleinen Tipp

OB

 

[Wuchtbrumme]

die Frage ist doch wohl ein Witz. Wie soll man das denn beantworten? Nimm einen Hub, mach einen Netzwerk-Capture mit Wireshark im Promiscous-Mode und stell das .bin-File ein, alles andere ist nur Raten.

Wie ist der Mac Mini Server konfiguriert? Was für ein Range, was für ein Interface für den DHCP-Server? Ist das konfigurierte Interface verbunden? Ist der DHCP-Server an? Bekommen andere Clients eine Lease, soll heißen, weißt Du überhaupt, dass das Dingens geht? Ist auf der Fritzbox die Kommunikation unter angeschlossenen Geräten zugelassen? Ist der Sparmodus für Ethernet auf der FB aus?

 

[obstbauer]

die Frage ist doch wohl ein Witz. Wie soll man das denn beantworten? Nimm einen Hub, mach einen Netzwerk-Capture mit Wireshark im Promiscous-Mode und stell das .bin-File ein, alles andere ist nur Raten.

Wie ist der Mac Mini Server konfiguriert? Was für ein Range, was für ein Interface für den DHCP-Server? Ist das konfigurierte Interface verbunden? Ist der DHCP-Server an? Bekommen andere Clients eine Lease, soll heißen, weißt Du überhaupt, dass das Dingens geht? Ist auf der Fritzbox die Kommunikation unter angeschlossenen Geräten zugelassen? Ist der Sparmodus für Ethernet auf der FB aus?

Hallo Wuchtbrumme,

danke für deine Antwort.

- DHCP Range 10.0.88.50-.200 auf eth0
- eth0 ist natürlich verbunden (ethernet zur FB)
- DHCP läuft, alle clients bekommen leases über WLAN (nur windows clients nicht)
- fritzbox ist auch alles auf grün d.h. angeschl. Geräte kommunizieren miteinander, sparmodus der FB-Ports aus

 

[Wuchtbrumme]

Prinzipielle Probleme mit Windows und einem auf OS X betriebenen DHCPd kenne ich nicht, habe ich aber ehrlich gesagt auch noch nicht probiert (außer, dass eine Win7-VM mit gebridgetem Netzwerkinterface vom OS X Server einwandfrei DHCP bekommt).

Der Range kommt mir etwas merkwürdig vor (was nicht heißen soll, dass es nicht geht). Was hast Du denn da für ein Subnet mit welcher Maske eingerichtet? Die Fritzbox ist im selben Netz? Läuft auf dem Windows-Client irgendeine Software, bevorzugt eine Firewall, eine Internet-Security oder sowas?

Wie sind die Netzwerkinterfaces unter Windows konfiguriert? Gibt es evtl. einen Duplex-Mismatch am Switch (der führt zu langsamem Traffic, der wiederum DHCP-Broadcasttraffic beeinflussen kann)?

Mein Tip wäre, schau Dir den Broadcast-Traffic an; am besten auf dem OS X Server und auf dem Windows-Rechner (ein Hub würde helfen) und schau, was auf dem Server im Log steht. Was für Optionen (DHCP-Parameter) sind auf dem OS X Server hinterlegt? Ich würde mit einer Basiskonfiguration (IP, Maske, Nameserver, Router, Zeitserver) starten.

 

[obstbauer]

Danke!

Hier mal die Parameter vom Server als Screenshot,
wie gesagt, alle Apple & iOS Clients bekommen problemlos leases.
Haben die WIN Clients evtl. Probleme mit der Netmask?

 

[Wuchtbrumme]

es gibt zwar CIDR, aber deswegen braucht man RFC1918 trotzdem nicht malträtieren. Ich sehe auch keinen Sinn darin, 65534 Hosts adressieren zu können. In Deinem lokalen Netz hast Du davor sowieso ganz andere Probleme.

Bei OS X habe ich bereits einige Merkwürdigkeiten bemerkt, die meiner Meinung nach auf striktem Verhalten von Subnetz-Klassen ohne Beachtung von RFC1918 basieren und sich auch um CIDR nicht scheren.

Ich würde erst einmal eine vernünftige Netzmaske verwenden; mit einem Class B (tschuldigung, Vereinfachung, um nicht immer mit CIDR...) funktioniert's.

Bevor wir hier aber groß rumsuchen: Das System ist sauber installiert, nicht irgendwie aus einem Time-Machine-Backup von Time Capsule oder so wiederhergestellt oder sonstwie verändert? Und die Einstellungen des Nertzwerkinterfaces unter Systemeinstellungen ist analog eingestellt? Wenn Du da z.B. eine 255.55.255.0 al s Maske hättest, dann wäre die Broadcast-Adresse eine ganz andere; das könnte das Verhalten erklären.Genauso gut könnte es ein Bug in Windows sein. Schwer zu sagen, wenn man nicht alle Details geliefert bekommt, die man braucht.