NTP is geblokkeerd door ofwel mijn routers ofwel mijn ISP

[Mastakilla]

Hallo,

Reeds meerdere maanden / jaren (weet het niet exact) werkt NTP niet meer op mijn computers. Eerst dacht ik dat het Windows was, omdat het enkel opviel op mijn vrouw haar laptop, die vrij snel vele minuten out-of-sync gaat. Maar nadat ik vele uren heb geprobeerd dit op te lossen (inclusief enkele uren met meerdere Microsoft helpdesk medewerkers), ontdekte ik dat eigenlijk al mijn computers dit probleem hebben. Mijn vrouw haar laptop is intussen ook geformatteerd en zelfs op een verse Windows 10 installatie (laatste versie), komt het voor. Op mijn eigen desktop ontdekte ik ook dat op mijn Virtual Machine, die via VPN op het internet gaat, het probleem niet voor komt.

Al dit wijst volgens mij dan ook op een probleem in mijn network of bij de ISP. Ik zou echter niet weten hoe ik dit moet troubleshooten, aangezien NTP gebruikt van UDP en je dus niet, zoals bij TCP, gewoon een telnet kan doen naar een bepaalde poort.

Mijn netwerk is als volgt:
Internet komt binnen in de garage via een telefoonkabel (VDSL2) naar een FRITZ!Box 7530.
Op de FRITZ!Box staat alles van WIFI uit en de enige netwerkkabel gaat naar mijn eerste Asus ZenWiFi AX (Mesh systeem).
Vandaar gaat er een "wired backhaul" naar mijn tweede Asus ZenWiFi AX in mijn bureau.
De tweede Asus ZenWiFi heeft enkele apparaten direct aangesloten, maar heeft ook een kabel naar een Cisco SG100D-08 V2. Dit is gewoon een domme 8 poorts gbit switch (valt volgens mij ook niets aan te configureren).

Mijn ISP is EDPnet (VDSL2 in België)

Heeft iemand een idee hoe ik dit verder kan troubleshooten? Kan ik bv op de FRITZ!Box iets uitvoeren waarmee ik kan testen of de FRITZ!Box wel NTP access heeft?
Ik heb trouwens ook al verschillende NTP servers geprobeerd, wat dus ook niet helpt...

[Glewellyn]

Heb je met bij voorbeeld WireShark al eens een capture gedaan van je netwerkverkeer en gefilterd op NTP?

[nescafe]

Je kunt op de FRITZ!Box een packet capture maken door naar http://fritz.box/html/capture.lua te gaan (of via de webinterface: Contents (linksonder), FRITZ!Box Support, Packet traces).

Maar waarschijnlijk kun je betere voortgang boeken door je Asus in Access Point mode (AiMesh Router in AP mode) te schakelen. Zie https://www.asus.com/support/FAQ/1044151/

Let op - bij het omzetten van router mode naar AP mode zullen clients een ander IP krijgen (rechtstreeks van de FRITZ!Box) - de verbinding valt dan tijdelijk uit op de betreffende apparaten, soms moet je dat even forceren door deze te herstarten of tijdelijk de netwerkkabel te unpluggen.

[Will_M]

Heb je op die AVM Fritzbox ook aangegeven staan dat 't ding als NTP server voor je eigen LAN mag werken?

Inloggen op de Fritz!

Thuisnetwerk -> Netwerk -> Netwerkinstellingen -> Tijdsychronisatie -> Vinkje bij 'De FRITZ!Box kan als tijdserver in het thuisnetwerk worden gebruikt.'

Tijdserver van de Fritzbox zelf instellen op 1.europe.pool.ntp.org ... Of 2 , 3 , 4 .....

[biomass]

nescafe schreef op donderdag 7 oktober 2021 @ 23:11:
Je kunt op de FRITZ!Box een packet capture maken door naar http://fritz.box/html/capture.lua te gaan (of via de webinterface: Contents (linksonder), FRITZ!Box Support, Packet traces).

Bedankt voor het noemen van deze functie, ik had deze ook al een keertje gebruikt maar wist niet meer hoe. De 'FRITZ!Box Support' staat linksonder de Contents pagina (het oog neigt eerst naar al die functies die onder Fritz!Box Content genoemd staan).

[Ben(V)]

Als je twee routers gebruikt (double NAT) dan moet je zorgen dat UDP port 123 op de fritzbox geforward wordt naar die Asus router.

Of beter.
Gebruik de Asus router als NTP server voor je Lan devices en gebruik de Fritzbox als NTP server voor de ASUS en stel een NTP server op het internet in als NTP server voor de Fritzbox.

[Mastakilla]

Bedankt voor de antwoorden!

[ Voor 157% gewijzigd door Mastakilla op 12-10-2021 14:31 ]

[Mastakilla]

Ik heb mijn antwoorden in mijn laatste reply hieronder proberen te bundelen

[ Voor 129% gewijzigd door Mastakilla op 12-10-2021 14:31 ]

[Mr Magic]

Je kunt het ook testen vanaf een Windows Admin command prompt:

code:

w32tm /stripchart /computer:0.nl.pool.ntp.org /dataonly /samples:5

Je zou dan iets moeten zien als:

code:

Tracking 0.nl.pool.ntp.org [162.159.200.1:123].
Collecting 5 samples.
The current time is 08/10/2021 11:51:48.
11:51:48, -00.6908464s
11:51:50, -00.6906810s
11:51:52, -00.6907713s
11:51:54, -00.6904804s
11:51:56, -00.6908736s

[DukeBox]

Ben(V) schreef op vrijdag 8 oktober 2021 @ 09:03:
Als je twee routers gebruikt (double NAT) dan moet je zorgen dat UDP port 123 op de fritzbox geforward wordt naar die Asus router.

Hoe dat zo ? NTP (UDP) request kan vanaf iedere willekeurige poort boven de 1023 geïnitieerd worden en komt daar ook op terug.

[Ben(V)]

https://support.ntp.org/bin/view/Support/TroubleshootingNTP

ntpd requires full bidirectional access to the privileged UDP port 123.

Een en ander is afhankelijk hoe je de boel configureert, maar als hij die Asus router als NTP server geconfigureerd heeft dan is het verstandig om in die Asus in te stellen dat hij zijn tijd weer van die Friztbox haalt en die op zijn beurt weer van een publieke ntp server.

[ewoutw]

Ben(V) schreef op vrijdag 8 oktober 2021 @ 09:03:
Als je twee routers gebruikt (double NAT) dan moet je zorgen dat UDP port 123 op de fritzbox geforward wordt naar die Asus router.
...

ik heb NTP vaak genoeg met dubbelnat gebruikt, nog nooit een forward voor ingesteld,
UDP kan gewoon gerouteerd en genat worden. Dubbel NAT maakt eigenlijk nooit uit (Al heeft het ook zeker nadelen).

[ Voor 14% gewijzigd door ewoutw op 08-10-2021 13:52 ]

[Raven]

Ben(V) schreef op vrijdag 8 oktober 2021 @ 13:11:
https://support.ntp.org/bin/view/Support/TroubleshootingNTP

[...]


Een en ander is afhankelijk hoe je de boel configureert, maar als hij die Asus router als NTP server geconfigureerd heeft dan is het verstandig om in die Asus in te stellen dat hij zijn tijd weer van die Friztbox haalt en die op zijn beurt weer van een publieke ntp server.

"ntpd requires full bidirectional access to the privileged UDP port 123."

Dat is niet helemaal waar, ben ik ook al eens ingestonken. Als het gaat om verkeer tussen twee NTP servers (bijv. pool.ntp.org en je router), dan inderdaad udp poort 123 in beide richtingen toestaan.

In het geval van client->server verkeer, moet de combinatie clientbronpoort udp >1023 en bestemmingspoort 123 toegestaan worden.

Op mijn router-pc leverde dat de volgende regels op:

code:

add rule ip filter input udp sport { 123 , 1024-65535 } udp dport 123 counter accept
add rule ip filter output udp sport 123 udp dport { 123 , 1024-65535 } counter accept

[ Voor 13% gewijzigd door Raven op 08-10-2021 15:00 ]

[Mastakilla]

Mr Magic schreef op vrijdag 8 oktober 2021 @ 11:54:
Je kunt het ook testen vanaf een Windows Admin command prompt:

code:

w32tm /stripchart /computer:0.nl.pool.ntp.org /dataonly /samples:5

Je zou dan iets moeten zien als:

code:

Tracking 0.nl.pool.ntp.org [162.159.200.1:123].
Collecting 5 samples.
The current time is 08/10/2021 11:51:48.
11:51:48, -00.6908464s
11:51:50, -00.6906810s
11:51:52, -00.6907713s
11:51:54, -00.6904804s
11:51:56, -00.6908736s

Command line lijkt te werken, maar dezelfde NTP server in the Windows configuratie werkt niet blijkbaar...

[Mastakilla]

Ben(V) schreef op vrijdag 8 oktober 2021 @ 09:03:
Als je twee routers gebruikt (double NAT) dan moet je zorgen dat UDP port 123 op de fritzbox geforward wordt naar die Asus router.

Heb ik geprobeerd en hielp jammer genoeg niet...

[ Voor 115% gewijzigd door Mastakilla op 12-10-2021 15:03 ]

[Mastakilla]

Will_M schreef op donderdag 7 oktober 2021 @ 23:13:
Heb je op die AVM Fritzbox ook aangegeven staan dat 't ding als NTP server voor je eigen LAN mag werken?

Inloggen op de Fritz!

Thuisnetwerk -> Netwerk -> Netwerkinstellingen -> Tijdsychronisatie -> Vinkje bij 'De FRITZ!Box kan als tijdserver in het thuisnetwerk worden gebruikt.'

Tijdserver van de Fritzbox zelf instellen op 1.europe.pool.ntp.org ... Of 2 , 3 , 4 .....

Ben(V) schreef op vrijdag 8 oktober 2021 @ 09:03:
Of beter.
Gebruik de Asus router als NTP server voor je Lan devices en gebruik de Fritzbox als NTP server voor de ASUS en stel een NTP server op het internet in als NTP server voor de Fritzbox.

Ben(V) schreef op vrijdag 8 oktober 2021 @ 13:11:
https://support.ntp.org/bin/view/Support/TroubleshootingNTP

[...]


Een en ander is afhankelijk hoe je de boel configureert, maar als hij die Asus router als NTP server geconfigureerd heeft dan is het verstandig om in die Asus in te stellen dat hij zijn tijd weer van die Friztbox haalt en die op zijn beurt weer van een publieke ntp server.

Windows using my Asus ZenWiFi AX as NTP server:


My Asus ZenWiFi AX using my FRITZ!Box as NTP server


My FRITZ!Box using a public internet NTP server

werkt maw jammer genoeg niet

[ Voor 13% gewijzigd door Mastakilla op 12-10-2021 14:35 ]

[Mastakilla]

Glewellyn schreef op donderdag 7 oktober 2021 @ 23:01:
Heb je met bij voorbeeld WireShark al eens een capture gedaan van je netwerkverkeer en gefilterd op NTP?

[Mastakilla]

nescafe schreef op donderdag 7 oktober 2021 @ 23:11:
Je kunt op de FRITZ!Box een packet capture maken door naar http://fritz.box/html/capture.lua te gaan (of via de webinterface: Contents (linksonder), FRITZ!Box Support, Packet traces).

Bedankt!
Ik heb de pagina gevonden, maar hoe kan ik dan een packet capture maken specifiek voor NTP?

nescafe schreef op donderdag 7 oktober 2021 @ 23:11:
Maar waarschijnlijk kun je betere voortgang boeken door je Asus in Access Point mode (AiMesh Router in AP mode) te schakelen. Zie https://www.asus.com/support/FAQ/1044151/

Let op - bij het omzetten van router mode naar AP mode zullen clients een ander IP krijgen (rechtstreeks van de FRITZ!Box) - de verbinding valt dan tijdelijk uit op de betreffende apparaten, soms moet je dat even forceren door deze te herstarten of tijdelijk de netwerkkabel te unpluggen.

Momenteel staat mijn router op "Wireless router mode / AiMesh Router mode (Default)". Als ik het goed begrijp, maak ik, door de Asus in AP mode te zetten, van de Asus een soort van slave van de FRITZ!Box, waarbij de FRITZ!Box alles regelt van DHCP, port forwarding naar de clients, etc. En dan heb ik maar 1 lokaal subnet ipv 2, zoals ik nu heb met dubbel NAT...

Misschien dat dit het idd wel wat eenvoudiger maakt, maar ik vraag me wel af of me dit ook niet gaat beperken, aangezien de FRITZ!Box eigenlijk het minderwaardige netwerkdevice is dat ik enkel en alleen behoudt omdat mijn provider me hiertoe verplicht...

Kan iemand me een volledige lijst geven van welke services allemaal worden "uitgezet" / "overgedragen worden aan de FRITZ!Box" door de Asus in AP mode te zetten? Dan kan ik een goede inschatting maken van wat ik hierdoor "misloop"...

Ik denk dan bv aan:

• DHCP
• Port forwarding
• NTP (optioneel)
• ...?

Hoe zit het bv met QoS? Dat is bv veel uitgebreider op mijn Asus dan op mijn FRITZ!Box...

[ Voor 94% gewijzigd door Mastakilla op 12-10-2021 15:07 ]

[DukeBox]

Ben(V) schreef op vrijdag 8 oktober 2021 @ 13:11:
https://support.ntp.org/bin/view/Support/TroubleshootingNTP

Dat is voor 2-way synchronization voor o.a. tussen stratum 1 servers. Niet voor client synchronisatie.

[Mastakilla]

Zou deze setting misschien een oplossing kunnen zijn om wel maar 1 lokaal netwerk te hebben met mijn Asus als "master"? Of kan de FRITZ!Box, als ik hem zo instel, niet meer functioneren als router met het internet?

[Will_M]

Mastakilla schreef op donderdag 14 oktober 2021 @ 00:10:
[Afbeelding]
Zou deze setting misschien een oplossing kunnen zijn om wel maar 1 lokaal netwerk te hebben met mijn Asus als "master"? Of kan de FRITZ!Box, als ik hem zo instel, niet meer functioneren als router met het internet?

Daarmee schakel je inderdaad de routering naar/van het internet uit op je Fritzbox!

[Mastakilla]

Will_M schreef op donderdag 14 oktober 2021 @ 00:16:
[...]


Daarmee schakel je inderdaad de routering naar/van het internet uit op je Fritzbox!

Ok bedankt! Dan is dat dus geen oplossing voor mijn probleem.

Dan hoop ik dat iemand nog kan antwoorden op mijn vragen die ik in de reply daarvoor heb gesteld...

[nescafe]

Mastakilla schreef op dinsdag 12 oktober 2021 @ 14:33:
[...]
Ik heb de pagina gevonden, maar hoe kan ik dan een packet capture maken specifiek voor NTP?

Dat is niet mogelijk, je zult dus de capture moeten starten, ntp resync forceren en capture stoppen. Vervolgens kun je in Wiresharp het verkeer analyseren en de juiste filters toepassen.

[FreakNL]

Mastakilla schreef op dinsdag 12 oktober 2021 @ 14:18:
[...]

[Afbeelding]
Command line lijkt te werken, maar dezelfde NTP server in the Windows configuratie werkt niet blijkbaar...

Als je in dat windows vensterje nu gewoon een IP adres gebruikt?

194.109.6.2

Krijg je dan nog steeds een foutmelding?

[fastedje]

Nectar kan helaas niet controleren of je een UDP verbinding kan openen. Je zou wel met wireshark of tcpdump kunnen kijken of je een ICMP close terug krijgt: https://en.wikipedia.org/...l#Destination_unreachable

[m2011]

Mastakilla schreef op donderdag 7 oktober 2021 @ 22:59:
Hallo,

Reeds meerdere maanden / jaren (weet het niet exact) werkt NTP niet meer op mijn computers.

Als je niet meer weet welke maand of jaar het is, dan heb je jezelf echt te afhankelijk gemaakt van NTP

[nihilissimis]

Mastakilla schreef op dinsdag 12 oktober 2021 @ 14:18:
[...]

[Afbeelding]
Command line lijkt te werken, maar dezelfde NTP server in the Windows configuratie werkt niet blijkbaar...

Als t vanaf de command-line werkt, kan je ervan uitgaan dat t op protocol niveau werkt en zou ik het probleem eerder bij Windows zoeken dan in het netwerk.

[Verwijderd]

Pak een raspberry pi met een gps chip en maak je eigen NTP server

[Brahiewahiewa]

Mastakilla schreef op dinsdag 12 oktober 2021 @ 14:18:
[...]

[Afbeelding]
Command line lijkt te werken, maar dezelfde NTP server in the Windows configuratie werkt niet blijkbaar...

Dit betekent dus dat er geen blokkade is op ISP-niveau. Of op router niveau, for that matter.

Kijk voor de lol eens in Event Viewer | Application and Services Logs | Microsoft | Windows | Time Service
Staan daar misschien Errors of Warnings die iets verduidelijken?

[Mastakilla]

Nogmaals: het probleem is niet op windows niveau. Ik heb het op meerdere desktops en laptops, zelfs na een verse installatie van de laatste windows 10. Dit terwijl dat een VM die via de VPN gaat, het probleem niet heeft...

[ Voor 6% gewijzigd door Mastakilla op 14-10-2021 15:55 ]

[Brahiewahiewa]

Mastakilla schreef op donderdag 14 oktober 2021 @ 12:44:
Nogmaals: het probleem is niet op windows niveau. Ik heb het op meerdere desktops en laptops, zelfs na een verse installatie van de laatste windows 10. Ook een VM die via de VPN gaat, heeft het probleem niet...

Dus je gaat gewoon niet in Event Viewer kijken? Succes dan...

[Mastakilla]

Brahiewahiewa schreef op donderdag 14 oktober 2021 @ 12:52:
[...]

Dus je gaat gewoon niet in Event Viewer kijken? Succes dan...

Geen errors of warnings, enkel information
Als ik manuele sync doe, verschijnt volgend information event (een aantal keer - met verschillende TimeCreated / tickercount):

code:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Time-Service" Guid="{06edcfeb-0fd0-4e53-acca-a6f8bbf81bcb}" /> 
  <EventID>266</EventID> 
  <Version>0</Version> 
  <Level>4</Level> 
  <Task>0</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x4000000000000000</Keywords> 
  <TimeCreated SystemTime="2021-10-14T12:13:51.5673459Z" /> 
  <EventRecordID>3210</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="12724" ThreadID="7252" /> 
  <Channel>Microsoft-Windows-Time-Service/Operational</Channel> 
  <Computer>HTPC</Computer> 
  <Security UserID="S-1-5-19" /> 
  </System>
- <EventData Name="TMP_OPS_TIME_RESYNC_EVENT">
  <Data Name="ReasonCode">0</Data> 
  <Data Name="TickCount">124362203</Data> 
  </EventData>
  </Event>

[ Voor 8% gewijzigd door Mastakilla op 14-10-2021 14:32 ]

[Mastakilla]

FreakNL schreef op donderdag 14 oktober 2021 @ 04:39:
[...]


Als je in dat windows vensterje nu gewoon een IP adres gebruikt?

194.109.6.2

Krijg je dan nog steeds een foutmelding?

[ Voor 17% gewijzigd door Mastakilla op 14-10-2021 14:26 ]

[Drardollan]

Ik heb eenzelfde probleem gehad in een zakelijke omgeving. Daar zat een HPE switch tussen met daarin de "auto DOS" protectie aan (zie voor meer uitleg: https://louwrentius.com/h...ing-network-problems.html).

Ik zou om te beginnen eens kijken wat er gebeurd als je een andere internetverbinding gebruikt. Even hotspotje met je telefoon bijvoorbeeld. Als het probleem dan niet optreedt dan ligt het zeker in je infrastructuur. Als het probleem dan wel optreedt dan moet je het binnen Windows zoeken. Je geeft aan dat het op diverse machines zo is, maar is er buiten de infrastructuur nog een andere gemeenschappelijke deler? Bijvoorbeeld antivirus software?

[SmokingSig]

Mastakilla schreef op dinsdag 12 oktober 2021 @ 14:29:
[...]

[Afbeelding]

En waar is je terug kerende trafiek ?

[Mastakilla]

Intro

Hallo allemaal. Excuses voor het late antwoord. Door het gebrek aan vooruitgang, was ik het even beu om hier mee bezig te zijn. Ook keek ik op tegen de meest veelbelovende tip, om mijn double-NAT netwerk om te bouwen tot een bridged netwerk. Dit weekend heb ik me er echter over gezet en ben ik er weer in gevlogen.

Eerst en vooral nog even de laatste replies opvolgen

Drardollan schreef op donderdag 14 oktober 2021 @ 16:15:
Ik heb eenzelfde probleem gehad in een zakelijke omgeving. Daar zat een HPE switch tussen met daarin de "auto DOS" protectie aan (zie voor meer uitleg: https://louwrentius.com/h...ing-network-problems.html).

Ik zou om te beginnen eens kijken wat er gebeurd als je een andere internetverbinding gebruikt. Even hotspotje met je telefoon bijvoorbeeld. Als het probleem dan niet optreedt dan ligt het zeker in je infrastructuur. Als het probleem dan wel optreedt dan moet je het binnen Windows zoeken. Je geeft aan dat het op diverse machines zo is, maar is er buiten de infrastructuur nog een andere gemeenschappelijke deler? Bijvoorbeeld antivirus software?

Goeie tip, bedankt!


Zoals je kan zien werkt met een wifi-via-gsm verbinding NTP zonder problemen.
En met de ethernet-via-router verbinding werkt NTP niet.

Tussen deze 2 screenshots is buiten het type verbinding niets verandert... Ik hoop dat dit nu duidelijk maakt dat het probleem niets te maken heeft met Windows-config, een software firewall of een AV. En dat het enkel te maken kan hebben met de netwerk infrastructuur (mijn netwerk devices of de ISP).

SmokingSig schreef op donderdag 14 oktober 2021 @ 16:20:
En waar is je terug kerende trafiek ?

Die is er dus duidelijk niet eh

Double-NAT -> Bridged

Verder heb ik dus ook eindelijk werk gemaakt om mijn double-NAT netwerk om te bouwen naar een bridged netwerk. Ik heb er voor gekozen om mijn FRITZ!Box in bridge mode te zetten en mijn Asus ZenWiFi de PPPoE verbinding te laten maken.
Hiervoor heb ik de instructies van mijn provider gevolgt:
https://www.edpnet.be/nl/...e-modus-configureren.html

Dit is volgens mijn goed gelukt, wat door het onderstaande screenshot bewezen wordt

Maar zelfs nu werkt NTP nog steeds niet... Zowel niet "direct" als "via-de-router".

En nu?

Ik zit dus nog steeds vast maw... Tips zijn welkom

Als ik me niet vergis, heb ik door de FRITZ!Box te bridgen uitgesloten dat het iets met de FRITZ!Box config te maken heeft en kan het enkel maar met de Asus ZenWiFi of mijn provider te maken hebben? Kan iemand dit bevestigen (of ontkennen) aub? Dat zou de scope toch al een beetje beperken...

[ Voor 3% gewijzigd door Mastakilla op 06-12-2021 11:08 ]

[Wylana]

Mag ik vragen waarom je niet het algemene adres gebruikt pool.ntp.org? Die resolved dan automatisch naar je dichtstbijzijnde NTP server.

Verder staat in je laatste screenshot alleen maar vermeld dat dat je Azus Zen ook naar het 0.be.pool.ntp.org verwijst. Verder zie ik nergens dat deze is ingesteld als NTP server! Dus waar staat precies vermeld dat 192.168.0.1 als NTP is ingesteld? Je probeert nu naar mijn mening te verbinden met een NTP server die er niet is....dus klopt de melding.

[Mastakilla]

Wylana schreef op maandag 6 december 2021 @ 11:13:
Mag ik vragen waarom je niet het algemene adres gebruikt pool.ntp.org? Die resolved dan automatisch naar je dichtstbijzijnde NTP server.

Verder staat in je laatste screenshot alleen maar vermeld dat dat je Azus Zen ook naar het 0.be.pool.ntp.org verwijst. Verder zie ik nergens dat deze is ingesteld als NTP server! Dus waar staat precies vermeld dat 192.168.0.1 als NTP is ingesteld? Je probeert nu naar mijn mening te verbinden met een NTP server die er niet is....dus klopt de melding.

Ik heb al met oneindig veel verschillende NTP servers proberen te verbinden en ze werken allemaal niet. Via de gsm-hotspot werkt 0.be.pool.ntp.org, dus waarom zou dit een "minderwaardige" NTP server zijn?

Maar voor de duidelijkheid:


Dat de Asus geen duidelijke instelling heeft om als NTP server te functioneren is inderdaad correct. Die is er, voor zover ik weet, niet... Mij is het ook niet helemaal duidelijk of hij dit wel kan / doet of niet.
Daarom heb ik ook zowel "direct", als via de ZenWiFi geprobeert en screenshots van gepost. En beide werken niet...

[ Voor 8% gewijzigd door Mastakilla op 06-12-2021 11:40 ]

[Wylana]

Mastakilla schreef op maandag 6 december 2021 @ 11:30:
[...]

Ik heb al met oneindig veel verschillende NTP servers proberen te verbinden en ze werken allemaal niet. Via de gsm-hotspot werkt 0.be.pool.ntp.org, dus waarom zou dit een "minderwaardige" NTP server zijn?

Maar voor de duidelijkheid:
[Afbeelding]

Dat de Asus geen duidelijke instelling heeft om als NTP server te functioneren is inderdaad correct. Die is er, voor zover ik weet, niet... Mij is het ook niet helemaal duidelijk of hij dit wel kan of niet.
Daarom heb ik ook zowel "direct", als via de ZenWiFi geprobeert en screenshots van gepost. En beide werken niet...

Ik heb je hele verhaal nog eens gelezen en las dat je eerst je Fritzbox als NTP server had ingesteld. Echter staat die nu in Bridge mode en dus is ie geen NTP server meer. Dus je hebt alleen nog de mogelijkheid om te verbinden met een externe NTP server.

Probeer eens voor de gein het adres pool.ntp.org te gebruiken ipv een specifiek adres. Dit adres is een namelijk een algemeen adres dat automatisch de juiste NTP server voor je zoekt en daarmee antwoord.

Verder denk ik dat het mogelijk in je Asus Zen zit. Gezien het feit dat je via je 4G hotspot wel kan verbinden, moet het wel in je eigen netwerk zitten. Ik zou daar eens kijken naar firewall instellingen o.i.d.

Misschien eventueel het adres whitelisten?
https://www.asus.com/support/FAQ/1013636/

[Mastakilla]

Wylana schreef op maandag 6 december 2021 @ 11:42:
[...]
Probeer eens voor de gein het adres pool.ntp.org te gebruiken ipv een specifiek adres. Dit adres is een namelijk een algemeen adres dat automatisch de juiste NTP server voor je zoekt en daarmee antwoord.

Wylana schreef op maandag 6 december 2021 @ 11:42:
Verder denk ik dat het mogelijk in je Asus Zen zit. Gezien het feit dat je via je 4G hotspot wel kan verbinden, moet het wel in je eigen netwerk zitten. Ik zou daar eens kijken naar firewall instellingen o.i.d.

Misschien eventueel het adres whitelisten?
https://www.asus.com/support/FAQ/1013636/

Dit is een test met de firewall tijdelijk uit


Dit zijn mijn huidige FW settings (is volgens mij gewoon de default)





En tenslotte mijn poging tot whitelisting

[Wylana]

Probeer eens ipv met Powershell de sync in te stellen.

Kijken of dat wel werkt.

Open Windows Powershell (of Command Prompt) als Adminstrator.
Voer daarna het volgende commando uit

Net Stop W32Time
W32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org"
W32tm /config /reliable:yes
Net Start W32Time
W32tm /config /update
W32tm /resync

pause

Check of de sync gelukt is.

[Mastakilla]

Wylana schreef op maandag 6 december 2021 @ 12:32:
Probeer eens ipv met Powershell de sync in te stellen.

Kijken of dat wel werkt.

Open Windows Powershell (of Command Prompt) als Adminstrator.
Voer daarna het volgende commando uit

Net Stop W32Time
W32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org"
W32tm /config /reliable:yes
Net Start W32Time
W32tm /config /update
W32tm /resync

pause

Check of de sync gelukt is.

[Ben(V)]

Check eens of je soms een group policy heb die de boel tegenhoud.
zie:
https://techgenix.com/windows-time-sync-issues/

Het kan geen firewall settin zijn wat dit werkte volgens jouw wel:
w32tm /stripchart /computer:0.nl.pool.ntp.org /dataonly /samples:5

[ Voor 100% gewijzigd door Ben(V) op 06-12-2021 13:55 ]

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 13:50:
De conclusie is dus dat ergens een firewall of group policy de ntp request tegenhoud.

Group policy en software firewall kan volgens mij niet, want dan zou het via een gsm hotspot ook niet werken...

En de firewall op mijn Asus ZenWiFi is het volgens mij ook niet, want zelfs als ik die uitzet, dan nog werkt het niet...

Dan schiet enkel nog maar de ISP over... Wel straf dat ik als enige dit zou merken...

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 13:50:
Check eens of je soms een group policy heb die de boel tegenhoud.
zie:
https://techgenix.com/windows-time-sync-issues/

Het kan geen firewall settin zijn wat dit werkte volgens jouw wel:
w32tm /stripchart /computer:0.nl.pool.ntp.org /dataonly /samples:5

Group policy kan het volgens mij niet zijn, want dan zou het via een gsm hotspot ook niet werken... Of vergis ik me?

[Ben(V)]

Nee ISP noch firewall kan het zijn want je test naar de timeserver werkte gewoon.

w32tm /stripchart /computer:0.nl.pool.ntp.org /dataonly /samples:5

[ Voor 114% gewijzigd door Ben(V) op 06-12-2021 14:15 ]

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 13:56:
Nee ISP noch firewall kan het zijn want je test naar de timeserver werkte gewoon.

[...]

Bedoel je de test met PowerShell?
"The computer did not resync because no time data was available."
Lijkt me toch eerder niet te werken...?

[Ben(V)]

Dat geeft aan dat het wel werkt anders had je die server niet kunnen registreren maar dat het ophalen van de time data failed.

Maar handmatig in de poweshell werkte het wel met:

w32tm /stripchart /computer:pool.ntp.org /dataonly /samples:5

[ Voor 35% gewijzigd door Ben(V) op 06-12-2021 14:04 ]

[Wylana]

En check ff de Group Policies.

https://appuals.com/how-t...vailable-error-on-windows

En dan vanaf het stuk FOR LOCAL COMPUTER.

Kijk eens of die ook op DISABLED (UITGESCHAKELD) staat. Zo ja, aanpassen naar Niet Geconfigureerd.

[Mastakilla]

Zoals je kan zien, zijn er geen group policies configured. Ook is dit een gewoon thuis netwerk, dus zonder domain controllers ofzo

[Wylana]

Ok, dan hebben we die ook als oorzaak gefilterd.

Zou je eens in Powershell (als Administrator) de volgende commando's willen uitvoeren.

w32tm /query /source
w32tm /query /configuration

Ben benieuwd wat daar de uitkomst dan van is.

[Mastakilla]

Wylana schreef op maandag 6 december 2021 @ 14:12:
Ok, dan hebben we die ook als oorzaak gefilterd.

Zou je eens in Powershell (als Administrator) de volgende commando's willen uitvoeren.

w32tm /query /source
w32tm /query /configuration

Ben benieuwd wat daar de uitkomst dan van is.

code:

PS C:\WINDOWS\system32> W32tm /query /source
Local CMOS Clock
PS C:\WINDOWS\system32> W32tm /query /configuration
[Configuration]

EventLogFlags: 2 (Local)
AnnounceFlags: 5 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 10 (Local)
MaxPollInterval: 15 (Local)
MaxNegPhaseCorrection: 54000 (Local)
MaxPosPhaseCorrection: 54000 (Local)
MaxAllowedPhaseOffset: 1 (Local)

FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 360000 (Local)


[TimeProviders]

NtpClient (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Local)
ResolvePeerBackoffMaxTimes: 7 (Local)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 1 (Local)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 32768 (Local)
Type: NTP (Local)
NtpServer: pool.ntp.org (Local)

NtpServer (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)

[consolefreak]

Heb je 'AiProtection' aan staan op je huidige Asus router? Probeer eens uit te zetten en dan nog eens te proberen? Misschien zijn er nog meer 'slimmigheden' in je router die iets kunnen veroorzaken.

[Ben(V)]

Windows gebruikt dus alleen de cmos time.

En geef nog een deze commando:

w32tm /stripchart /computer:nl.pool.ntp.org /dataonly /samples:2
w32tm /stripchart /computer:time.windows.com /dataonly /samples:2

[Mastakilla]

consolefreak schreef op maandag 6 december 2021 @ 14:17:
Heb je 'AiProtection' aan staan op je huidige Asus router? Probeer eens uit te zetten en dan nog eens te proberen? Misschien zijn er nog meer 'slimmigheden' in je router die iets kunnen veroorzaken.

Dat had ik inderdaad nog niet geprobeerd! En die stond inderdaad aan... Onderstaand screenshot is met zowel AiProtection als de Asus Firewall uit...

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 14:23:
Windows gebruikt dus alleen de cmos time.

En geef nog een deze commando:

[...]

code:

PS C:\WINDOWS\system32> w32tm /stripchart /computer:nl.pool.ntp.org /dataonly /samples:2
Tracking nl.pool.ntp.org [87.233.197.123:123].
Collecting 2 samples.
The current time is 06/12/2021 14:27:57.
14:27:57, +00.1134902s
14:27:59, +00.1134718s
PS C:\WINDOWS\system32> w32tm /stripchart /computer:time.windows.com /dataonly /samples:2
Tracking time.windows.com [40.119.148.38:123].
Collecting 2 samples.
The current time is 06/12/2021 14:28:04.
14:28:04, +00.1068643s
14:28:06, +00.1108913s

[Ben(V)]

Hij kan dus prima de beide timeservers bereiken, dus het probleem zit in Windows,

Ik zou eens een unregister van de timeservers doen, misschien is daar iets corrupt geraakt.
dus zo:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync /rediscover
w32tm /query /status

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 14:30:
Hij kan dus prima de beide timeservers bereiken, dus het probleem zit in Windows,

Ik zou eens een unregister van de timeservers doen, misschien is daar iets corrupt geraakt.
dus zo:

[...]

Ik begrijp nog steeds niet hoe dit aan Windows zou kunnen liggen hoor... Ik heb het hier namelijk op meerdere computers, waarvan 1tje het zelfs onmiddellijk heeft na een verse Windows installatie (gewoon van een MSDN ISO)...
Ook werkt het wel als ik de gsm hotspot gebruik...

Maar soit, hier het resultaat:

code:

PS C:\WINDOWS\system32> net stop w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.

PS C:\WINDOWS\system32> w32tm /unregister
W32Time successfully unregistered.
PS C:\WINDOWS\system32> w32tm /register
W32Time successfully registered.
PS C:\WINDOWS\system32> net start w32time
The Windows Time service is starting.
The Windows Time service was started successfully.

PS C:\WINDOWS\system32> w32tm /resync /rediscover
Sending resync command to local computer
The computer did not resync because no time data was available.
PS C:\WINDOWS\system32> w32tm /query /status
Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0000000s
Root Dispersion: 0.0000000s
ReferenceId: 0x00000000 (unspecified)
Last Successful Sync Time: unspecified
Source: Local CMOS Clock
Poll Interval: 10 (1024s)

[Ben(V)]

Mijn kennis is uitgeput.

Het moet aan Windows liggen want als je in de powershell de timeservers benadert krijg je van twee verschillende timeservers gewoon netjes de time data terug dus noch je netwerk, noch je router noch je ISP blokkeert die NTP requests.
Alleen als Windows het zelf probeert mislukt het.

Misschien heb je hier nog wat aan:
https://www.meinbergglobal.com/english/info/ntp-w32time.htm

[ Voor 13% gewijzigd door Ben(V) op 06-12-2021 14:42 ]

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 14:40:
Mijn kennis is uitgeput.

Het moet aan Windows liggen want als je in de powershell de timeservers benadert krijg je van twee verschillende timeservers gewoon netjes de time data terug dus noch je netwerk, noch je router noch je ISP blokkeert die NTP requests.
Alleen als Windows het zelf probeert mislukt het.

Enorm bedankt om mee erover na te denken! Ik hoop dat iemand anders misschien nog een idee heeft?

Kan je me trouwens misschien verklaren hoe het kan dat het aan Windows zou liggen, maar toch:
1) Het wel werkt via een gsm hotspot?
2) Hetzelfde probleem zich voordoet op al mijn computers. Dit is dus inclusief een vers geinstalleerde Windows op mijn vrouw haar laptop. Ook de Windows die hiervoor op mijn vrouw haar laptop stond (welke HP zelf heeft geinstalleerd) had exact hetzeflde probleem. Enkel een VM die via een VPN het internet bereikt, heeft het probleem niet...

[ Voor 11% gewijzigd door Mastakilla op 06-12-2021 14:46 ]

[Ben(V)]

Geen idee.
Maar als je NTP data van een NTP server op het internet kunt ophalen vanaf de powershell en een w32tm commando en Windows (die ook w32tm gebruikt) kan dat niet dan kun je daar volgens mij maar een conclusie aan verbinden.

[Mastakilla]

Aangezien iedereen hier maar blijft vermoeden dat het Windows ligt, heb ik het eens over een andere boeg gegooid...

Ik heb nl ook een TrueNAS server. Dit is gebaseerd op FreeBSD en heeft dus niets met Windows te maken. Ook deze server heeft geen werkende NTP...

code:

data# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp.cybertu.be  .INIT.          16 u    - 1024    0    0.000   +0.000   0.000
 ntp2.unix-solut .INIT.          16 u    - 1024    0    0.000   +0.000   0.000
 dns-rec-2-brudi .INIT.          16 u    - 1024    0    0.000   +0.000   0.000
data# ping ntp.pool.org
PING ntp.pool.org (64.99.80.121): 56 data bytes
64 bytes from 64.99.80.121: icmp_seq=0 ttl=242 time=113.178 ms
64 bytes from 64.99.80.121: icmp_seq=1 ttl=242 time=113.392 ms
^C
--- ntp.pool.org ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 112.750/113.034/113.392/0.230 ms
data# ping ntp.cybertu.be
PING ntp.cybertu.be (51.255.138.215): 56 data bytes
64 bytes from 51.255.138.215: icmp_seq=0 ttl=53 time=14.439 ms
64 bytes from 51.255.138.215: icmp_seq=1 ttl=53 time=13.602 ms
^C
--- ntp.cybertu.be ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.602/14.020/14.439/0.418 ms
data# ntpdate pool.ntp.org
 6 Dec 14:53:34 ntpdate[59056]: the NTP socket is in use, exiting
data# service ntpd stop
Stopping ntpd.
Waiting for PIDS: 1320.
data# ntpdate pool.ntp.org
 6 Dec 14:54:29 ntpdate[59076]: no server suitable for synchronization found

[ Voor 16% gewijzigd door Mastakilla op 06-12-2021 15:02 ]

[Brahiewahiewa]

Mastakilla schreef op maandag 6 december 2021 @ 14:57:
...

code:

...
 6 Dec 14:53:34 ntpdate[59056]: the NTP socket is in use, exiting
...

Zegt genoeg, lijkt me

[borft]

Hmm, vaag probleem. Kan je de ntpdate eens met -v runnen? klaagt ie omdat ie geen verbinding kan maken? of lukt dns niet? zou het een ipv4/ipv6 probleem kunnen zijn (-6) probeer anders ook es met -u en/of -q, o, en natuurlijk -d

dus
ntpdate -q -u -v -d -4 pool.ntp.org

Brahiewahiewa schreef op maandag 6 december 2021 @ 15:01:
[...]

Zegt genoeg, lijkt me

lijkt me niet, want de regel eronder wordt ntpd gestopt.....

[ Voor 50% gewijzigd door borft op 06-12-2021 15:07 ]

[Mastakilla]

Brahiewahiewa schreef op maandag 6 december 2021 @ 15:01:
[...]

Zegt genoeg, lijkt me

Je moet eerst de ntpd service stoppen vooraleer je het ntpdate commando kan lopen... Zie:
https://www.truenas.com/c...ds/ntp-not-syncing.62428/
Na die service te stoppen is de foutmelding:
"no server suitable for synchronization found"

[ Voor 13% gewijzigd door Mastakilla op 06-12-2021 15:03 ]

[Mastakilla]

borft schreef op maandag 6 december 2021 @ 15:02:
Hmm, vaag probleem. Kan je de ntpdate eens met -v runnen? klaagt ie omdat ie geen verbinding kan maken? of lukt dns niet? zou het een ipv4/ipv6 probleem kunnen zijn (-6) probeer anders ook es met -u en/of -q, o, en natuurlijk -d

dus
ntpdate -q -u -v -d -4 pool.ntp.org


[...]


lijkt me niet, want de regel eronder wordt ntpd gestopt.....

Hier de verbose / debug output (die ook automatisch -u / unprivileged port doet)

code:

data# ntpdate -vd pool.ntp.org
 6 Dec 15:06:47 ntpdate[59304]: ntpdate 4.2.8p15-a (1)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)

server 51.155.16.62, port 123
stratum 1, precision -25, leap 00, trust 000
refid [GPS], root delay 0.000000, root dispersion 0.000000
reference time:      e55897a3.00000000  Mon, Dec  6 2021 15:07:31.000
originate timestamp: e55897a3.04539ec5  Mon, Dec  6 2021 15:07:31.016
transmit timestamp:  e558977e.196d99d9  Mon, Dec  6 2021 15:06:54.099
filter delay:  0.06796    0.06776    0.06735    0.06735
               ----       ----       ----       ----
filter offset: +36.896518 +36.896559 +36.896753 +36.896698
               ----       ----       ----       ----
delay 0.06735, dispersion 0.00008, offset +36.896753

server 107.194.210.155, port 123
stratum 2, precision -21, leap 00, trust 000
refid [17.253.6.253], root delay 0.010803, root dispersion 0.024506
reference time:      e558968b.b57acb79  Mon, Dec  6 2021 15:02:51.708
originate timestamp: e55897a3.4231401f  Mon, Dec  6 2021 15:07:31.258
transmit timestamp:  e558977e.4c17628c  Mon, Dec  6 2021 15:06:54.297
filter delay:  0.15025    0.14992    0.15007    0.15004
               ----       ----       ----       ----
filter offset: +36.898865 +36.898937 +36.899043 +36.899103
               ----       ----       ----       ----
delay 0.14992, dispersion 0.00009, offset +36.898937

server 204.2.134.163, port 123
stratum 3, precision -23, leap 00, trust 000
refid [193.187.181.6], root delay 0.009949, root dispersion 0.051071
reference time:      e55897a1.214b9970  Mon, Dec  6 2021 15:07:29.130
originate timestamp: e55897a3.7af7f0ca  Mon, Dec  6 2021 15:07:31.480
transmit timestamp:  e558977e.80a42cf9  Mon, Dec  6 2021 15:06:54.502
filter delay:  0.18819    0.18791    0.18765    0.18738
               ----       ----       ----       ----
filter offset: +36.896968 +36.896667 +36.897090 +36.896918
               ----       ----       ----       ----
delay 0.18738, dispersion 0.00014, offset +36.896918

server 193.150.22.36, port 123
stratum 2, precision -20, leap 00, trust 000
refid [194.58.204.20], root delay 0.017136, root dispersion 0.046280
reference time:      e5588fb5.84a5a560  Mon, Dec  6 2021 14:33:41.518
originate timestamp: e55897a3.9e90a930  Mon, Dec  6 2021 15:07:31.619
transmit timestamp:  e558977e.b3d77518  Mon, Dec  6 2021 15:06:54.702
filter delay:  0.06425    0.06299    0.06335    0.06258
               ----       ----       ----       ----
filter offset: +36.898012 +36.898228 +36.898345 +36.898376
               ----       ----       ----       ----
delay 0.06258, dispersion 0.00009, offset +36.898376

 6 Dec 15:06:54 ntpdate[59304]: step time server 51.155.16.62 offset +36.896753 sec

Ik weet echter niet goed hoe ik deze output moet interpreteren...

Enkel verbose is zo trouwens:

code:

data# ntpdate -v pool.ntp.org
 6 Dec 15:05:09 ntpdate[59268]: ntpdate 4.2.8p15-a (1)
 6 Dec 15:05:18 ntpdate[59268]: no server suitable for synchronization found

En jou specifieke commando:

code:

data# ntpdate -q -u -v -d -4 pool.ntp.org
 6 Dec 15:12:09 ntpdate[59400]: ntpdate 4.2.8p15-a (1)
transmit(162.159.200.1)
receive(162.159.200.1)
transmit(91.121.216.238)
receive(91.121.216.238)
transmit(78.129.36.63)
receive(78.129.36.63)
transmit(45.87.78.35)
receive(45.87.78.35)

server 162.159.200.1, port 123
stratum 3, precision -25, leap 00, trust 000
refid [10.78.8.138], root delay 0.006165, root dispersion 0.000351
reference time:      e5589866.53f772b0  Mon, Dec  6 2021 15:10:46.327
originate timestamp: e55898de.6ffa5451  Mon, Dec  6 2021 15:12:46.437
transmit timestamp:  e55898b9.8695b0ac  Mon, Dec  6 2021 15:12:09.525
delay 0.03613, dispersion 0.00000, offset +36.906350

server 91.121.216.238, port 123
stratum 2, precision -24, leap 00, trust 000
refid [193.190.230.37], root delay 0.004517, root dispersion 0.029449
reference time:      e55895b2.cdcb4ea7  Mon, Dec  6 2021 14:59:14.803
originate timestamp: e55898de.a50468dd  Mon, Dec  6 2021 15:12:46.644
transmit timestamp:  e55898b9.bb619eb0  Mon, Dec  6 2021 15:12:09.731
delay 0.03914, dispersion 0.00000, offset +36.905817

server 78.129.36.63, port 123
stratum 3, precision -22, leap 00, trust 000
refid [193.190.198.14], root delay 0.011200, root dispersion 0.115738
reference time:      e558981c.af5df9ab  Mon, Dec  6 2021 15:09:32.685
originate timestamp: e55898de.d90df016  Mon, Dec  6 2021 15:12:46.847
transmit timestamp:  e55898b9.ee94a91e  Mon, Dec  6 2021 15:12:09.931
delay 0.04633, dispersion 0.00000, offset +36.905506

server 45.87.78.35, port 123
stratum 2, precision -25, leap 00, trust 000
refid [109.68.160.223], root delay 0.000610, root dispersion 0.001068
reference time:      e55895ca.650e9eba  Mon, Dec  6 2021 14:59:38.394
originate timestamp: e55898df.08fd426e  Mon, Dec  6 2021 15:12:47.035
transmit timestamp:  e55898ba.1fa77a5c  Mon, Dec  6 2021 15:12:10.123
delay 0.03653, dispersion 0.00000, offset +36.905996

 6 Dec 15:12:10 ntpdate[59400]: step time server 45.87.78.35 offset +36.905996 sec

[ Voor 21% gewijzigd door Mastakilla op 06-12-2021 15:13 ]

[borft]

Mastakilla schreef op maandag 6 december 2021 @ 15:08:
[...]

Hier de verbose / debug output (die ook automatisch -u / unprivileged port doet)

code:

data# ntpdate -vd pool.ntp.org
 6 Dec 15:06:47 ntpdate[59304]: ntpdate 4.2.8p15-a (1)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)
transmit(51.155.16.62)
receive(51.155.16.62)
transmit(107.194.210.155)
receive(107.194.210.155)
transmit(204.2.134.163)
receive(204.2.134.163)
transmit(193.150.22.36)
receive(193.150.22.36)

server 51.155.16.62, port 123
stratum 1, precision -25, leap 00, trust 000
refid [GPS], root delay 0.000000, root dispersion 0.000000
reference time:      e55897a3.00000000  Mon, Dec  6 2021 15:07:31.000
originate timestamp: e55897a3.04539ec5  Mon, Dec  6 2021 15:07:31.016
transmit timestamp:  e558977e.196d99d9  Mon, Dec  6 2021 15:06:54.099
filter delay:  0.06796    0.06776    0.06735    0.06735
               ----       ----       ----       ----
filter offset: +36.896518 +36.896559 +36.896753 +36.896698
               ----       ----       ----       ----
delay 0.06735, dispersion 0.00008, offset +36.896753

server 107.194.210.155, port 123
stratum 2, precision -21, leap 00, trust 000
refid [17.253.6.253], root delay 0.010803, root dispersion 0.024506
reference time:      e558968b.b57acb79  Mon, Dec  6 2021 15:02:51.708
originate timestamp: e55897a3.4231401f  Mon, Dec  6 2021 15:07:31.258
transmit timestamp:  e558977e.4c17628c  Mon, Dec  6 2021 15:06:54.297
filter delay:  0.15025    0.14992    0.15007    0.15004
               ----       ----       ----       ----
filter offset: +36.898865 +36.898937 +36.899043 +36.899103
               ----       ----       ----       ----
delay 0.14992, dispersion 0.00009, offset +36.898937

server 204.2.134.163, port 123
stratum 3, precision -23, leap 00, trust 000
refid [193.187.181.6], root delay 0.009949, root dispersion 0.051071
reference time:      e55897a1.214b9970  Mon, Dec  6 2021 15:07:29.130
originate timestamp: e55897a3.7af7f0ca  Mon, Dec  6 2021 15:07:31.480
transmit timestamp:  e558977e.80a42cf9  Mon, Dec  6 2021 15:06:54.502
filter delay:  0.18819    0.18791    0.18765    0.18738
               ----       ----       ----       ----
filter offset: +36.896968 +36.896667 +36.897090 +36.896918
               ----       ----       ----       ----
delay 0.18738, dispersion 0.00014, offset +36.896918

server 193.150.22.36, port 123
stratum 2, precision -20, leap 00, trust 000
refid [194.58.204.20], root delay 0.017136, root dispersion 0.046280
reference time:      e5588fb5.84a5a560  Mon, Dec  6 2021 14:33:41.518
originate timestamp: e55897a3.9e90a930  Mon, Dec  6 2021 15:07:31.619
transmit timestamp:  e558977e.b3d77518  Mon, Dec  6 2021 15:06:54.702
filter delay:  0.06425    0.06299    0.06335    0.06258
               ----       ----       ----       ----
filter offset: +36.898012 +36.898228 +36.898345 +36.898376
               ----       ----       ----       ----
delay 0.06258, dispersion 0.00009, offset +36.898376

 6 Dec 15:06:54 ntpdate[59304]: step time server 51.155.16.62 offset +36.896753 sec

Ik weet echter niet goed hoe ik deze output moet interpreteren...

Enkel verbose is zo trouwens:

code:

data# ntpdate -v pool.ntp.org
 6 Dec 15:05:09 ntpdate[59268]: ntpdate 4.2.8p15-a (1)
 6 Dec 15:05:18 ntpdate[59268]: no server suitable for synchronization found

hmm, lijkt erop dat het, met een unprivileged port, dus wel werkt? dus als je met alleen -u draait? misschien dat je isp geen uitgaande UDP verbindingen op een port < 1024 toestaat?

[Ben(V)]

Hoe trek je die conclusie, ik zie toch duidelijk dat hij poort 123 gebruikt en van al de servers gewoon ntp data terug krijgt?
leap 00 betekent dat hij gewoon synchroniseert.

Je kunt het ook verifieren met dit commando:

ntpq -pn

[ Voor 11% gewijzigd door Ben(V) op 06-12-2021 15:21 ]

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 15:18:
Hoe trek je die conclusie, ik zie toch duidelijk dat hij poort 123 gebruikt en van al de servers gewoon ntp data terug krijgt?
Je kunt het ook verifieren met dit commando:

[...]

code:

data# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 45.87.77.15     .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 45.87.76.3      .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 94.224.67.24    .INIT.          16 u    -   64    0    0.000   +0.000   0.000

Ik denk dat dit de output is als het niet werkt?

[Mastakilla]

borft schreef op maandag 6 december 2021 @ 15:13:
[...]


hmm, lijkt erop dat het, met een unprivileged port, dus wel werkt? dus als je met alleen -u draait? misschien dat je isp geen uitgaande UDP verbindingen op een port < 1024 toestaat?

Dus de output met "-u" (of "-d") had wel een succes volle sync gedaan?

[Ben(V)]

Je hebt hier duidelijk andere ntp servers hier dan die van ntp.pool.org

[M2M]

*knip*. Dit advies voegt niet zoveel toe.

[ Voor 89% gewijzigd door rens-br op 06-12-2021 15:33 ]

[borft]

Ben(V) schreef op maandag 6 december 2021 @ 15:18:
Hoe trek je die conclusie, ik zie toch duidelijk dat hij poort 123 gebruikt en van al de servers gewoon ntp data terug krijgt?
leap 00 betekent dat hij gewoon synchroniseert.

Je kunt het ook verifieren met dit commando:

[...]

-u betekent dat ie een unprivileged port gebruikt voor de uitgaande verbinding. De connectie gaat natuurlijk wel naar port 123, want dat is waar de ntpd op luistert op de servers.

Mastakilla schreef op maandag 6 december 2021 @ 15:26:
[...]

Dus de output met "-u" (of "-d") had wel een succes volle sync gedaan?

Nee, maar dat komt door de -q (van query). Maar het feit dat ie data terug krijgt, betekent dat ie het wel zou doen. Dus, wat gebeurt er als je gewoon ntpdate -u pool.ntp.org doet?

[ Voor 26% gewijzigd door borft op 06-12-2021 15:31 ]

[M2M]

M2M schreef op maandag 6 december 2021 @ 15:27:
[mbr]*knip*. Dit advies voegt niet zoveel toe.[/]

Thanks, mijn post had een mooi opstapje kunnen zijn om gewoon zelf een timeserver te maken. Kosten zijn kleiner dan 50 euro als je er een raspberry pi voor pakt.

[Mastakilla]

Ok, goed nieuws... Ik denk dat ik de oplossing gevonden heb!

Het zat niet in Windows Maar wel bij mijn ISP (EDPnet) die blijkbaar poort 123 blokkeert.

Blokkeren jullie NTP (Network Time Protocol)? Op al mijn computers werkt dit namelijk niet. Dit zijn zowel Windows als FreeBSD computers. Als ik de hotspot van mijn GSM gebruik (Proximus), dan werkt het wel gewoon.
Ik heb ook al oneindig veel instellingen in de router geprobeerd, inclusief alles van Firewall enzo uitzetten.
Sofia heeft zich bij de chat gevoegd.
Sofia: Hallo Mastakilla, dat klopt, poort 123 is geblokkeerd maar kan op aanvraag worden opengezet.
Sofia: Dit beschouw ik dus als een aanvraag
Sofia: Ik zal eventjes de verbinding controleren, moment.
Mastakilla: ps: ik bedoel trouwens dat NTP niet werkt als client eh
Sofia: Werd zojuist opengezet.
Mastakilla: ik wil GEEN NTP server ofzo lopen
Mastakilla: als je die port 123 hebt opengezet zodat ik een ntp server kan draaien, dan heeft dat weinig zin vrees ik, dan mag je die ook terug toe draaien
Sofia: Wat is dan de bedoeling?
Mastakilla: de bedoeling is dat mijn tijd met het internet kan synchroniseren
Sofia: Daarvoor moet de 123 poort open staan, die is by deafult door ons geblokkeerd.
Heb die om 15:27 opengezet.
Mastakilla: sorry, maar begrijp ik het nu goed dat jullie blokkeren dat computers hun tijd kunnen synchroniseren met het internet?
Sofia: Klopt.
Om ervoor te zorgen dat we beschermd zijn tegen DDoS-aanvallen, is poort 123 standaard geblokkeerd voor klanten met dynamische IP-adressen.
Mastakilla: Is dit ergens gedocumenteerd?
Mastakilla: Ik ben namelijk al maanden aan het zoeken naar een oplossing en kon me bijna niet voorstellen dat jullie zo'n feature zouden blokkeren? Hier moeten dan toch veel klanten over klagen? Je wilt niet weten hoeveel uren ik al aan dit probleem verloren ben...
Mastakilla: Dit is nl een standaard feature van ieder OS van zelfs voor ik was geboren tot nu. Ieder OS maakt hier gebruik van...
Sofia: Nee, dat is niet vermeld op onze support pagina.
Mastakilla: Zou u dan aub er voor kunnen zorgen dat dit erop komt te staan, zodat anderen hun kostbare tijd hier niet aan verkwisten?
Mastakilla: Trouwens: ik weet dat een NTP server lopen risico geeft op mee helpen aan DDoS aanvallen. Maar hiervoor moet je toch ook niet het NTP client verkeer blokkeren?
Sofia: Het is daar niet vermeld omdat er voor gekozen werd om dit niet algemeen bekend te maken, maar ik vraag zeker na of er plannen zijn om de support pagina met deze informatie bij te vullen.
Mastakilla: Volgens mij blokkeren jullie dit niet op de correcte manier. Volgens mij kan je dit ook blokkeren op een manier zodat enkel NTP servers blocked worden en niet het client verkeer...
Mastakilla: Soit, laat de poort voor mij voorlopig dan maar open aub. Ik ben toch niet van plan een NTP server te lopen, dus loop ik (denk ik) niet het risico om mee te helpen aan DDoS aanvallen...
Sofia: Het blijft open.
Mastakilla: ok bedankt, maar vraag aan de technisch dienst aub ook om hun blokkade te herbekijken. Het lijkt me niet nodig / correct om ook NTP client verkeer te blokkeren...

Nadat ze de poort voor mij openzetten, werkt het plots allemaal weer wel...

Vergis ik me trouwens wanneer ik aan Sofia (EDPnet) zeg dat je poort 123 kan blokkeren op een manier zodat enkel NTP servers verhinderd worden en niet NTP clients?

[ Voor 3% gewijzigd door Mastakilla op 06-12-2021 15:56 ]

[Ben(V)]

Volkomen belachelijk om NTP requests verkeer dat naar buiten gaat te blokkeren.
Alle normale clients gebruiken NTP om hun tijd te synchronizer met het internet, dus alle klanten van deze ISP lopen op cmos tijd met alle gevolgen van dien.

En een NTP DDOS aanval misbruikt een bug in de NTP servers en niet NTP clients en die bug is volgens mij al jaren geleden gefixed (2014 dacht ik )

Weet niet of je vast zit aan deze ISP maar dat zou voor mij reden zijn om een andere te nemen.

[borft]

Mastakilla schreef op maandag 6 december 2021 @ 15:53:
Ok, goed nieuws... Ik denk dat ik de oplossing gevonden heb!

Het zat niet in Windows Maar wel bij mijn ISP (EDPnet) die blijkbaar poort 123 blokkeert.


[...]


Nadat ze de poort voor mij openzetten, werkt het plots allemaal weer wel...

Vergis ik me trouwens wanneer ik aan Sofia (EDPnet) zeg dat je poort 123 kan blokkeren op een manier zodat enkel NTP servers verhinderd worden en niet NTP clients?

Ik denk het niet. Ze zouden inkomend verkeer (voor klanten) op udp op porten < 1024 kunnen blokkeren, dan hebben clients er geen last meer van.

Mooi dat het opgelost is.

[Mastakilla]

Ben(V) schreef op maandag 6 december 2021 @ 16:03:
Volkomen belachelijk om NTP verkeer dat naar buiten gaat te blokkeren.
Alle normale clients gebruiken NTP om hun tijd te synchronizer met het internet, dus alle klanten van deze ISP lopen op cmos tijd met alle gevolgen van dien.

En een NTP DDOS aanval misbruikt een bug in de NTP servers en niet NTP clients en die bug is volgens mij al jaren geleden gefixed (2014 dacht ik )

Weet niet of je vast zit aan deze ISP maar dat zou voor mij reden zijn om een andere te nemen.

Hier zijn ze inderdaad goed de mist in gegaan. Maar als je het Belgische ISP landschap wat kent, weet je dat er eigenlijk geen goed alternatief is voor EDPnet als je geen limieten wilt. En buiten deze fout, ben ik er eigenlijk enorm tevreden van...

[Wylana]

Goed te horen dat je de oorzaak gevonden hebt.

Maar wat een gedoe zeg en heel merkwaardig dat je ISP dit blokkeert.

Eindelijk kan je verder met je NTP inrichting nu!

[Ben(V)]

Even terzijde.
Door dit issue ben ik even aan het googlen geslagen en vond een veel betere (en snellere) timeserver te weten ntp.time.nl.

Hun website vind je hier.
https://www.sidnlabs.nl/n...-ntp-dienst-van-sidn-labs

Wilde ik hier toch even delen.

[Mastakilla]

Trouwens bedankt allemaal om mee te zoeken!