Posted: Thu Mar 11, 2021 14:22 Post subject: NTP server connecting protocol and ports
Hi All,
This is my first post and it's a bit different type of query and I am trying to find some answers from the DDWRT developers/experts.
My TP Link router with stock TP Link's firmware fails to sync time with Internet NTP servers. It just returns Time Out for tens of NTP servers.
I understand that this is totally out of scope here on this forum.
But I am curious to understand when DD WRT firmware establishes Time Sync with NTP servers on various routers does it connect to SNTP 123 or UDP 123 or TCP 37 or UDP 37 or some other port/protocol.
Sadly TP Link support is not providing any info and it's unclear if my ISP blocks these ports or there's indeed issue with TP Link firmware.
My Linux PC on same ISP can sync time ntpdate -q <servername> command as well as another Dlink router with stock firmware but not TP Link router.
I am not expecting any help in troubleshooting as I am not using DD WRT but I am restricting the scope to understanding how DD WRT syncs time with NTP servers.
Thanks and I hope my query is on topic here.
Best regards.
NTP runs over udp port 123 by default... there are different versions of the protocol and if yours is too old it will give errors. I have no idea what your TP Link router is doing so I can not be of much help. The other thing is your hardware clock on that router may have failed or be so undisiciplined that the ntp algorithm rejects it and does not sync.
DD-WRT uses the standard UDP 123 to establish the connection.
the NTP server can have settings to reject for certain reasons, some will block/reject if you query too many times in a specific amount of time (ie they think it is a start of a ddos)
Thank you @Wildlion for this info.
Ok so it's UDP 123 and since my other Dlink router is able to sync, it means ISP is not blocking the port.
I also flashed my Dlink router with DDWRT and it was as well able to sync time correctly with default as well as time.nist.gov. So connection outbound to UDP 123 is fine.
That's the only clarity I needed.
So there must be something wrong with the TPLink router.
Hi,
additionally I have just one more query. When DD-WRT sends NTP client sync request to NTP server does it originate on Source port UDP 123 or a higher port like above 1000
i.e. is it Client UDP 123 to NTP Server UDP 123
or Client UDP (say) 1020 to NTP UDP 123
Thanks.
Thanks, that's a bit puzzling because my ISP blocks incoming 123 port udp, so how come DD-WRT on my dlink router is able to sync time with NTP servers.
I though it would have been a higher numbered port which generally is not blocked by ISP.
It probably is doing packet inspection and sees an outgoing request first from that port/protocol, then it records in the table an expected response and waits until it gets it.
Does it change the source port from 123 to something else?
If it expects a response back on 123 it will be blocked at ISP. Yet with DD-WRT, NTP Sync in router is working.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sun Sep 18, 2022 12:31 Post subject:
If you share your DD-WRT version and router brand name and version it would be better than making generic questions based on wild guesses and conjecture and thus we could perhaps see if any thing is not right in setup and give you specific help if needed. If in doubt read the top sections on https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=332703
I dont think there are any ISP blocks to standard NTP ports, it would make no sense for any ISP, as NTP is pretty much universal use case for all sorts of devices, as you noted yourself other devices work, so it is not blocked, this is a fact.
Also your NTP setup matters, we have no idea what you're inserting in there, also its best left blank as it uses built in servers which change based on your geo location.
@the-joker
Thanks for your post. The general info I was looking for was more or less received in the discussion. The original post is nearly 2 years old. I returned my TPLink router back to seller then and have changed my ISP twice since then.
This thread may simply be closed now as the original context no longer exists.