22
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 52664361491
Url: https://administrator.de/contentid/52664361491
Ausgedruckt am: 24.11.2024 um 23:11 Uhr
22 Kommentare
Neuester Kommentar
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?
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.
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,
https://de.wikipedia.org/wiki/Zeroconf
https://wiki.wireshark.org/DHCP
https://www.der-windows-papst.de/2019/02/26/dhcp-ueberwachungsprotokolli ...
Gruss,
Peter
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.das zweite Netz (also das 192.168.1.223), das den NACK erhält ist die von den Clients selbst erwähle IP-Adresse
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ürdigNur 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 gruessenIch 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 sindIch 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/ZeroconfGruss,
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:
Soviel für mich als Laien nicht in allem zu Verstehenden, das als Reqeust vom Client losgeschickt wurde
und das ACK
Dann DHCP Offer
Bis hier also genau das was sein sollte...
Client: DHCP Inform
Dann macht der Client ein ACK
ACK ist m.W. ein Acknowledge (Bestätigung)
und die zeigt...
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
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: 255Soviel 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: 255Bis 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: 000000000000000000Dann 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…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
und im DHCP Offer taucht ein Fehler auf:
und dann informiert der Client - auch über die nach wie vor vorhandene fehlerhafte IP Adresse
DCHP Inform
Soweit, was ich beobachten konnte.
Es scheinen die Clients zu sein, aber es kam mit dem Wechsel auf DHCP Server 2016
Grüsse
Alex
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: 255und 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: 255DCHP 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: 000000000000000000Soweit, 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:
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!?
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)
< code > blablublubb </code > (ohne die Leerzeichen)
hallo em-pi
ich versuche das mal zu machen.
Ja, das ist cool....
Grüsse
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
aus dem System-Eventlog des Clients
Die Adresse nach IPConfig /all
Grüsse
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) 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 . . . . . . . : AktiviertGrü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
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
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
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.
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.Ich versuche es nochmal:
Zitat von @em-pie:
Das passt aber nicht. Dein
Was steckt hinter dieser IP?
Ein Router o.ä.?
Gemeint ist hier: wer hat die 192.168.1.1 inne?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.ä.?
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,
Gruss,
Peter
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.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
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
und ja, jetzt antwortet der DHCP antwortet schnell und präzise
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
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.
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 . . . . . . . : Aktiviertund 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 = 0msUnd 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
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,
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.)
https://de.wikipedia.org/wiki/Namensaufl%C3%B6sung
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
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.
https://de.wikipedia.org/wiki/MAC-Adresse
Gruss,
Peter
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.1Und 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 NetzmaskenUnd 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 minuteUnd 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 Serverhttps://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
bei einem ping auf 192.168.1.1 kommt
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.
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=53Ping 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...
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.
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
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
