Mar 30, 2024

1409

Server 2016 DHCP ein Client verliert Lease NACH Erneuern

Hallo
ich habe ein Netz aus VMWare-Maschinen - den bisherigen Domnänenkontroller (DC) habe ich von Server 2008R2 auf Server 2016 umgezogen (Ich weis Server 2016 läuft aus, reicht aber für mich vollkommen aus)
Das DHCP habe ich per Backup und Restore auf den neuen Server umgezogen.
Nachdem alles rd 10 Tage lief, gabs Schwierigkeiten mit den Adressleases. Die Clients erhielten keine Adressen und verwendeten folgerichtig privat erstellte Adressen. Für ein dann anfallenden Leaserequest erhielten Sie ein NACK - während manche einfach eine Adresse erhielten.
15,03/29/24,15:45:47,NACK,192.168.1.223,,CCF73542AF4E,,0,6,,,,,,,,,0
15,03/29/24,15:45:59,NACK,192.168.1.200,,AC1F6B0508B0,,0,6,,,,,,,,,0
15,03/29/24,15:46:14,NACK,192.168.1.200,,AC1F6B0508B0,,0,6,,,,,,,,,0
15,03/29/24,15:46:40,NACK,192.168.1.223,,CCF73542AF4E,,0,6,,,,,,,,,0
11,03/29/24,15:46:43,Erneuern,192.168.100.53,amazon-514593cb2.anonymisiert.de,CCF73542AF4E,,2058600827,0,,,,0x616E64726F69642D646863702D372E312E32,android-dhcp-7.1.2,,,,0
15,03/29/24,15:46:48,NACK,192.168.1.200,,AC1F6B0508B0,,0,6,,,,,,,,,0

Ein NeuStarten des DHCP blieb erfolglos.
Ich habe nun die Lease-Dauer auf 12 Std verringert und die Clients ausgeschalten - damit klappte das Erneuern der Leases von fast allen Clients:

Dann eine Überraschung (beide Geräte sind Internetradios)

15,03/29/24,18:35:09,NACK,192.168.1.200,,AC1F6B0508B0,,0,6,,,,,,,,,0
10,03/29/24,18:35:12,Zuweisen,192.168.100.40,,AC1F6B0508B0,,1299488745,0,,,,0x756468637020312E31322E30,udhcp 1.12.0,,,,0
10,03/29/24,18:39:30,Zuweisen,192.168.100.43,,3801465A6369,,836012027,0,,,,0x756468637020312E31352E32,udhcp 1.15.2,,,,0
15,03/29/24,18:41:06,NACK,192.168.1.225,,3801465A6369,,0,6,,,,,,,,,0
15,03/29/24,18:41:39,NACK,192.168.1.225,,3801465A6369,,0,6,,,,,,,,,0

Das Gerät erhielt seine Adresse, ich kontne auch zuhören wie eine abgehackte Radioverbindung entstand und dann weg war.

Wie kann sowas vorkommen?

Grüsse
Alex. Bierig

Please also mark the comments that contributed to the solution of the article

Content-Key: 52664361491

Url: https://administrator.de/contentid/52664361491

Printed on: May 9, 2024 at 00:05 o'clock

22 Comments

Latest comment

Moin,

Ich sehe zwei verschiedene IP Netze: wer routet zwischen den Netzen?
Wird dort DHCP-Relay verwendet? Stimmt die IP des DCs?
Wobei dann erst gar keine Pakete ab DHCP ankommen dürften.

Nutzt ihr Radius/ NPS/ 802.1x?
Mal die InternetRadios komplett neu gestartet. Drucker (so meine Beobachtung) „freuen“ sich auch immer, wenn plötzlich jemand anderes DHCP spielt. Die musst ich in der Vergangenheit dann immer einmal neu starten.

Hast du auch mal ins Eventlog des DHCP-Server geschaut?

Hallo em-pie

das zweite Netz (also das 192.168.1.223), das den NACK erhält ist die von den Clients selbst erwähle IP-Adresse, die sie sich nehmen, wenn sie keine DHCP-Antwort erhalten.
Der gewollte und mit dem autorisierten Server Bereich geht von 192.168.100.1-192.168.100.254 - davon sind von der Verteilung ausgeschlossen die Endadressen 1-39 (diverse Server und auch der Drucker) und 245-254 (die IPs des WLAN Routers und der Repeater fürs MESH)
Wir sind viel zu klein für Radius/ NPS/ 802.1x - also nein wir nutzen davon nichts. Wir haben einen Webserver im Netz stehen (zwecks Lernen und Üben PHP<->SQL), mehr nicht.
Und der DC ist auch DNS- und DHCP-Server
Ich habe die Radios und auch zwei Smartphones x-mal neu gestartet - dennoch klappt es nicht.
Das Eventlog des DHCP Server habe ich angeschaut - es gibt keine Einträge.
Nur die im Log des DHCP
Überrascht hat mich, dass das Gerät erfolgreich eine IP-des lokalen Netztes bekam und zwei Minuten später wieder mit dieser blöden privaten Adresse ums Eck bog. (Heute übrigens wieder trotz einer 20Std Stromlos-Zeit)

Ich weis nicht, wie Clients das genau machen:
Ich dachte immer die rufen ins lokale Netz: Hallo DHCP Server...und wenn der antwortet, fordern sie eine IP-Adresse an und erhalten die auch.
Unklar ist mir wieso die Clients (auch Windows 10 Rechner) eine selbst generierte IP (z.Bsp.:192.168.1.223) präsentieren, die dann logischerweise nicht zur Verlängerung freigegeben wird.
Das Ärgerliche: Ich bin von Server 2008R2 auf Server 2016 umgestiegen (muss ja mal irgendwann sein) - unter dem 2008R2 Server hatte ich keinerlei Probleme.

Grüsse
Alex.

Hallo,

Zitat von @Alex.Bierig:
das zweite Netz (also das 192.168.1.223), das den NACK erhält ist die von den Clients selbst erwähle IP-Adresse

Die Clients geben sich nicht selbst eine IP aus dem 192.168.1.0 sondern wenn überhaupt dann eine IP aus dem APIPA Bereich, also 169,254.1.0 bis 169.254.254.255.
https://de.wikipedia.org/wiki/Zeroconf

die sie sich nehmen, wenn sie keine DHCP-Antwort erhalten.

Soweit richtig, da viele Software und OSe nicht mehr arbeiten wenn eben keine IP existiert.

Ich habe die Radios und auch zwei Smartphones x-mal neu gestartet - dennoch klappt es nicht.

Einmal den Kabelhai laufen gelassen hätte dir gezeigt was ein client anfragt und bekommt wenn eine IP (neue oder verlängerung einer IP) per DHCP verlangt wird.
https://wiki.wireshark.org/DHCP

Das Eventlog des DHCP Server habe ich angeschaut - es gibt keine Einträge.

Du hast keine Eintraege in dein Ereignissprotokoll vom Server 2016? Merkwürdig

Nur die im Log des DHCP

https://www.itprotoday.com/compute-engines/how-do-i-enable-dhcp-server-l ...
https://www.der-windows-papst.de/2019/02/26/dhcp-ueberwachungsprotokolli ...

Überrascht hat mich, dass das Gerät erfolgreich eine IP-des lokalen Netztes bekam und zwei Minuten später wieder mit dieser blöden privaten Adresse ums Eck bog. (Heute übrigens wieder trotz einer 20Std Stromlos-Zeit)

Wireshark lässt gruessen

Ich weis nicht, wie Clients das genau machen:

Per Magie und vielen Vermutungenen und manche Clients nutzen auch 7 seitige Würfel oder Orakeln wenn die mit KI ausgestattet sind

Ich dachte immer die rufen ins lokale Netz: Hallo DHCP Server...und wenn der antwortet, fordern sie eine IP-Adresse an und erhalten die auch So ist es. Auch hier hilft dir ein Kabelhai und zeigt dir die genaue Kommunikation

Unklar ist mir wieso die Clients (auch Windows 10 Rechner) eine selbst generierte IP (z.Bsp.:192.168.1.223)

https://de.wikipedia.org/wiki/Zeroconf

Gruss,
Peter

Hallo Peter

ich habe den Kabelhai auf diesem Client hier und auf dem DNS Server installiert und protokolliert, was passiert wenn ich
ipconfig /release
ipconfig /renew
mache.
Was da kommt ist für mich ein Buch mit (naja fast) sieben Siegeln.
Dieser Client hier, mit dem ich arbeite, bekam heute auch keine IP des lokalen Netzes, sondern nur die selbst generierte... (warum auch immer, da er gestern die heute wieder angebotene hatte)

Und! ich habe ausführlich dargelegt, was ich gefunden habe, evtl willst Du das gar nicht alles lesen 8-))

Wie gesagt: Diese Schwierigkeiten habe ich erst, nachdem ich den DC/DNS/DHCP von Server 2008R2 nach Server 2016 umgezogen habe - über 2 Tage hin, damit dei Synchonisationen durchlaufen konnten.

Was dann dieser Client beim Request machte:

Frame 1157: 378 bytes on wire (3024 bits), 378 bytes captured (3024 bits) on interface \Device\NPF_{CFCB9CAD-789C-40EC-98FB-F0B21EDDBFAE}, id 0
Ethernet II, Src: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 364
    Identification: 0x2afe (11006)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x0e84 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 0.0.0.0 (0.0.0.0)
    Destination Address: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 344
    Checksum: 0x10d1 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 191]
    [Timestamps]
    UDP payload (336 bytes)
Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x5ca21e11
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Request)
        Length: 1
        DHCP: Request (3)
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Option: (50) Requested IP Address (192.168.1.201)
        Length: 4
        Requested IP Address: programme64.local (192.168.1.201)
    Option: (54) DHCP Server Identifier (192.168.1.1)
        Length: 4
        DHCP Server Identifier: 192.168.1.1 (192.168.1.1)
    Option: (12) Host Name
        Length: 11
        Host Name: programme64
    Option: (81) Client Fully Qualified Domain Name
        Length: 32
        Flags: 0x00
        A-RR result: 0
        PTR-RR result: 0
        Client name: programme64.anonymisiert.de
    Option: (60) Vendor class identifier
        Length: 8
        Vendor class identifier: MSFT 5.0
    Option: (55) Parameter Request List
        Length: 12
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
        Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
        Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
        Parameter Request List Item: (31) Perform Router Discover
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
        Parameter Request List Item: (43) Vendor-Specific Information
    Option: (255) End
        Option End: 255

Soviel für mich als Laien nicht in allem zu Verstehenden, das als Reqeust vom Client losgeschickt wurde

und das ACK

Frame 1158: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) on interface \Device\NPF_{CFCB9CAD-789C-40EC-98FB-F0B21EDDBFAE}, id 0
Ethernet II, Src: D-Link_f7:11:ae (00:1c:f0:f7:11:ae), Dst: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst: programme64.local (192.168.1.201)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 576
    Identification: 0x0000 (0)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0xf492 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.1.1 (192.168.1.1)
    Destination Address: programme64.local (192.168.1.201)
User Datagram Protocol, Src Port: 67, Dst Port: 68
    Source Port: 67
    Destination Port: 68
    Length: 556
    Checksum: 0x695e [unverified]
    [Checksum Status: Unverified]
    [Stream index: 49]
    [Timestamps]
    UDP payload (548 bytes)
Dynamic Host Configuration Protocol (ACK)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x5ca21e11
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: programme64.local (192.168.1.201)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (ACK)
        Length: 1
        DHCP: ACK (5)
    Option: (54) DHCP Server Identifier (192.168.1.1)
        Length: 4
        DHCP Server Identifier: 192.168.1.1 (192.168.1.1)
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (60s) 1 minute
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Length: 4
        Router: 192.168.1.1 (192.168.1.1)
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: 192.168.1.1 (192.168.1.1)
    Option: (15) Domain Name
        Length: 9
        Domain Name: dlink.com
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…

Dann DHCP Offer

Frame 1159: 357 bytes on wire (2856 bits), 357 bytes captured (2856 bits) on interface \Device\NPF_{CFCB9CAD-789C-40EC-98FB-F0B21EDDBFAE}, id 0
Ethernet II, Src: VMware_7f:4f:28 (00:0c:29:7f:4f:28), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: mailer.anonymisiert.de (192.168.100.1), Dst: 255.255.255.255 (255.255.255.255)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 343
    Identification: 0x1911 (6417)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0xfbdb [validation disabled]
    [Header checksum status: Unverified]
    Source Address: mailer.anonymisiert.de (192.168.100.1)
    Destination Address: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 67, Dst Port: 68
    Source Port: 67
    Destination Port: 68
    Length: 323
    Checksum: 0x99c3 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 192]
    [Timestamps]
    UDP payload (315 bytes)
Dynamic Host Configuration Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x5ca21e11
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: programme64.anonymisiert.de (192.168.100.46)
    Next server IP address: mailer.anonymisiert.de (192.168.100.1)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (58) Renewal Time Value
        Length: 4
        Renewal Time Value: (86400s) 1 day
    Option: (59) Rebinding Time Value
        Length: 4
        Rebinding Time Value: (151200s) 1 day, 18 hours
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (172800s) 2 days
    Option: (54) DHCP Server Identifier (192.168.100.1)
        Length: 4
        DHCP Server Identifier: mailer.anonymisiert.de (192.168.100.1)
    Option: (15) Domain Name
        Length: 18
        Domain Name: anonymisiert.de
    Option: (3) Router
        Length: 4
        Router: rd250.de (192.168.100.24)
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: mailer.anonymisiert.de (192.168.100.1)
    Option: (44) NetBIOS over TCP/IP Name Server
        Length: 4
        NetBIOS over TCP/IP Name Server: mailer.anonymisiert.de (192.168.100.1)
    Option: (46) NetBIOS over TCP/IP Node Type
        Length: 1
        NetBIOS over TCP/IP Node Type: H-node (8)
    Option: (255) End
        Option End: 255

Bis hier also genau das was sein sollte...
Client: DHCP Inform

Frame 1286: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{CFCB9CAD-789C-40EC-98FB-F0B21EDDBFAE}, id 0
Ethernet II, Src: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: programme64.local (192.168.1.201), Dst: 255.255.255.255 (255.255.255.255)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 328
    Identification: 0x2b49 (11081)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x4beb [validation disabled]
    [Header checksum status: Unverified]
    Source Address: programme64.local (192.168.1.201)
    Destination Address: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 308
    Checksum: 0xc3b6 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 215]
    [Timestamps]
    UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Inform)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x3a655afa
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: programme64.local (192.168.1.201)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Inform)
        Length: 1
        DHCP: Inform (8)
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Option: (12) Host Name
        Length: 11
        Host Name: programme64
    Option: (60) Vendor class identifier
        Length: 8
        Vendor class identifier: MSFT 5.0
    Option: (55) Parameter Request List
        Length: 13
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
        Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
        Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
        Parameter Request List Item: (31) Perform Router Discover
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
        Parameter Request List Item: (43) Vendor-Specific Information
        Parameter Request List Item: (252) Private/Proxy autodiscovery
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000

Dann macht der Client ein ACK
ACK ist m.W. ein Acknowledge (Bestätigung)
und die zeigt...

Frame 1287: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) on interface \Device\NPF_{CFCB9CAD-789C-40EC-98FB-F0B21EDDBFAE}, id 0
Ethernet II, Src: D-Link_f7:11:ae (00:1c:f0:f7:11:ae), Dst: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst: programme64.local (192.168.1.201)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 576
    Identification: 0x0000 (0)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0xf492 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.1.1 (192.168.1.1)
    Destination Address: programme64.local (192.168.1.201)
User Datagram Protocol, Src Port: 67, Dst Port: 68
    Source Port: 67
    Destination Port: 68
    Length: 556
    Checksum: 0x8ee5 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 49]
    [Timestamps]
    UDP payload (548 bytes)
Dynamic Host Configuration Protocol (ACK)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x3a655afa
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: programme64.local (192.168.1.201)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (ACK)
        Length: 1
        DHCP: ACK (5)
    Option: (54) DHCP Server Identifier (192.168.1.1)
        Length: 4
        DHCP Server Identifier: 192.168.1.1 (192.168.1.1)
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Length: 4
        Router: 192.168.1.1 (192.168.1.1)
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: 192.168.1.1 (192.168.1.1)
    Option: (15) Domain Name
        Length: 9
        Domain Name: dlink.com
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…

Da ich in der Konsole sehen konnte, dass das nichts war mit der korrekten IP, habe ich das nochmals gemacht,

Irgendwann (ohne Protokollierung)
ipconfig / release
ipconfig /all (klar eine private IP)
ipconfig /renew
und ups...gut wars...

fortsetzung wegen Zeilenbegrenzung

Grüsse
Alex

Hallo Peter

Fortsetzung wegen Zeilenbegrenzung

ich habe den Kabelhai auf diesem Client hier und auf dem DNS Server installiert und protokolliert, was passiert wenn ich
ipconfig /release
ipconfig /renew
mache.
Was da kommt ist für mich ein Buch mit (naja fast) sieben Siegeln.

und nun der Mitschnitt vom DHCP (auf dem DC)
(nicht zeitgleich)

das DISCOVER kam als erstes, dann DHCP Request

Frame 5279: 378 bytes on wire (3024 bits), 378 bytes captured (3024 bits) on interface \Device\NPF_{2D8F5CF9-9E1F-4334-A25F-35D561FF6CDD}, id 0
Ethernet II, Src: programme64.local (30:9c:23:d6:b3:45), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x6c8bea07
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: programme64.local (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Request)
        Length: 1
        DHCP: Request (3)
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: programme64.local (30:9c:23:d6:b3:45)
    Option: (50) Requested IP Address (192.168.1.201)
        Length: 4
        Requested IP Address: programme64.local (192.168.1.201)
    Option: (54) DHCP Server Identifier (192.168.1.1)
        Length: 4
        DHCP Server Identifier: 192.168.1.1 (192.168.1.1)
    Option: (12) Host Name
        Length: 11
        Host Name: programme64
    Option: (81) Client Fully Qualified Domain Name
        Length: 32
        Flags: 0x00
        A-RR result: 0
        PTR-RR result: 0
        Client name: programme64.anonymisiert.de
    Option: (60) Vendor class identifier
        Length: 8
        Vendor class identifier: MSFT 5.0
    Option: (55) Parameter Request List
        Length: 12
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
        Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
        Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
        Parameter Request List Item: (31) Perform Router Discover
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
        Parameter Request List Item: (43) Vendor-Specific Information
    Option: (255) End
        Option End: 255

und im DHCP Offer taucht ein Fehler auf:

Frame 5282: 357 bytes on wire (2856 bits), 357 bytes captured (2856 bits) on interface \Device\NPF_{2D8F5CF9-9E1F-4334-A25F-35D561FF6CDD}, id 0
Ethernet II, Src: maileranonymisiert.de (00:0c:29:7f:4f:28), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: mailer.anonymisiert.de (192.168.100.1), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Dynamic Host Configuration Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x6c8bea07
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: programme64.anonymisiert.de (192.168.100.46)
    Next server IP address: mailer.anonymisiert.de (192.168.100.1)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: programme64.local (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (58) Renewal Time Value
        Length: 4
        Renewal Time Value: (86400s) 1 day
    Option: (59) Rebinding Time Value
        Length: 4
        Rebinding Time Value: (151200s) 1 day, 18 hours
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (172800s) 2 days
    Option: (54) DHCP Server Identifier (192.168.100.1)
        Length: 4
        DHCP Server Identifier: mailer.anonymisiert.de (192.168.100.1)
    Option: (15) Domain Name
        Length: 18
        Domain Name: anonymisiert.de
    Option: (3) Router
        Length: 4
        **Router: kenny-bika.de (192.168.100.24)  ===>Fehler: Der Router ist //OPNSense// (192.168.100.24) **steht auch so im DNS. kenny-bika.de ist eine gehostete Domain
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: mailer.anonymisiert.de (192.168.100.1)
    Option: (44) NetBIOS over TCP/IP Name Server
        Length: 4
        NetBIOS over TCP/IP Name Server: mailer.anonymisiert.de (192.168.100.1)
    Option: (46) NetBIOS over TCP/IP Node Type
        Length: 1
        NetBIOS over TCP/IP Node Type: H-node (8)
    Option: (255) End
        Option End: 255

und dann informiert der Client - auch über die nach wie vor vorhandene fehlerhafte IP Adresse
DCHP Inform

Frame 5753: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{2D8F5CF9-9E1F-4334-A25F-35D561FF6CDD}, id 0
Ethernet II, Src: programme64.local (30:9c:23:d6:b3:45), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: programme64.local (192.168.1.201), Dst: 255.255.255.255 (255.255.255.255)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 328
    Identification: 0x5f59 (24409)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set  
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x17db [validation disabled]
    [Header checksum status: Unverified]
    Source Address: programme64.local (192.168.1.201)
    Destination Address: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
    Source Port: bootpc (68)
    Destination Port: bootps (67)
    Length: 308
    Checksum: 0xea53 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 590]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Inform)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xe6130768
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: programme64.local (192.168.1.201)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: programme64.local (30:9c:23:d6:b3:45)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Inform)
        Length: 1
        DHCP: Inform (8)
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: programme64.local (30:9c:23:d6:b3:45)
    Option: (12) Host Name
        Length: 11
        Host Name: programme64
    Option: (60) Vendor class identifier
        Length: 8
        Vendor class identifier: MSFT 5.0
    Option: (55) Parameter Request List
        Length: 13
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
        Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
        Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
        Parameter Request List Item: (31) Perform Router Discover
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
        Parameter Request List Item: (43) Vendor-Specific Information
        Parameter Request List Item: (252) Private/Proxy autodiscovery
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000

Soweit, was ich beobachten konnte.

Es scheinen die Clients zu sein, aber es kam mit dem Wechsel auf DHCP Server 2016

Grüsse
Alex

Moin,

Beim Überfliegen habe ich das hier gesehen:

Domain Name: dlink.com

Ist sichergestellt, dass du keine zwei DHCP-Server aktiv hast?
Also nicht, dass da noch irgendein Router/ vermeidlicher AccessPoint (falsch) aktiv ist?

Was passiert, wenn du am Server den DHcP-Dienst beendest und dann mal einen (anderen) Client neustartest!?

P.S. Bitte deine Ergebnisse in Code-Tags setzen:
< code > blablublubb </code > (ohne die Leerzeichen)

hallo em-pi
ich versuche das mal zu machen.

Ja, das ist cool....

Grüsse

Hallo
Was passiert, wenn du am Server den DHcP-Dienst beendest und dann mal einen (anderen) Client neustartest!?
dann kriegt der Client seine private Adresse, der sich selbst gibt und jammert rum, dass er sich nicht anmelden könne

Zeitüberschreitung bei der Namensauflösung für den Namen _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.anonymisiert.de, nachdem keiner der konfigurierten DNS-Server geantwortet hat.
Zeitüberschreitung bei der Namensauflösung für den Namen isatap.anonymisiert.de, nachdem keiner der konfigurierten DNS-Server geantwortet hat.
Zeitüberschreitung bei der Namensauflösung für den Namen WMS-WIN7.anonymisiert.de, nachdem keiner der konfigurierten DNS-Server geantwortet hat.
Aufgrund eines Ermittlungsfehlers konnte von "NtpClient" kein Domänenpeer als Zeitquelle festgelegt werden. In 3473457 Minuten wird ein weiterer Versuch ausgeführt und das Intervall für weitere Versuche anschließend verdoppelt Fehler: Der Eintrag wurde nicht gefunden. (0x800706E1)  

aus dem System-Eventlog des Clients

Die Adresse nach IPConfig /all

Ethernet-Adapter LAN WMS-Win7:

   Verbindungsspezifisches DNS-Suffix: dlink.com
   Beschreibung. . . . . . . . . . . : Intel(R) PRO/1000 MT-Netzwerkverbindung
   Physikalische Adresse . . . . . . : 00-0C-29-27-F1-7A
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::64a3:4a72:92f1:d01c%10(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.226(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Montag, 1. April 2024 13:51:07
   Lease läuft ab. . . . . . . . . . : Montag, 1. April 2024 14:03:06
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6-IAID . . . . . . . . . . . : 234884137
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2A-B4-08-5A-00-0C-29-27-F1-7A

   DNS-Server  . . . . . . . . . . . : 192.168.1.1
   Primärer WINS-Server. . . . . . . : 192.168.100.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Grüsse

Hallo em-pie,

ich bins mir sehr sicher, dass kein weiterer DHCP-Server da ist (siehe vorherige Antwort)

woher der DNS-Suffix dlink.com kommt, ist mir noch nicht klar.
Ich konnte den Eintrag nicht unter den Computern im AD finden, auch nicht in der Registry des Domänenkontrollers
Grüsse

dann kriegt der Client seine private Adresse, der sich selbst gibt und jammert rum, dass er sich nicht anmelden könne

Das passt aber nicht. Dein ipconfig /all sagt ja, dass der Client seine IP von dem DHCP-Server mit der IP 192.168.1.1 erhalten hat.
Was steckt hinter dieser IP?
Ein Router o.ä.?

Hallo em-pie,

aber es gibt wohl an einigen Clients einen Tunneladapter isatap.dlink.com

Tunneladapter isatap.dlink.com:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: dlink.com
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

C:\Users\Administrator>   

an einem WIN 7 Client ein gnadenloses Entfernen aus der Registry hat nicht geholfen (also Client wieder restored)

Aber diesen dlink.com finde ich in der Registry an vielen Stellen als DHCP Server udn DHCP Domain.

Grüsse

Beantworte doch bitte einmal die obigen Fragen, anstatt hier unkoordiniert irgendwas Neues einzustreuen

Hallo em-pie

Beantworte doch bitte einmal die obigen Fragen, anstatt hier unkoordiniert irgendwas Neues einzustreuen
sorry, das kommt durch Überschneidungen - ich versuche die Ergebensse zu Deinen Fragen zu sammeln - deswegen.

also:
ich habe KEINEN zweiten DHCP Server laufen (jedenfalls kein mir bekanntes Gerät)
wenn ich das richtige DHCP stoppe, meckern die Cients, dass keine Namensauflösung geht
Ich hatte mal einen DLINK Router als Repeater im WLAN, weil da das Mesh nicht wollte ist er rausgeflogen (liegt in der Ecke)
Aktuell gibt es ein MESH von Fritz mit zwei Repeatern von Fritz - diese Fritzbox hängt (wie ein normaler Client) hinter der Firewall. Sie macht KEIN DHCP oder ähnliches - die beiden Repeater auch nicht

Ich finde in der Registry des Clients ganz klar den DLINK.COM als DHCP und Domain für DHCP eingetragen - zusammen mit der IP 192.168.1.1
Weis nicht, wieso das auf zwei Smartphones Auswirkung haben kann (aber tut) und auf zwei andere nicht. Ebenso, wie bei drei Internetradios zwei laufen und der dritte nicht.

In der Registry taucht das dlink.com als Netzwerkliste im Intranet auf und auch direkt als TCPIP\Parameter

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Tcpip\Parameters]
"ICSDomain"="mshome.net"  
"SyncDomainWithMembership"=dword:00000001  
"NV Hostname"="WMS-WIN7"  
"DataBasePath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\  
  00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\
  64,00,72,00,69,00,76,00,65,00,72,00,73,00,5c,00,65,00,74,00,63,00,00,00
"NameServer"=""  
"ForwardBroadcasts"=dword:00000000  
"IPEnableRouter"=dword:00000000  
"Domain"="anonymisiert.de"  
"Hostname"="WMS-WIN7"  
"SearchList"=""  
"UseDomainNameDevolution"=dword:00000001  
"EnableICMPRedirect"=dword:00000001  
"DeadGWDetectDefault"=dword:00000001  
"DontAddDefaultGatewayDefault"=dword:00000000  
"EnableWsd"=dword:00000001  
"QualifyingDestinationThreshold"=dword:00000003  
"EnableIPAutoConfigurationLimits"=dword:00000001  
"NV Domain"="anonymisiert.de"  
"DhcpDomain"="dlink.com"  
"DhcpNameServer"="192.168.1.1"  

Wenn der DHCP-Server den Request kriegt, mach er ein korrektes Offer einer Adresse, die der Client (siehe das furchtbar viele von WireShark weiter oben)

Ich weis nicht, wie ich die Reg-Einträge (das ist nicht meine Welt) loswerden kann, ohne dass manche Software (ipconfig) nicht mehr streikt.
Ich habe auch keine Ahnung, ob da ein Trojanisches Pferd irgendwo ist, einen SCAN dazu muss ich erst noch umsetzen

So ein Murks.

Grüsse

Beantworte doch bitte einmal die obigen Fragen, anstatt hier unkoordiniert irgendwas Neues einzustreuen

sorry, das kommt durch Überschneidungen - ich versuche die Ergebensse zu Deinen Fragen zu sammeln - deswegen.

Die Überschneidung beträgt doch aber keine 3,5h...

Ich versuche es nochmal:

Zitat von @em-pie:
Das passt aber nicht. Dein ipconfig /all sagt ja, dass der Client seine IP von dem DHCP-Server mit der IP 192.168.1.1 erhalten hat.
Was steckt hinter dieser IP?
Ein Router o.ä.?

Gemeint ist hier: wer hat die 192.168.1.1 inne?
Ist das Gerät anpingbar?

Würde ein (Windows-) CLient keinen DHCP-Server finden, so würde er eine IP, beginnend mit 169.254.xx.yy erhalten (Stichwort: APIPA)

Hallo,

Zitat von @Alex.Bierig:
ich habe KEINEN zweiten DHCP Server laufen (jedenfalls kein mir bekanntes Gerät)

Ich muss dich enttäuschen. Da läuft tatsächlich ein DHCP Server (auch wenn du es nicht weisst oder wahrhaben willst). Pinge mit den Client der nun eine 19.168.1.x IP hat diesen DHCP Server (der hat tatsächlich die IP 192.168.1.1) an und schau nach welche MAC zurückgegeben wird. Die ersten 3 Byte der MAC kennzeichnen den NIC Hersteller. Dann gehst du gedanklich deine Hardware Gerät für Gerät durch. Und nein. ein DHCP Server macht nicht die grosse Lila Lampe an. Im Wireshark kannst du auch dessen MAC sehen.

wenn ich das richtige DHCP stoppe, meckern die Cients, dass keine Namensauflösung geht

Wenn du einen DHCP Server stoppst dann bekommen keine Geräte mehr eine IP.Ob die dann resultierende APIPA reicht um deinen DNS korrekt zu befragen ist dann ein ganz anderes Problem und ist ein DNS Problem, kein DHCP Problem.

Ich hatte mal einen DLINK Router als Repeater im WLAN, weil da das Mesh nicht wollte ist er rausgeflogen (liegt in der Ecke)

Wenn da keine LAN Kabel gesteckt sind, wollen wir davon nichts wissen (und du auch nicht)

Aktuell gibt es ein MESH von Fritz mit zwei Repeatern von Fritz - diese Fritzbox hängt (wie ein normaler Client) hinter der Firewall. Sie macht KEIN DHCP oder ähnliches - die beiden Repeater auch nicht

Wäre neu das eine FritzBox kein DHCP Server kann. Aber der DHCP Server kann tatsächlich ausgeschaltet werden. Auch ein M. Sch........ konnte kein rennen fahren mit dem Auto wo der Motor ausgebaut war.

Ich finde in der Registry des Clients ganz klar den DLINK.COM als DHCP und Domain für DHCP eingetragen - zusammen mit der IP 192.168.1.1

Und die MAC ist was? Am Client (wenn er eine IP ala 192.168.1.x hat) im CMD Fenster ein getmac.

Weis nicht, wieso das auf zwei Smartphones Auswirkung haben kann (aber tut) und auf zwei andere nicht. Ebenso, wie bei drei Internetradios zwei laufen und der dritte nicht.

Weil die IPs aus einem 192.168.1.0/24 und einen 192.168.100.0/24 Netz kommunizieren (miteinander reden) können, nur wenn ein entsprechend konfigurierter Router dazwischen hängt...

Wenn der DHCP-Server den Request kriegt, mach er ein korrektes Offer einer Adresse, die der Client (siehe das furchtbar viele von WireShark weiter oben)

Bei DHCP antworten alle DHCP Server und nur der schnellste gewinnt. Daher soll auch immer nur ein (1) DHCP Server existieren. Highlander: Es kann nur einen geben.

So ein Murks.

Sagte mein Opa auch immer beim reparieren seines Gogos, aber er war auch Fliesenleger mit Schwerpunkt Tratsch

Gruss,
Peter

Hallo miteinander

danke erstmal für Eure Mühen

irgendwie bediene ich das Forum manchmal falsch, ich drücke wohl nicht immer auf Antwort senden...8-(
Somit sind manche meiner Antworten nicht angekommen -sorry hierfür.

zu dem DHCP Server 168.100.1.1 der da rumgeistert
er ist nicht anpingbar - dann fiel der Groschen!
War aber Anwenderfehler, damit ich im Forumschreiben kann muss ich mit einer "richtigen" IP unterwegs sein (sonst wirds nichts mit der Namensauflösung), die ich händisch eingetragen habe. Sonst kann ich das Forum nicht erreichen
Manchmal sieht man den Wald vor lauter Bäumen...

Also...
Netzkarte deaktiviert und dann wieder aktiviert

C:\Windows\system32>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : programme64
   Primäres DNS-Suffix . . . . . . . : anonymisiert.de
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : anonymisiert.de
                                       dlink.com

Ethernet-Adapter LAN-Programme:

   Verbindungsspezifisches DNS-Suffix: dlink.com
   Beschreibung. . . . . . . . . . . : Intel(R) I211 Gigabit Network Connection
   Physikalische Adresse . . . . . . : 30-9C-23-D6-B3-45
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::346d:8fe3:b8fb:4f8b%11(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.201(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Dienstag, 2. April 2024 16:35:34
   Lease läuft ab. . . . . . . . . . : Dienstag, 2. April 2024 16:38:34
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6-IAID . . . . . . . . . . . : 238066723
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-23-8D-BB-33-30-9C-23-D6-B3-45
   DNS-Server  . . . . . . . . . . . : 192.168.1.1
   Primärer WINS-Server. . . . . . . : 192.168.100.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

und ja, jetzt antwortet der DHCP antwortet schnell und präzise

C:\Windows\system32>ping 192.168.1.1

Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.1: Bytes=32 Zeit=1ms TTL=64

Ping-Statistik für 192.168.1.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

Und ich habe die Fritzbox gestern mehrfach geprüft, da ist kein DHCP an (würde ja auch in den Bereich 192.168.178.xxx gehen)

Und danke, mit Hilfe von WireShark habe ich die MAC-Adresse des fraglichen DHCP-Server erhalten

Ethernet II, Src: D-Link_f7:11:ae (00:1c:f0:f7:11:ae), Dst: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
    Destination: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
        Address: Micro-St_d6:b3:45 (30:9c:23:d6:b3:45)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: D-Link_f7:11:ae (00:1c:f0:f7:11:ae)
        Address: D-Link_f7:11:ae (00:1c:f0:f7:11:ae)
		
		[...]

    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (60s) 1 minute
	

Mit einer wirklich sehr kurzen Leasedauer

Jetzt fahre ich alle Maschinen, auch den richtigen DC, runter und suche nach dem ominösen Gerät
Auf dem Client, mit dem ich normalerweise arbeite gibt es jedenfalls keinen DHCP-Server Dienst, nur den Client-Dienst.

Grüsse und bis demnächst

Alex.

Hallo,

Zitat von @Alex.Bierig:
zu dem DHCP Server 168.100.1.1 der da rumgeistert
er ist nicht anpingbar

Dafür kann es die verschiedensten Gründe geben. Im einfachsten fall ist es ihm untersagt auf ein ICMP Request (Ping anforderung) zu antworten. Oder ist vom 192.168.100.0 Netz einfach nicht erreichbar (es fehlt der entsprechende Router usw.)

War aber Anwenderfehler, damit ich im Forumschreiben kann muss ich mit einer "richtigen" IP unterwegs sein (sonst wirds nichts mit der Namensauflösung), die ich händisch eingetragen habe. Sonst kann ich das Forum nicht erreichen

Hast du eine Spezielle Zange um deine Hose zuzumachen? Es gibt keine richtig oder falsche IP Adressen. https://de.wikipedia.org/wiki/IP-Adresse Und Namensauflösung hat nichts mit DHCP zu tun. https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Der_DH ...
https://de.wikipedia.org/wiki/Namensaufl%C3%B6sung

Netzkarte deaktiviert und dann wieder aktiviert

Überflüssige Aktion

   DNS-Suffixsuchliste . . . . . . . : anonymisiert.de
                                       dlink.com

Ethernet-Adapter LAN-Programme:

   Verbindungsspezifisches DNS-Suffix: dlink.com
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   Primärer WINS-Server. . . . . . . : 192.168.100.1

Daher kommen deine vielen D-Link.com eintragungen in deiner Registrierung
Und warum noch einen WINS - und dann noch im nicht erreichbaren IP Netz, das 192.168.100.0

und ja, jetzt antwortet der DHCP antwortet schnell und präzise

Klar, sonst hättest du auch keine IP per diesen DHCP Server erhalten. ohne Router keine Kommunikation zwischen Netz 192.168.1.0 und Netz 192.168.100.0mit jeweils /24 Netzmasken

Und ich habe die Fritzbox gestern mehrfach geprüft, da ist kein DHCP an (würde ja auch in den Bereich 192.168.178.xxx gehen)

Kommt halt drauf wie deine FritzBox konfiguriert ist. kann aber muss nicht.

    Source: D-Link_f7:11:ae (00:1c:f0:f7:11:ae)
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (60s) 1 minute

Unsinnige Lease Time
Und auch https://macvendors.com/ sagt das es ein D-Link gerät sein sollte. Wo das steht/liegt musst du selbst rausfinden. Und je nach Konfiguration kann es auch sein das es nicht auf Pings antwortet.

Jetzt fahre ich alle Maschinen, auch den richtigen DC, runter und suche nach dem ominösen Gerät

Sollte wie bei D-Link üblich auch auf dessen Gehäuse D-Link stehen haben.

Auf dem Client, mit dem ich normalerweise arbeite gibt es jedenfalls keinen DHCP-Server Dienst, nur den Client-Dienst.

Weil es eben ein Hardware Gerät ist. D-Link hat zwar auch software, aber keinen eigenen DHCP Server
https://de.wikipedia.org/wiki/MAC-Adresse

Gruss,
Peter

Hallo Peter,
danke für Deine Mühen

ich habe im ganzen Haus wirklich KEIN DLINK Gerät vorhanden (ausser den ausser Betrieb genommenen DLINK Router, der zählt aber nicht, alles andere ist von Netgear und Fritz)

Ich verwende seit SBS 4.5 den Adressbereich 192.168.100.1-192.168.100.254 (192.168.100.1/24)
Darin vergebe ich mittels DHCP an Clients, wie auch smartphone, Internetradio, TV, Firestick, Medienserver, Tablett und Geräte von Besuchern per DHCP Adresse, einen Teil habe ich für Server ausgeschlossen (192.168.100.1-192.168.100.40).
Es gibt einen Server (feste IP 192.168.100.7, kein Domänenmitglied und dadrauf liegt der Rest als VMWare) Er hat 12 Netzwerkkarten (IBM) von denen 10 nur der VMWare zugeordnet sind (nur VMWare Karten Treiber aus dem virtuellem VMWare Netzwerk)
Der von mir benutzte Client kriegt meistens 192.168.100.46 als IP und kann 192.168.1.1 nicht anpingen und nicht finden. Damit ich via Firewall ins Internet kann muss der Client in dem Adressbreich des Firewallserver liegen (192.168.100.24), der auch als Gateway angegeben ist. Alle Geräte müssen darüber ins Internet, nur dieser Firewall (OPNSense) hat ein Kabel zum WAN.
Um den (bisher nicht gefundenen DHCP zu finden) muss ich den Client in den Bereich von 192.168.1.x bringen. Am schnellsten geht das bei den derzeitigen Schwierigkeiten zur Deaktivieren/Aktivieren der Netzwerkkarte.
Wenn ich nun von diesen Notebook hier (192.168.100.56 per DHCP, der Domain Kontroller hat 192.168.100.1)
ping dlink.com absetze, kommt

Ping wird ausgeführt für dlink.com [104.20.74.106] mit 32 Bytes Daten:
Antwort von 104.20.74.106: Bytes=32 Zeit=34ms TTL=53

bei einem ping auf 192.168.1.1 kommt

Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.

setze ich den Client manuell in das Netz von 192.168.1.1 als Beispiel 192..168.1.10
dann läuft es genau umgekehrt.
ping DLINK.COM wird nicht aufgelöst
Ping 192.168.1.1 dageben läuft

ohne Router keine Kommunikation zwischen Netz 192.168.1.0 und Netz 192.168.100.0mit jeweils /24 Netzmasken
Eine verbindung dieser Netze ist von mir ja auch nicht gewollt, denn dann tauchen Fehler (welcher Art auch immer) auf. Und das ist m.E. gut so.

Kommt halt drauf wie deine FritzBox konfiguriert ist. kann aber muss nicht.
klar, stimmt schon, aber ich habe definitiv auf der Fritzbox KEIN DHCP an und sie hat die feste IP 192.168.100.250

Daher rede ich von "richtigen" IP-Adressen (das sind die, aus dem von mir definiertem Bereich)

Sollte wie bei D-Link üblich auch auf dessen Gehäuse D-Link stehen haben.
Das Schlimme ist, es gibt kein DLINK-Gerät im Haus (evtl eine D-Link Netzkarte in einem der alten PCs, die als Datengrab dienen und nur manchmal per Wake-on-LAN gestartet werden. Keiner dieser PCs hat die MAC Adresse, die vom fraglichen DLINK DHCP Server (00:1c:f0:f7:11:ae))

Ich habe gestern meiner Frau erklärt, warum das Internet und E-Mail aktuell nicht gehen, dass wir einen "Geister-Rechner" im Haus haben.

Es riecht so, auch wenn es nicht sein kann (weil nicht sein kann, was nicht sein darf 8-)) ), als ob ich mir auf dem Client, an dem ich normalerweisearbeite, einen Trojaner oder sowas gefangen habe.
Ich habe diesen Client heute bewusst ausgeschalten gelassen und alle Clients, die mit der dynamsichen IP-Adress-Anfrage in den Bereich 168.100.1.1 landeten, haben nun eine "richtige" Adresse erhalten.

Auch wenn die vier Netzwerkkarten des fraglichen Clients (zwei physikalische, zwei virtuelle von VM-Ware) nicht die MAC Adresse des Server 168.100.1.1 haben und die Dienstübersicht keinen DHCP Server anzeigt, scheint genau dadrauf einer zu laufen und zwar mit der MAC Adresse 00:1c:f0:f7:11:ae.

Ich habe nun drei Tage einen Voll-Scan laufen lassen, es wurden einige Trojaner gefunden (die mit Bilderdownlaods mitkamen), die sich alle löschen liesen.
Aber sonst nichts.
Jetzt probiere ich es mal mit dem c't Sicherheitsstick, vielleicht ist der Kaspersky Virusscanner doch verseucht.

Danke für Deine Mühen

Grüsse Alex.

Ich gehe von einem Firmennetzwerk aus!?
Mal daraüber nachgedacht, das irgendein Depp einen Router mitgebracht hat, weil er mit seinem Handy WLAN haben will?

Hast du managebare Switche im Einsatz?
Wenn ja: suche dort nach der MAC-Adresse. Die kann dir den Port anzeigen, auf dem die MAC gesichtet wurde...

Hallo em-pie

es war mal Firmennetzwerk, jetzt liegt es bei mir - ich bin Rentner und betreue noch ein paar wenige Kollegen und Kunden (Datenbanken SQL-Server). Die sind bereits Rentner oder werden es dieses Jahr voll.

Es konnte kein "Künstler" einen Router mitbringen, den ich im Serverräumchen nicht entdecke. Und auch an anderen Stellen mit LAN Dosen steckt nichts, was da nicht hingehört. Bins tatsächlich gestern kontrollieren gewesen. Unser Youngster hatte einen 5G/WLAN Router mit gebracht, den habe ich weg geschlossen.
Aber ich habe eine managbaren Netgear Switch (den ich noch nie gemanaged habe), da muss ich die Unterlagen rausfischen und mal sehen, was da wie zu machen ist auf seinem Sonderport. Da ich jetzt einige Tage weg muss, werdet Ihr Anfang kommende Woche von mir lesen.

Bis dahin: Angenehme Tage und ein schönes Wochenende.

Grüsse
Alex.

Hallo em-pie,
hallo Peter

ich danke Euch nochmals für die Geduld und Mühen, die Ihr Euch gegeben habt.
Und - Asche auf mein Haupt, es gab tatsächlich einen sehr gut versteckten D-Link Router im Netz.
Es ist ein D-Link DVG-5121SP 2-Port VoIP-Telefonadapter (TA).
Der war/ist fürs FAX-Gerät notwndig, damit das FAX übers Netz auf das VOIP zugreifen kann.
Folgerichtig war er am FAX auf seiner Rückseite mit Klettband angeheftet. Entdeckt habe ich ihn, als ich dieTelefone abgeklappert habe, ob da der Router irgendwo herkommt.
Den Router stromlos gemacht - Problem gelöst.

Unklar ist mir jedoch, wieso der Router jetzt erst, nach über sechs Jahren Betrieb, aktiv wurde.
OK, er kann schon immer aktiv gewesen sein, das würde dann u.U. bedeuten, dass der DHCP-Server des Servers 2008 R2 wesentlich schneller antwortete als der D-Link das tat. Und dass der DHCP-Server des jetzt aktiven Servers 2016 langsamer antwortet als der des D-Link.

Mangels aufgeschriebener/oder verlegter Zugangsdaten musste ich einen Hardwarereset machen und muss den SIP-Router nun erneut konfigurieren.

Danke nochmals für Euer Fachwissen und die wertvollen Links.

Mit freundlichen Grüssen
Alex. Bierig

German solved General Microsoft Windows Server

Hotly discussed

Wireguard with systemd and nftablesLinuxero - 9 Comments