DHCP server is verdwenen

[SamPep]

Ha tweakers,

Sinds gisteren loop ik spontaan tegen een probleem aan met de LAN connectie op een x870e bord (Realtek PCIe 5GbE Family Controller). De PC weigert een wired connectie te maken. Foutmelding: " No DHCP Server was found". Bijzondere is dat alleen de PC er last van heeft. PS5, Shield, TV, Win10 hebben wired nergens last van. Wireless werkt voor alles en iedereen, ook de PC die geen wired connectie kan maken.

Ik heb de volgende zaken al geprobeerd:
- Turning it off and on again
- Nieuwe internet kabel
- herinstallatie drivers lan controller
- terugdraaien win11 update
- reset router en mesh(asus)
- IPconfig /renew: die timed out
De netwerkadapter staat opgenomen in device manager. Het LAN lampje knippert geel en is oranje

Ik vermoed haast dat de lan controller stuk is, maar dan zou het ook niet in device manager moeten staan gok ik?

Alvast bedankt voor jullie inzichten!

[ Voor 55% gewijzigd door SamPep op 07-08-2025 11:22 ]

[Drardollan]

Nutteloze grap.. Als er nou nog daadwerkelijk hulp of advies volgt oké maar niet zo

[ Voor 80% gewijzigd door MasterL op 07-08-2025 14:34 ]

[Christoxz]

Wat is de output van CMD -> `ipconfig`
Je zou eventueel zelf een IP kunnen configureren, kijken of dat wel werkt.

[dion_b]

Ik twijfel sterk aan hardwareprobleem. Om dat uit te sluiten: boot eens met een LiveUSB (maakt niet uit wat, zolang je NIC maar ondersteund is. Actuele Ubuntu zou het meestal moeten doen). Ik ga ervan uit dat het dan wel gaat werken, aangezien je meestal geen link en activity ziet bij dooie NIC. Zo niet inderdaad op hardware focussen.

Als dat het wel doet, zit het probleem dus in software/configuratie. Dat kan op een paar plekken zitten:
- Windows networking in de knoop. Gebeurt deprimerend vaak. Ga naar Network & Internet, Advanced Settings en kies Network Reset. Dit zou hetzelfde moeten doen als netsh winsock reset en netsh int ip reset
- firewall ergens die verkeerd geconfigureerd is, dus ofwel DHCP discovers/offers blokkeert. Dat kan firewall op je PC zijn (de Windows firewall zou bij bovenstaande al gereset moeten zijn, evt 3rd party firewall moet je apart aanpakken) of elders in het nietwerk, bijvoorbeeld op je router.en/of mesh (welke apparaten exact? en waarom noem je mesh bij een bedrade verbinding? wat zit er allemaal tussen deze PC en de router in?). Kijk ook naar features als IP Flood Detection die soms kunnen misdragen.
- DHCP server die zelf weigert te reageren op de PC. Weinig waarschijnlijk tenzij je zelf hebt zitten hobbyen op je router (eigen firmware geinstalleerd e.d.), maar als je al het andere uitgesloten hebt iets om na te kijken.

Kom je er niet uit, installeer sowieso Wireshark op de PC en doe een capture van alle verkeer op de Ethernetadapter. Daar zou je je DHCP discover moeten zien uitgaan en kun je kijken wat er vervolgens terug komt.

[SamPep]

dion_b schreef op donderdag 7 augustus 2025 @ 11:49:
Ik twijfel sterk aan hardwareprobleem. Om dat uit te sluiten: boot eens met een LiveUSB (maakt niet uit wat, zolang je NIC maar ondersteund is. Actuele Ubuntu zou het meestal moeten doen). Ik ga ervan uit dat het dan wel gaat werken, aangezien je meestal geen link en activity ziet bij dooie NIC. Zo niet inderdaad op hardware focussen.

Als dat het wel doet, zit het probleem dus in software/configuratie. Dat kan op een paar plekken zitten:
- Windows networking in de knoop. Gebeurt deprimerend vaak. Ga naar Network & Internet, Advanced Settings en kies Network Reset. Dit zou hetzelfde moeten doen als netsh winsock reset en netsh int ip reset
- firewall ergens die verkeerd geconfigureerd is, dus ofwel DHCP discovers/offers blokkeert. Dat kan firewall op je PC zijn (de Windows firewall zou bij bovenstaande al gereset moeten zijn, evt 3rd party firewall moet je apart aanpakken) of elders in het nietwerk, bijvoorbeeld op je router.en/of mesh (welke apparaten exact? en waarom noem je mesh bij een bedrade verbinding? wat zit er allemaal tussen deze PC en de router in?). Kijk ook naar features als IP Flood Detection die soms kunnen misdragen.
- DHCP server die zelf weigert te reageren op de PC. Weinig waarschijnlijk tenzij je zelf hebt zitten hobbyen op je router (eigen firmware geinstalleerd e.d.), maar als je al het andere uitgesloten hebt iets om na te kijken.

Kom je er niet uit, installeer sowieso Wireshark op de PC en doe een capture van alle verkeer op de Ethernetadapter. Daar zou je je DHCP discover moeten zien uitgaan en kun je kijken wat er vervolgens terug komt.

Zojuist een Ubuntu 24.04.2 USB geprobeerd. Daar kreeg ik geen wired connectie. Daarna opnieuw win11 geprobeerd en alles werkt weer naar behoren. Geen idee waarom alles weer werkt, maar issue is resolved.

[dion_b]

SamPep schreef op donderdag 7 augustus 2025 @ 13:24:
[...]


Zojuist een Ubuntu 24.04.2 USB geprobeerd. Daar kreeg ik geen wired connectie. Daarna opnieuw win11 geprobeerd en alles werkt weer naar behoren. Geen idee waarom alles weer werkt, maar issue is resolved.

Een ding is duidelijk: je hardware is prima.

Ik gooi het op drivers van je netwerkkaart die de kluts kwijt waren.

Overigens misschien interessant voor andren
TS had mij ge DMmed met een Wireshark trace. Helaas zaten daar geen DHCP handshakes in, dus er was geen rechtstreeks bewijs voor wat hier mis ging, maar alles groter dan ARP, ICMPv6 of IGMPv3 had - ongeacht source IP/MAC - fouten in de 'length' fields in de headers, dingen als dit:

code:

Internet Protocol Version 4, Src: 192.168.50.190, Dst: 192.168.50.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 49
        [Expert Info (Error/Protocol): IPv4 total length exceeds packet length (45 bytes)]
    Identification: 0x29c3 (10691)
    010. .... = Flags: 0x2, Don't fragment
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x29eb [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.50.190
    Destination Address: 192.168.50.255
    [Stream index: 2]
User Datagram Protocol, Src Port: 58078, Dst Port: 32412
    Source Port: 58078
    Destination Port: 32412
    Length: 29 (bogus, payload length 25)
        [Expert Info (Error/Malformed): Bad length value 29 > IP payload length]
    Checksum: 0x40ec [unverified]
    [Checksum Status: Unverified]
    [Stream index: 2]
    [Stream Packet Number: 1]
    [Timestamps]
    UDP payload (17 bytes)

Gezien het ongeacht source optrad moet dit aan ontvangende kant gebeuren, dus in de NIC in de PC, of in ieder geval in z'n drivers. Kan goed verklaren waarom binnenkomende pakketten niet goed verwerkt werden.

Verder was de router ARP requests aan het spammen (ongeveer 10 per seconde) en was er ook een sloot aan uPnP SSDP-verkeer, maar die zullen IMHO niets met DHCP-probleem te maken hebben gehad.

[RonnieKo]

SamPep schreef op donderdag 7 augustus 2025 @ 11:14:
Sinds gisteren loop ik spontaan tegen een probleem aan met de LAN connectie op een x870e bord (Realtek PCIe 5GbE Family Controller). De PC weigert een wired connectie te maken. Foutmelding: " No DHCP Server was found". Bijzondere is dat alleen de PC er last van heeft. PS5, Shield, TV, Win10 hebben wired nergens last van. Wireless werkt voor alles en iedereen, ook de PC die geen wired connectie kan maken.

Altijd mooi als er Nederlands en Engels door elkaar gebruikt wordt.... Of alles beter wordt als je Engelse termen gebruikt

Over het probleem: Je hebt waarschijnlijk op één of andere manier een loop in je PC. Veel nieuwe netwerkswitchen hebben de mogelijkheid om dat te detecteren. Zet de draadloze verbinding op de PC uit. Dan zal je geen probleem meer hebben.

Dit probleem had ik ook niet onder windows 10 met mijn laptop. Sinds een paar maand met Windows 11 op de laptop wel. Blijkbaar schakelt de wifi niet automatisch helemaal uit. Sinds ik in Windows 11 de wifi even handmatig uitzet als ik een netwerkkabel in de laptop heb zitten is het probleem weg.

[MasterL]

dion_b schreef op donderdag 7 augustus 2025 @ 15:57:
[...]

Een ding is duidelijk: je hardware is prima.

Ik gooi het op drivers van je netwerkkaart die de kluts kwijt waren.

Overigens misschien interessant voor andren
TS had mij ge DMmed met een Wireshark trace. Helaas zaten daar geen DHCP handshakes in, dus er was geen rechtstreeks bewijs voor wat hier mis ging, maar alles groter dan ARP, ICMPv6 of IGMPv3 had - ongeacht source IP/MAC - fouten in de 'length' fields in de headers, dingen als dit:

code:

Internet Protocol Version 4, Src: 192.168.50.190, Dst: 192.168.50.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 49
        [Expert Info (Error/Protocol): IPv4 total length exceeds packet length (45 bytes)]
    Identification: 0x29c3 (10691)
    010. .... = Flags: 0x2, Don't fragment
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x29eb [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.50.190
    Destination Address: 192.168.50.255
    [Stream index: 2]
User Datagram Protocol, Src Port: 58078, Dst Port: 32412
    Source Port: 58078
    Destination Port: 32412
    Length: 29 (bogus, payload length 25)
        [Expert Info (Error/Malformed): Bad length value 29 > IP payload length]
    Checksum: 0x40ec [unverified]
    [Checksum Status: Unverified]
    [Stream index: 2]
    [Stream Packet Number: 1]
    [Timestamps]
    UDP payload (17 bytes)

Gezien het ongeacht source optrad moet dit aan ontvangende kant gebeuren, dus in de NIC in de PC, of in ieder geval in z'n drivers. Kan goed verklaren waarom binnenkomende pakketten niet goed verwerkt werden.

Verder was de router ARP requests aan het spammen (ongeveer 10 per seconde) en was er ook een sloot aan uPnP SSDP-verkeer, maar die zullen IMHO niets met DHCP-probleem te maken hebben gehad.

In dit voorbeeld zijn er alleen broadcast pakketten te zien:
Src: 192.168.50.190 Dst: 192.168.50.255 (broadcast address)
Wat is 192.168.50.190 voor device en waarom stuurt deze zoveel broadcast packages?
De melding "Bad length value" lijkt toch wel op een MTU mismatch, ik heb dit vaak genoeg gezien bij VM's waarbij na een update de MTU (opeens) verlaagd werd. In een normaal LAN zouden deze meldingen niet voor moeten komen, jumbo frames uitgesloten draait alles normaal op 1500bytes.
Alles zou toch in 1 broadcast domain moeten zitten?

Edit:
Beetje Google, ik gok dat 192.168.50.190 Plex draait.
https://forums.plex.tv/t/...-32414-and-32412/65443/11
Dit zou het probleem toch niet kunnen ziijn?

Vind het idee van @RonnieKo ook helemaal niet gek een loop zou prima kunnen zeker met een niet goed geconfigureerd mesh setje.

[ Voor 5% gewijzigd door MasterL op 08-08-2025 15:02 ]

[SamPep]

.190 is inderdaad de Nvidia shield, waarop o.a. plex draait.

Toen dit probleem zich voor deed had ik de wlan overigens nog niet aangesloten op mn mobo. Pas toen de lan verbinding het niet deed, ben ik wifi gaan gebruiken.

Ik draai overigens geen asuswrt merlin, maar ook de routers/mesh hebben de afgelopen maanden geen nieuwe firmware gekregen.

De bad value lenght melding is inmiddels overigens verdwenen uit wireshark.