Community news, upcoming events and general discussions
Threads: 32 Posts: 82
Get technical support from the community
Threads: 1182 Posts: 6596
Threads: 16 Posts: 58
Tell us how to make XDK better!
Threads: 35 Posts: 117
Share and discuss community member projects
Threads: 53 Posts: 256
In file SDK/xdk110/Common/source/Utility/SNTP.c there is a bug in function SNTP_Enable(void). When you initialise a UDP socket instead of providing source port on which you whish to receive response from NTP server, you use destination port (123) of the NTP server. Since port 123 is from reserved range (0-1023) the function SntpTimeCallback is never called (no reply from server). This caused the whole SNTP.c implementation to be useles, because it could not update time via NTP.
I have changed the function implementation from
Ip_Port_T destPort = (Ip_Port_T) (SNTPSetup.ServerPort);
if (RC_OK != Sntp_start(Ip_convertIntToPort(destPort), SntpTimeCallback))
Ip_Port_T rcvPort = (Ip_Port_T) (SNTPSetup.ServerPort + 1023);
if (RC_OK != Sntp_start(Ip_convertIntToPort(rcvPort), SntpTimeCallback))
and now it works.
Thank you for your answer, but I must disagree - this is a bug, as the code without my change is not working (I cannot synchronise with any well known NTP server in the Internet). NTP port is indeed 123, but this is receive port number, no the port on which XDK opens socket for the reply. What I proposed in my fix is to change the outgoing port of XDK. Please refer to this poor draft of the situation:
XDK ----- (NTP request) --------> NTP server (listens port 123)
(rcv port) <---- (NTP reply)-------------
Here the (rcv port) cannot be 123. Thus I have added 1023 to it to get sth from range > 1023. And yes, this is called "registered ports" by IANA, but the port range can be used without any super privilages.
> Could you please get more into detail on why you don't want to use the standart port 123?
No, it's not about "I don't want", it's about I cannot use port 123 because it is simply not working. Please run any sample application from XDK like BoschXDKCloudConnectivity - it does not work (at least for me). Function SNTP_GetTimeFromServer cannot sync time with NTP server because of this bug. This is because in SNTP_Enable the sourcePort on which NTP reply should be received is confused with the destination port (which is 123).
Maybe I will put it this way: I do use port 123, but as a destination port. I.e. I have SNTP setup as this:
static SNTP_Setup_T SNTPSetupInfo =
.ServerUrl = "0.pool.ntp.org",
.ServerPort = UINT16_C(123),
But since SNTP_Enable takes SNTPSetupInfo.ServerPort as both destination port (which is OK) and listen port (which is not OK) the whole SNTP feature does not work. Especially SntpTimeCallback is never called.
Yes, I do know how UDP works. And yes, I do setup WLAN module and ServalPal before trying to update time with SNTP. For example my code on XDK can communicate with MQTT server I run on my laptop via WiFi, so the WiFi works OK.
I just thought maybe my WiFi router is somehow blocking UDP packets going back from the NTP server to the SDK? Your idea with packet sniffer is very good, I will check what packets are actually going in/out with Wireshark/tcpdump.
And yes, I do use do...while loop. The case is that when I use port 123 I do not get response even after 100 tries (30s timeout between tries) and when I use port 123+1023 as described in my original post I get the reply just after first request. So maybe indeed the router is a blocker here. But then how other devices in my WiFi synchronise time?
What information do you need about my application? I just connect to wifi and establish MQTT connection and send sensor data. All works (wifi connection, mqtt, sending data and receiving them on my laptop), but when I wanted to append current timestamp to the data I cannot do this since the timestamp cannot be synced.
sudo tcpdump -i "interface" udp -A -s 0 port 123