Userbase

Bij een stroompanne vandaag was mijn laptop klok gereset na het opstarten. Niks abnormaals op zich, er steekt geen batterij in en het bios batterijtje is leeg, dus als ie geen AC heeft dan verliest ie zijn klok.
Maar bij het proberen syncen van de systeemklok via windows' ingebouwde NTP sync kreeg ik niks dan timeouts, welke server ik ook probeerde.
Heb effe via een freeware proggy (newton) een aantal NTP servers getest in round-robin stijl, maar newton heeft timeouts op alle servers in zijn config lijst.

Dan maar ns op de desktop gechecked, zelfde resultaat. Dimension4 (het proggy dat al jarendag op mijn desktop de klok regelmatig synct) registreerde de laatste succesvolle sync op 21/7 rond 21u. Hij heeft wel een paar dagen niet aangestaan, maar toch... alle NTP servers hebben een timeout.

De enige time server die wel werkt, trouwens, is die van telenet zelf, ntp.telenet.be ; bij googlen naar telenet ntp servers kwam die naar boven, en wonder boven wonder geeft die geen timeout, als enige server in de rij.
Dit lijkt me meer dan een toeval te zijn. Zou telenet het NTP protocol ineens blokkeren? Zijn er nog telenet users die dit kunnen verifieren?

Ik gebruik verschillende NTP servers op verschillende devices (telefoon, camera's, enz...) en dat werkt gewoon.
Daarnet een aantal NTP servers getest met NTPQuery en alles oke.

Ik weet niet of het uitmaakt maar ik heb een business abonnement.

Wat ik net gemerkt hebt :manueel updaten van de windows klok
IPV4 & IPV6 time.windows.com (geen enkele werkt)

(getest met manueel IPV6 uit te vinken in netwerkkaart, dus een IP4 ip adres gebruikt,
indien je test met beiden actief gaat dit een timeout geven ...)

IPV4 die werken

time.nist.gov
time-nw.nist.gov
time-a.nist.gov
time-b.nist.gov


IPV6 geven allemaal timeout ...
dus sedert de overschakeling naar IPV6 is dit probleem ontstaan, eigelijk nooit op gelet

Ik heb hier de laatste maanden ook miserie mee (gehad) op een Telenet lijntje.

• Mijn Raspberry Pi heb ik intussen maar voorzien van een RTC.
• Siemens Gigaset basisstations bleken soms meer dan een maand geen time sync meer gehad te hebben. Niet zo'n probleem aangezien de klok redelijk stabiel is, maar toch: het zou moeten werken. Doch geen "merkbare last"...
• Op één NAS vind ik van half juni tot begin juli vier events terug waarbij de tijd tussen de 10 tot 80 minuten werd "gecorrigeerd" en enkele uren later opnieuw "gecorrigeerd" naar de andere kant. Hierbij dacht ik eerst aan iets heel anders: een mogelijke hack. Doch niets specifiek gevonden en gelet op de andere NTP issues ook niet verder meer gezocht (wél mijn "ogen opengehouden").
• Op PCs/tablets geen "merkbare last"...
• Ik heb (nog) geen continue logging ingesteld wat betreft de bereikbaarheid van externe NTP servers op dit TN lijntje. Doch handmatig via de command line heb ik wel gemerkt dat externe NTP servers soms niet bereikbaar zijn, minstens...

Op een BGC lijntje waar ik gebruik maak van dezelfde set externe NTP servers: geen enkel issue.
't Ja, de externe NTP servers zullen het probleem dan ook wel niet zijn zeker.

Even getest en inderdaad time.windows.com gaf een timeout... echter iets nadien werkte hij wel prima.

Heb trouwens ook IPv6 via HE tunnel actief... maar time.windows.com heeft geen IPv6 adres dus ik denk niet dat de oorzaak is.