Wie Rogue DHCP-Server ermitteln?

[stk]

Moin,

ich hab seit einiger Zeit ein paar Probleme mit dem Bezug von IPs via DHCP. Konkret: nach Neustart der Clients kriegen die keine gültige IP zugewiesen, sondern landen auf einer Bonjour-Adresse. Erst ein einloggen in einen lokalen Account und das anfordern eines neuen Releases liefert eine gültige (für den Rechner im OS X DHCP-Server fix vergebene) IP aus.

Ein Verdacht richtet sich gegen das 10.5.8 v1.1 Update des OS X Servers, der den Fehler mit der angeblich mehrfach vergebenen Seriennummer im Netz einfängt. Nach dem Update war das Verhalten der Clients zu beobachten.

Der zweite Verdacht wäre, das da noch irgendein Gerät (auch wenn ich keine Idee habe welches) noch als DHCP-Server im Netz rumbrüllt. Für Windows habe ich genügend Hinweise auf DHCP_loc u.ä. Tools gefunden (die unter Parallels und Konsorten jedoch unbrauchbar sind). Für Linux gibt es DHCP-probe. Der Versuch das Teil für den Mac zu kompilieren schlägt bei mir jedoch regelmässig fehl, auch mit per MacPorts installierter libnet. Frage daher: hat jemand o.g. Linux-Tool schon mal auf dem Mac ans Laufen gebracht oder gibt es etwas anderes mit dem man das Netz durchforsten kann? ipconfig liefert ja nur den aktuellen DHCP Server … kommt wohl nicht in Frage … . Oder kann jemand den v1.1-Verdacht bestätigen und hat dafür eine Lösung?

[edith]Der Grund warum ich auf Rogue DHCP komme - Eintrag im system.log des Servers:

Mar 30 08:30:43 tiger bootpd[59167]: dhcpd: INIT-REBOOT host 1,0:25:0:f7:dc:8f binding for 192.168.2.151 with another server

[/edith]

Gruß Stefan

 

[stk]

Ich fall tot um … Apple kann's einfach nicht …

Es ist in der Tat der OS X Server. Der DHCP-Server schert sich nicht um die Zuweisung des en-Ports, sondern brüllt auf allen Kanälen . Konfiguration wie folgt:

Fixe IPs für Ethernet und Airport Schnittstelle:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet6 fe80::211:24ff:fe7c:72de%en0 prefixlen 64 scopeid 0x4 
	inet 192.168.2.111 netmask 0xffffff00 broadcast 192.168.2.255
	ether 00:11:24:7c:72:de 
	media: autoselect (1000baseT <full-duplex,flow-control>) status: active
	supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,flow-control> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,flow-control> 100baseTX <full-duplex,hw-loopback> 1000baseT <full-duplex> 1000baseT <full-duplex,flow-control> 1000baseT <full-duplex,hw-loopback>
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
	lladdr 00:11:24:ff:fe:7c:72:de 
	media: autoselect <full-duplex> status: inactive
	supported media: autoselect <full-duplex>
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet6 fe80::211:24ff:fe96:7a92%en1 prefixlen 64 scopeid 0x6 
	inet 192.168.2.112 netmask 0xffffff00 broadcast 192.168.2.255
	ether 00:11:24:96:7a:92 
	media: autoselect status: active
	supported media: autoselect

DHCP ist angewiesen auf der Ethernetschnitte (en0) Leases zu verteilen:

In meiner unendlichen Ungeduld hab ich meinen Lenovo Hackintosh zerlegt und die Windowsplatte wieder eingebaut dhcploc von M$ geladen und angeworfen. Ergebnis:

C:\DOKUME~1\STK>dhcploc 192.168.2.126 192.168.2.111 d
08:36:12   OFFER (IP)192.168.2.137 (S)192.168.2.111
08:36:12   OFFER (IP)192.168.2.137 (S)192.168.2.112 ***

*** ist der, der da nix zu suchen hat .

Fazit: Apple schafft es in einem Update einen Fehler der durch die Verwendung mehrerer Schnittstellen auf einem Server zu fixen und einen anderen mit der gleichen Ursache wahlweise einzubauen oder zu übersehen .

Gruß Stefan

 

[pepi]

Hast beide Interfaces vom Xserve in der selben Broadcast Domain hängen?

Den Bug hat Apple seit 10.5.0 und der ist in 10.6.2 noch immer nicht vollständig behoben. Freu Dich also damit noch länger Spaß zu haben!

Ein Ding kannst probieren, das hat bei mir zumindest bei manchen Installationen geholfen:
[tt]sudo touch /etc/bootptab[/tt] und dann den DHCP Server restarten.
Definiere auf jeden Fall für beide Interfaces je ein Subnet und aktiviere nur eines davon.

Was Du auch noch machen kannst, was aber heikler ist, am 2. Interface die Ports 67/udp und 68/udp blocken, damit dort keine Anfragen rein- und rausgehen können.
Gruß Pepi

 

[stk]

Hast beide Interfaces vom Xserve in der selben Broadcast Domain hängen?

ja klar.

Ein Ding kannst probieren, das hat bei mir zumindest bei manchen Installationen geholfen:
[tt]sudo touch /etc/bootptab[/tt] und dann den DHCP Server restarten.
Definiere auf jeden Fall für beide Interfaces je ein Subnet und aktiviere nur eines davon.

hab ich gemacht, sehr gespannt bin …

Mar 30 13:59:46 tiger bootpd[62176]: Loaded 0 entries from bootptab (0 bad)
Mar 30 13:59:46 tiger bootpd[62176]: server name tiger.redaktiv.lan
Mar 30 13:59:46 tiger bootpd[62176]: interface en0: ip 192.168.2.111 mask 255.255.255.0
Mar 30 13:59:46 tiger bootpd[62176]: interface en1: ip 192.168.2.112 mask 255.255.255.0
Mar 30 13:59:47 tiger bootpd[62176]: DHCP REQUEST [en0]: 1,0:25:4b:bc:fd:d6 <maxi>
Mar 30 13:59:47 tiger bootpd[62176]: domain search added
Mar 30 13:59:47 tiger bootpd[62176]: replying to 192.168.2.150
Mar 30 13:59:47 tiger bootpd[62176]: ACK sent 150 maxi.redaktiv.lan 192.168.2.150 pktsize 363
Mar 30 13:59:47 tiger bootpd[62176]: service time 0.013140 seconds
Mar 30 13:59:47 tiger bootpd[62176]: DHCP REQUEST [en1]: 1,0:25:4b:bc:fd:d6 <maxi>
Mar 30 13:59:47 tiger bootpd[62176]: dhcpd: INIT-REBOOT host 1,0:25:4b:bc:fd:d6 binding for 192.168.2.150 with another server
Mar 30 13:59:47 tiger bootpd[62176]: service time 0.004190 seconds
Mar 30 13:59:49 tiger bootpd[62176]: DHCP REQUEST [en0]: 1,0:25:0:f7:dc:8f <maxi>
Mar 30 13:59:49 tiger bootpd[62176]: domain search added
Mar 30 13:59:49 tiger bootpd[62176]: replying to 192.168.2.151
Mar 30 13:59:49 tiger bootpd[62176]: ACK sent 150 maxi.redaktiv.lan 192.168.2.151 pktsize 363
Mar 30 13:59:49 tiger bootpd[62176]: service time 0.015528 seconds
Mar 30 13:59:49 tiger bootpd[62176]: DHCP REQUEST [en1]: 1,0:25:0:f7:dc:8f <maxi>
Mar 30 13:59:49 tiger bootpd[62176]: dhcpd: INIT-REBOOT host 1,0:25:0:f7:dc:8f binding for 192.168.2.151 with another server
Mar 30 13:59:49 tiger bootpd[62176]: service time 0.005846 seconds

sprich: auch jetzt scheint die zweite Schnitte noch DHCP spielen zu wollen .

Dann werd ich die AP-Schnittstelle doch noch komplett umkonfigurieren …

Gruß Stefan

 

[pepi]

Tja… dann fällt mir akut auch nix mehr ein. Das Problem kommt und geht manchmal. Hab ich bei einem Kunden auch so. Es ist zum Auswachsen… Apple ignoriert sämtliche BugReports am Radar leider auch. 2. Interface abstecken, oder die ipfw davor hochziehen.
Gruß Pepi