Sinds een paar dagen heb ik gemerkt dat mijn Windows systemen (3 stuks) geen een van allen via Lan een ip-adres krijgen, via Wifi gaat het wel goed. Ook heb ik een paar Linux systemen waar alles wel normaal functioneert. Ik heb al van alles geprobeerd.

• Alles volgens de beschrijving herstart modem uit en spanningsloos, Pon spanningsloos, na 30 sec (was wel meer dan 1 min) pon herstart, hierna wederom 1 a 2 min modem opgestart. Resultaat hetzelfde.
• vervolgens een keer een zelfde herstart maar nu met het modem naar de fabrieks instellingen gebracht. Resultaat weer het zelfde.
• Ook ondanks het me vreemd lijkt dat alle Windows systemen het zelfde hebben toch de instellingen gewijzigd van automatisch DHCP naar statisch ip-adres Resultaat wederom het zelfde.
• Terug naar Automatisch DHCP wederom het zelfde resultaat.
• Vervolgens via CMD met administrator rechten de commando’s netsh winsock reset, netsh int ip reset, ipconfig /release, ipconfig /renew, ipconfig /flushdns met de nodige herstarts van het systeem. Resultaat wederom hetzelfde.
• De kabels voor de zekerheid getest ondanks dat de netwerk poorten de juiste leds aangaven, de test van de kabels waren ook allemaal goed met een utp kabel tester.

Het systeem krijgt steeds het ip-adres 169.254.208.225 met subnet mask 255.255.0.0

In de log van de T-54 komt dan regelmatig de volgende melding voor ( ik heb de node naam, ip-adres en mac adres zelf in deze meldings weergave gewijzigd. Deze meldingen komen dan om de paar seconden voor.

Dec     23 15:40:23         daemon     debug     dhcpd     dnsmasq-dhcp: ip lease:X.X.X.134, given to MAC:X:X:X:X:X:X, with hostname:Naam van het systeem, Lease time:167347
21     Dec 23 15:40:23     daemon     info     dhcpd     dnsmasq-dhcp: sendLeaseMessageToESMD
22     Dec 23 15:40:13     daemon     debug     dhcpd     dnsmasq-dhcp: sendLeaseMessageToESMD esmd ret=1
23     Dec 23 15:40:13     daemon     debug     dhcpd     dnsmasq-dhcp: ip lease:X.X.X.133, given to MAC:X:X:X:X:X:X, with hostname:Naam van het systeem, Lease time:167333
24     Dec 23 15:40:13     daemon     info     dhcpd     dnsmasq-dhcp: sendLeaseMessageToESMD
25     Dec 23 15:40:13     daemon     info     dhcpd     dnsmasq-dhcp: DHCPDECLINE(br0) X.X.X.X X:X:X:X:X:X
26     Dec 23 15:40:10     daemon     debug     dhcpd     dnsmasq-dhcp: sendLeaseMessageToESMD esmd ret=1
27     Dec 23 15:40:10     daemon     debug     dhcpd     dnsmasq-dhcp: ip lease:X.X.X.133, given to MAC:X:X:X:X:X:X, with hostname:Naam van het systeem, Lease time:167333
28     Dec 23 15:40:10     daemon     info     dhcpd     dnsmasq-dhcp: sendLeaseMessageToESMD
29     Dec 23 15:40:00     daemon     debug     dhcpd     dnsmasq-dhcp: sendLeaseMessageToESMD esmd ret=1

Dit alles is volgens mij ontstaan na de herstart samen met de klantenservice en ondanks wat ik allemaal heb getest en gedaan ben ik redelijk aan het einde van wat ik nog meer zou kunnen doen.

Wellicht is er iemand van de community die hier wel raad mee weet dan zou ik het fijn vinden om hier kennis van te mogen nemen.

Ik blijf het dus vreemd vinden dat er na de herstart de Linux systemen nergens last van hebben en al de Windows systemen wel terwijl bij de herstart de systemen niet aan het modem/router hingen.

Ik wacht eerst even af of iemand het ei van columbus heeft voordat ik op een Windows systeem adapters en stuursoftware ga verwijderen en weer proberen opnieuw te installeren omdat ik het vreemd vind dat ze allemaal last hebben van dit euvel.

Alvast bedankt allen voor het mee denken en delen van informatie hiervoor. Het hoort misschien niet op de community maar toch ik  wens een ieder nog fijne feestdagen en gelukkig Nieuw jaar

Nog een aanvulling op het eerdere.

Sorry voor mijn slordigheid maar dat van statische ip-adres klopt niet helemaal, natuurlijk kreeg het windows systeem een ip-adres echter kreeg ik geen positief ping resultaat terug van b.v. www.odido.nl of van het ip adres hiervan (om dns uit te sluiten). Wel kon ik mijn lan systemen pingen.

Wat mij inmiddels ook is opgevallen dat als ik maar lang genoeg de Windows pc via UTP vast laat zitten dat er na een tijd een ip-adres wordt verkregen dat vervolgens niet gedeclined wordt. Deze periode kan wel 30 minuten duren (gisteren) vandaag was het 10 minuten.

Als ik dan vervolgens een ping naar www.odido.nl doe duurt het ongeveer nog 1 minuut voordat er een reply komt van www.odido.nl of te wel 20.56.240.229 zie hieronder .

24-12-2023 13:05:22 - Pinging www.odido.nl [20.56.240.229] with 32 bytes of data:

24-12-2023 13:05:25 - Request timed out.

24-12-2023 13:05:30 - Request timed out.

24-12-2023 13:05:35 - Request timed out.

24-12-2023 13:05:40 - Request timed out.

24-12-2023 13:05:45 - Request timed out.

24-12-2023 13:05:50 - Request timed out.

24-12-2023 13:05:56 - Request timed out.

24-12-2023 13:06:00 - Request timed out.

24-12-2023 13:06:05 - Request timed out.

24-12-2023 13:06:10 - Request timed out.

24-12-2023 13:06:15 - Request timed out.

24-12-2023 13:06:20 - Request timed out.

24-12-2023 13:06:21 - Reply from 20.56.240.229: bytes=32 time=6ms TTL=116

24-12-2023 13:06:22 - Reply from 20.56.240.229: bytes=32 time=7ms TTL=116

24-12-2023 13:06:23 - Reply from 20.56.240.229: bytes=32 time=7ms TTL=116

24-12-2023 13:06:24 - Reply from 20.56.240.229: bytes=32 time=7ms TTL=116

24-12-2023 13:06:25 - Reply from 20.56.240.229: bytes=32 time=6ms TTL=116

24-12-2023 13:06:26 - Reply from 20.56.240.229: bytes=32 time=6ms TTL=116

24-12-2023 13:06:27 - Reply from 20.56.240.229: bytes=32 time=6ms TTL=116

24-12-2023 13:06:28 - Reply from 20.56.240.229: bytes=32 time=7ms TTL=116

24-12-2023 13:06:29 - Reply from 20.56.240.229: bytes=32 time=6ms TTL=116

24-12-2023 13:06:30 - Reply from 20.56.240.229: bytes=32 time=7ms TTL=116

Zoals ik eerder heb aangegeven dat ik het commando ipconfig /renew in windows heb gegeven kreeg ik voor de duidelijkheid onderstaande melding.

C:\WINDOWS\system32>ipconfig /renew (met administrator rechten)

Windows IP Configuration

An error occurred while renewing interface Ethernet 2 : De DHCP-client heeft een IP-adres gekregen dat reeds in het netwerk in gebruik is. De lokale interface wordt uitgeschakeld totdat de DHCP-client een nieuw adres kan worden toegewezen.

Echter het ip-adres was in het netwerk niet aanwezig was niet te pingen.

Dus is mijn vermoeden dat DHCP niet lekker verloopt. Ik heb mijn test Windows pc inmiddels opnieuw geïnstalleerd maar dat gaf geen verbetering.

Ik blijf dus tot er iets anders is aangewezen de schuld bij het modem/router liggen.

Dubbele DHCP na het opstarten van de Zyxel kan ontstaan doordat er in het erachter liggende netwerk een andere DHCP server actief is of is geworden (slapend aanwezig) en

Lees hier over 169.254.xx,xx Ip adressen en de DHCP fouten en waardoor deze kunnen ontstaan

Koppel het eigen netwerk los, schakel alle apparaten uit.

Start de Zyxel op en wacht voldoende tijd totdat deze helemaal opgestart is.

Probeer hierna apparaat, pc, laptop, wifi uitbreidingen en dergelijke op te starten.
Statische adres toewijzingen kun je het beste doen door het MAC adres van een apparaat in de Zyxel te koppelen aan een IP adres. zie Thuisnetwerk → Statische DHCP.
Op deze wijze is het niet nodig IP range uitsluiting in te stellen. De router weet welk adres “bezet” is.

Bij schakelen tussen utp en wifi en sowieso tussen netwerken is de optredende vertraging afhankelijk van het apparaat waar de omschakeling op uitgevoerd wordt. Achtergrond processen en prioriteiten in de daarop draaiende services zijn daarin de vertragende factoren. Zelfs de command line ipconfig is een proces wat op zijn beurt moet wachten en WIndows of Linux kan andere prioriteiten hebben.

utp en wifi verbonden tegelijk verbonden hebben en zelfs in dat geval kost schakelen wat tijd.

Hoi Yalerta,

Bedankt voor je reactie. Inderdaad uiteindelijk een Extender die de boos doener was. Ik kon de Extender gewoon bereiken en ook de achterliggende systemen. En ook gaf deze aan dat DHCP uit stond. Nadat ik de  Extender had verplaatst blijkt alles weer te functioneren zoals het hoort. Hierna de Extender weer terug geplaatst en blijkt alles nog steeds te functioneren zoals het hoort. Waarom de 3 Windows systemen steeds klaagde over dubbele ip-adres en mijn Linux systemen niet  is mij nog steeds een raadsel. De problemen zijn waarschijnlijk ontstaan door dat de kerstverlichting aangesloten moest worden. Dit was op de spanningslof waar ook de Extender aangesloten was. Wellicht iets met de Extender toen gebeurt. Ik houd hem voor de zekerheid toch nog een tijdje in de gaten. Maar voor nu nogmaals bedankt voor je reactie.

Met netwerken is het inderdaad soms lastig op de juiste plaatsen de lampjes aan te krijgen en op de goede manier. Daar is kerstverlichting wat makkelijker in

Zelf heb ik wel bemerkt dat Windows systemen trager reageren bij netwerk wijzigingen. Om te zeggen dat dit altijd zo is is teveel gezegd.

Fijn dat het nu werkt en hopelijk blijft dat zo na het weer inpakken van de kerstlampjes.