1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Wie Rogue DHCP-Server ermitteln?

Dieses Thema im Forum "macOS & OS X Server" wurde erstellt von stk, 30.03.10.

  1. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    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 … o_O. 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:
    Code:
    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
     
    #1 stk, 30.03.10
    Zuletzt bearbeitet: 30.03.10
  2. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    Ich fall tot um … o_O 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 :oops:. Konfiguration wie folgt:

    Fixe IPs für Ethernet und Airport Schnittstelle:
    Code:
    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:

    [​IMG]

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

    Code:
    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 :oops:.

    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 :oops:.

    Gruß Stefan
     
  3. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    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
     
  4. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    ja klar.

    hab ich gemacht, sehr gespannt bin …

    Code:
    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 o_O.

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

    Gruß Stefan
     
  5. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    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
     

Diese Seite empfehlen