Home/Support/Support Forum/Problems with tcp_time.c sample
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Problems with tcp_time.c sample

0 votes
Has anyone tried the sample to read an Internet time server. I want to synchronise my web application and so tried the sample.

I started by modifying the server list to 2 servers local to me

ntp1.npl.co.uk 139.143.5.57
ntp2.npl.co.uk 139.143.5.58

When I run the sample all seems to work ok (single step debugging), until waiting for the UDP packet reply for the NTP server. It never arrives. I known the NTP servers is there because my XP laptop is set to be synchronised by the same server.

I'm going to investigate the problem in more detail and have a look to see if the rabbit 3720 is sending the UDP packet request.

But if anyone else has had any experiance with NTP servers any help you can give would be good.

Cheers

Jonpd
asked Feb 22, 2007 in Rabbit by jonpd New to the Community (3 points)

Please log in or register to answer this question.

4 Answers

0 votes
Jon,

There are a couple of possible reasons your sample time program is not working:

(1) the rabbit end is buggy, and never sending the request; unlikley, presuming the DHCP query get's a proper reply with sensible network config values; I've had my rabbit send and receive UDP requests, though all over a local lan

(2) the sample program uses a "fake" ntp; it's actually using timep, on socket 37, which is an old 1-second resolution unix time protocol and a 32 bit counter; real NTP uses socket 123 and 64 bit magic numbers; it's possible the targets you note are not responding to socket 37, whereas they would respond on socket 123

(3) the greater LAN/WAN routers, NAT, firewalls and/or transport system (between the rabbit and the time sources you are using) drop the request somewhere; UDP is "unreliable", and on busy networks, the routers just simply drop the packets; that's why NFS pre-tcp version4 had to have it's own internal error recovery algorithims, for example

(4) if you have a local linux system on the LAN where your rabbit is, try the sample program again, using the linux server as the time source, and that will ensure (2) and (3) are removed as possible points as to why it's not working [BTW: I've turned the sample into a library routine, and it's working just fine, though using a local linux server as a time reference]

Rgds, David Booth
answered Mar 9, 2007 by User1054 New to the Community (7 points)
0 votes
Hi David,

Thanks for the reply. I've spent more time on the problem and using another of the sample apps I got access to a time server. The sample used a TCP client to connect to the time server using a DAYTIME port.

I think I was going wrong with the port number that I was using. I'll go back and try the UDP program using the correct port number (123)

Cheers,


Jonpd
answered Mar 9, 2007 by jonpd New to the Community (3 points)
0 votes
Hi Jon,

Hope I'm not teaching you what you already know:
Beware there is a fundamental difference between probing port 37 (timep) and port 123 (ntp).

On port 37, all you need to is send it something, anything and (security issues aside), the daemon (usually inetd on a u**x server) will ignore what it's been sent, and then will return a 32-bit unsigned integer; the integer being the number of seconds that have elapsed since the beginning of the unix-universe, being 1st Jan 1970 UTC. (the "epoch").

On port 123, you need to send it a semi-intelligent formatted number, and you will get back an internally formatted number, including the current time, plus some other stuff. Have a look at www.ntp.org for more details than you probably want to know.

The sample rabbit prog does not contain any smarts on how to build a "probe" NTP packet, then rip apart the NTP reply, let alone what to do with it past that. Troll the web for sample "sntp" implimentations to get an idea of what's involved. (The client only side of NTP).

I submit, it's also dubious value, in as much as the RTC & SECTIMER in the rabbit has a 1 second resolution, so there is little value in quizzing a clock that can be accurate to within nano-seconds.
answered Mar 11, 2007 by User1054 New to the Community (7 points)
0 votes
Hi Jon,
try SNTP.LIB written by Hans Van Ingelgom (was posted on Zworld's old BB), it's a simple an robust library that can be used to synchronize the on-board RTC. See the description below to decide whether this library is suitable for your application.

Description:
/* SNTP.LIB V0.8
*
* This library provides a very very simple SNTP (Simple Network
* Time Protocol, RFC1769) interface.
*
* sntp_gettime() returns the time, measured in seconds since
* Jan 01, 1980, 00:00 GMT. To do so, it sends an empty NTP request
* to the server and retreives the time from the reply. THIS MEANS
* THERE IS NO ROUDTRIP DELAY CALCULATION! (read the RFC if you wish
* to implement this feature).
*
* This software is freeware. You can use it in your own programs,
* as long as this copyright notice is not changed. No warranties
* implied. If you make changes to the code, please send them to
* hvingel@vub.ac.be along with a short description of your changes.
*
*/

Cheers,
Martin
answered Mar 11, 2007 by mfuhrer New to the Community (4 points)
...