CradlePoint and NTP

July 2, 2015 at 8:01 am Leave a comment

CradlePoint routers have one interesting habit that I’ve noticed.  If they can’t connect to the WAN, they won’t try to sync with the NTP server it is configured for.

On the surface, this seems smart.  Don’t bother trying to sync time unless you have a path to the Internet, right?

But what if you have a local time server?  In that light, this is a poor decision.

Perhaps a bit more complexity to their code would satisfy everyone.  If the NTP server that is configured is an IP address and it’s one that falls into RFC1918 (private IPs), then go ahead and try to sync as soon as you boot up.  If it’s a DNS name, or a public IP, then wait until you get a WAN connection.

Anyhow, I noticed this some time back, but didn’t think too much of it.  As it turns out, it can cause an issue in our particular use-case.

In my previous post, I outlined that we are using the API to perform speed tests at remote sites, using what I call an “LTE Survey Kit”, to gather data about all three of the major carriers at once at each remote location.  We noticed an anomaly in the speed test results.  Most of the time it works fine, but occasionally we get back a completed speed test with a speed of 0.00.  That’s right.  It told us that it FINISHED the test in the 60 seconds we provided, but the speed was calculated to be 0.00.

How can that be?  If it took the full 60 seconds to download 1 MB of data…  Well, let’s do some simple math:  1000 KB / 60 seconds = 16.67 KBps.

So, if it was as slow as possible, while still completing, I’d expect a result greater than 0.00.

A bit of testing today discovered that on the few occasions we see this anomalous result, the test started before an NTP sync was done, and finishing after it completed.  The speed was calculated as if it took from sometime during 1969 until present day 2015 to complete that speed test, hence the speed of 0.00 Kbps.

So, how to fix?  Well, we could simply remove the NTP server config so it doesn’t sync, but I thought perhaps adding a wait loop would be better.  So now, when this test runs, after the CBA850s come up on the individual carriers, I check to see if NTP is synced (another API call),  Once all the devices with active WAN links have synced with NTP, then we can start the test.  As a side benefit, this gives each of the devices a little more time on the carrier prior to kicking off a test.

Also, I found out today that if you query the API (/api/status/rf I believe) you get back an array of all the results of the SINR.  This is polled every 18 seconds by the CradlePoint and could be very useful in checking for stability.  Having the extra wait time for NTP sync means we can collect data a little longer.


Entry filed under: CradlePoint.

Can’t trust Cell coverage maps? Make your own! Making administrative web apps in PHP

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


July 2015
« Jun   Aug »

Most Recent Posts

%d bloggers like this: