CS410 System clock not keeping time sync

[Isaac Schneider]

Hello,

 

I was troubleshooting a system flag issue and found that the clock is different. The system is set for EST but is 30minutes behind. When going in via ssh, running the date command I show "UTC 2008" at the end of the string. Anyone seen this before?

 

Thanks,

Isaac.

[Isaac Schneider]

Good News!

 

I seem to have a a bit of insight as to why the box is not syncing ntp properly. The CS410 running pbxnsip v3.3.1.3177 looks like it is using ntpclient http://doolittle.icarus.com/ntpclient/ for a lightweight ntp client. Unlike newer clients who use TCP as well as UDP, ntpclient only works using UDP for queries. Also the source port of 123 can cause issues for return packets. Some ISPs for network and or client protection filter the "server" ports (the first 1024 ports). This can cause the client to fail on routers that do not have an alg with dynamic source ports for NTP.

 

Also due to a bug between windows 2003 server NTP server (w32time) and ntpclient (and others) there is a miscommunication. This has been possibly addressed in a previous hotfix for Server 2003 http://support.microsoft.com/?kbid=830092 . The envirnment I am running in has a 2003 R2 server and contains a newer w32time.dll (version 5.2.3790.3959) than the hotfix. It still has compatability problems with the ntpclient but nothing else on the network.

 

The startup flow goes as follows... The system runs the DHCP client if configured to do so. PBXnSIP box does not receive an NTP server option in a DHCP response, it does not update the system variable. The startup script then defaults the NTPServer variable to use pool.ntp.org The systems startup script /etc/rc5.d/S20pbxnsip contains a rule to set the date to Jan 1st 2008 and then run ntpclient using the NTPServer variable to update the clock. This can work but can cause some problems when NTP is not functioning. You would notice problems registering with sip trunks and external UAs.

 

To get arround the rest of the issues listed above I did the following.

 

Configure a new server pool:

I chose to use a more optimized pool - us.pool.ntp.org . This keeps the traffic arround the continental us. to change the pool edit /etc/rc5.d/S20pbxnsip got to line 14 or line as listed below..

 

if [ -z "$NTPSERVER" ]; then NTPSERVER=

pool.ntp.org

; fi

change to ..

if [ -z "$NTPSERVER" ]; then NTPSERVER=

us.pool.ntp.org

; fi

 

For a full list of optimized pools please visit the following...

http://support.ntp.org/bin/view/Servers/NTPPoolServers

 

Change client UDP ports and Poke a hole in firewalll:

1. Add a rule to forward a UDP port from the external wan interface and have the same UDP port for the internal destination. When adding the rule select a port above 1024 and below 65536

2. In the PBXnSIP webgui go to the Admin> Settings> Ports

3. Locate the field named NTP port, enter the port number you selected for your port forwarding rule on step 1.

4. Click on the Save Button

5. Reboot unit (in ssh: sync;sync;sync , reboot) (webgui goto Admin>System>PSTN-Gateway, click reboot)

 

This all seems to have fixed my specific environment and hopefully yours too!. I believe by using another ntp client this problem can be eliminated.

 

Ps. A nice side story, When ntp clients go wrong - http://www.cs.wisc.edu/~plonka/netgear-sntp/

 

Thanks,

Isaac.

[Vodia PBX]

Whow. Interesting findings!

 

Additionally, it seems there was a mess up between IPv4 and IPv6 in the DNS resolution of the NTP (seems to be limited to the CS410 PBX). The next build will also fix that.

[pbx support]

Whow. Interesting findings!

 

Additionally, it seems there was a mess up between IPv4 and IPv6 in the DNS resolution of the NTP (seems to be limited to the CS410 PBX). The next build will also fix that.

 

We have a version that has IPv4 and IPv6 related fix. You can download it from http://pbxnsip.com/cs410/update-3.4.0.3194.tgz

[andrewgroup]

We were debating to not give the root access to avoid issues like these. What you don't know shouldn't hurt you.

 

And Root access was debated. - Good Call on granting it.