Posts filed under ‘CradlePoint’

CradlePoint and NTP

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.

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

Can’t trust Cell coverage maps? Make your own!

At my day job, I’m responsible for the network connectivity for hundreds of remote locations.  We use 3G today as a backup to our T1 circuits.  One thing most IT people who have tried to put in a cellular network can probably attest to:  Vendor provided cellular coverage maps absolutely suck.  Even if you give the vendors a list of your addresses, you’ll get a far rosier picture of the coverage they can provide than exists in this reality.

So, what do you do when the vendor provided data isn’t any good?  

You make your own!


We’ve taken a small plastic tub, a consumer grade 5 port Ethernet switch, three CradlePoint CBA850’s, and a Quirky power strip to handle the huge power bricks the CBA850s need.  We’ve mounted the power strip to the bottom of the tub,  the switch to the side of the tub on one end, and the three CBA850s to the sides, so that their antennas fold down just below the top.  The CBA850s are pre-wired to the Ethernet switch, along with an extra CAT5 cable about 10 feet long.  The CBAs and the switch are plugged into the power strip.  The CBA850s are configured for AT&T, Sprint, and Verizon, so we can get a good picture of the coverage of all three carriers.  They are configured with static IPs not used elsewhere in our locations.  When our technician arrives at a location, he removes the top of the case, folds up the antennas, finds a power outlet and a free Ethernet port and plugs in.  A quick call to our NOC to let them know which location he’s at and which port to turn up is all that’s left for the tech to do.  At that point, our NOC staff can kick off a script which updates the router config for that location to NAT the CBA850s to addresses specific to that store, allowing them to be reached from headquarters.

Then, using the API magic I mentioned in my last post, the script validates that all three CBA850s are reachable, then it checks in with them to see if the WAN is connected, waiting around 5 minutes for any stragglers.  Once they are all up, or the expiration time has passed, it kicks off a series of speed tests, both upload and download, gathering the results of the tests along with other diagnostic info (SINR, signal strength, etc).  Drop that data into a database table, and there’s our “map”.

That’s no MAP!  That’s just a bunch of numbers!

No, our “map” won’t look like a map, but it will have data telling us which of the three main cellular providers is the best at every one of our locations that we’ve tested.  From the perspective of our management, that’s really all that matters.

July 1, 2015 at 8:39 am Leave a comment

CradlePoint API info

Every CradlePoint router (with at least a reasonably recent firmware) includes a very nice API.

However, if you search looking for documentation on their website about it, you’ll only find information on the API for ECM, their central management service.

Here are a few very useful URLs that you can call with the Restful client of your choice:

Figure out what model of CradlePoint you’ve reached, and/or the serial number:
https://  [CradlePoint IP]/api/status/product_info/

“data”: {
“company_name”: “Cradlepoint, Inc.”,
“copyright”: “Cradlepoint, Inc. 2015”,
“mac0”: “REDACTED“,
“company_url”: “”,
“manufacturing”: {
“board_ID”: “050000”,
“mftr_date”: “20150401”,
“serial_num”: “REDACTED
“product_name”: “CBA850”
“success”: true

Get your firmware version (major.minor.patch):
https:// [CradlePoint IP]/api/status/fw_info
“data”: {
“build_date”: “Thu Feb 19 12: 00: 07 MST 2015”,
“manufacturing_upgrade”: false,
“major_version”: 5,
“custom_defaults”: false,
“minor_version”: 3,
“fw_update_available”: false,
“patch_version”: 4,
“upgrade_minor_version”: 0,
“build_version”: 13953,
“upgrade_major_version”: 0,
“upgrade_patch_version”: 0,
“build_type”: “RELEASE”
“success”: true

Find out if you’re connected:

https:// [CradlePoint IP]/api/status/wan/connection_state

“data”: “connected”,
“success”: true

Get your WAN interface IP:
https:// [CradlePoint IP]/api/status/wan/ipinfo
“data”: {
“netmask”: “”,
“dns”: [
“ip_address”: “”,
“primary”: “lte-REDACTED“,
“gateway”: “”
“success”: true

Too much good diag stuff to mention: 

Please note, I REDACTED most of the unique identifying info, but these fields are all available on your gear.  To get the portion of the URL that’s redacted, look in the “primary” key of the result of your WAN ip info, shown just above.

https:// [CradlePoint IP]/api/status/wan/devices/lte-REDACTED/diagnostics

“data”: {
“HM_PLMN”: “310410”,
“CELL_ID”: “176898562 (0xa8b4202)”,
“CS”: “UP”,
“PRD”: “MC400LPE (SIM1)”,
“VER_PKG”: “,005.010_002”,
“MDL”: “MC400LPE (SIM1)”,
“TXCHANNEL”: “20576”,
“MODEMOPMODE”: “Online”,
“ROAM”: “1”,
“VER”: “SWI9X15C_05.05.16.02 r21040 carmd-fwbuild1 2014/03/17 23:49:48”,
“CFGAPNMASK”: “65534”,
“MODEMPSSTATE”: “Attached”,
“RXCHANNEL”: “2576”,
“VER_PREF_PKG”: “,005.010_002”,
“RSRQ”: “-7”,
“RSRP”: “-90”,
“DBM”: “-69”,
“SCRAPN”: “16”,
“SS”: “100”,
“LAST_PIN”: “”,
“BANDULFRQ”: “824-849”,
“TX_LTE”: “-6.5”,
“RFBAND”: “Band 5”,
“SELAPN”: “1”,
“SINR”: “21.2”,
“EMMSTATE”: “Registered”,
“CHIPSET”: “9X15C”,
“MODEMTEMP”: “40”,
“HW_VER”: “1.0”,
“IS_LTE”: “true”,
“MFG_MDL”: “MC7354-CP”,
“MFG”: “CradlePoint Inc.”,
“PRLV”: “1”,
“LAST_PIN_VALID”: “False”,
“PRI_VER”: “05.03”,
“DEFAPN”: “1”,
“DORMANT”: “Dormant”,
“PUK_RETRIES”: “10”,
“EMMSUBSTATE”: “Normal Service”,
“MODEMIMSSTATE”: “No service”,
“CUR_PLMN”: “310410”,
“BANDDLFRQ”: “869-894”,
“RFCHANNEL”: “2576”,
“PRI_ID”: “9903437”
“success”: true

My favorite (so far) is a bit difficult to explain in this blog post, but I’ll try:

https:// [CradlePoint IP]/api/control/netperf

To use this, you need 5.4.0 or newer firmware, and you’ll really need your own NetPerf server, but if you get that set up, you should be able to initiate your own speed tests across the LTE link.  You’ll need to pass data to this one, though, so it’s a bit harder.  Here’s my data template, with words surrounded by percent signs as variables.

$json_template = ‘{“input”:{“options”:{“limit”:{“size”:%size%,”time”:%timeout%},”port”:””,”host”:”%host%”,”ifc_wan”:””,”recv”:%recv%,”send”:%send%,”tcp”:true,”udp”:false},”tests”:null},”run”:1}’;

After customizing this for the test that I want to perform, I do a HTTP PUT of this data.  In my case, with PHP, I have to pass my $json like this:  array(‘data’ => $json).

Anyhow, doing this kicks off a speedtest that runs for %timeout% seconds.  You can then to a GET to the /api/control/netperf URL and get a status, like so:

https:// [CradlePoint IP]/api/control/netperf

“data”: {
“input”: {
“tests”: null,
“options”: {
“udp”: false,
“limit”: {
“size”: 0,
“time”: 10
“tcp”: true,
“recv”: true,
“port”: null,
“send”: false
“output”: {
“results_path”: null,
“status”: “idle”,
“command”: null,
“error”: null,
“progress”: 0,
“guid”: -1
“success”: true

In the “output” section above, had I just performed a test, I could look at the value of “results_path”, which is a URL to the results of the test.

There is a TON of great info you can get from the CradlePoint API.  CradlePoint built their web interface off of the API, so pretty much anything you see in the web interface can be accessed via the API.  In fact, if you simply use a tool like HTTPwatch to look at the interaction between your web browser and the remote CradlePoint device, you’ll be able to learn how to do all this yourself.


June 30, 2015 at 8:29 pm 10 comments

CradlePoint configuration file format

What’s a CradlePoint?

We’ve recently been considering the use of CradlePoint routers.  CradlePoint specializes in routers that work with wireless providers.  Some companies make routers that have 3G or 4G compatibility with a limited set of hardware, but CradlePoint made a business out of trying to support a significant number of them.  According to my initial tests and their documentation, it should support just about every 3G modem we’ve used over the last 3 years or so from AT&T, Sprint, and Verizon, including some new ones we just got in.

We’ve actually been pretty impressed with the level of detail found in the CradlePoint.  It gives us far more information about the cellular signal than our current 3G solution, potentially helping us to make decisions that could affect our customers.

The Plan

In an ideal world, we’d like to configure one CradlePoint router the way we want it, backup the configuration file, then take that and turn it into a template with variables in place for everything that’s unique at each site.  Using our existing site database, we could churn out configuration files for just about every remote site.  We might need to have a different template for each wireless provider, but we could make it work.

The Problem

However, when you backup the configuration, you get a binary file.

Searching through their knowledge base turned out to be a waste of time.

In an earlier version of CradlePoint software, the configuration was in XML format.  From looking at their CLI, it looks like they’ve moved on to JSON formatted data, which is probably for the best.  It’s less prone to issues than XML, according to what I’ve read.

Using their CLI, you can do a “get” from the root and get the entire config in clear text, but you get a lot more than you need (including log files, etc).  There’s a config directory you can cd into, then do a “get” and you’ll get most of what you need.  But, looking through the results, you’ll see that it’s missing some key things that are located in other sections of the file system, like the network and port configuration.

Their Enterprise tech support was not very forthcoming on the matter.  They don’t want to share the format.

What’s the Big Deal?

CradlePoint has a service (ECM), which is basically a Saas central manager for their routers.  I dislike Saas, as a general rule.  Sure, you have subscription services for anything security related, but a subscription to manage my hardware?  It seems that they include this with support now, so it’s “free”, as long as you are keeping up with your support.  Edit:  Nope, I was wrong here.  ECM is a separate service.

I think they have obscured their format precisely to keep people from being able to do what I like to do:  script my own configuration.  We are considering setting up VPN’s across our CradlePoints.  We are all about security, so we’d want a large unique key for every site, and a way to update them periodically.  We’d have to keep those configurations in-sync with the devices at the headquarters end of the VPN tunnel.  Scripting sounds like a perfect solution to these problems, and we can do that if we know the format of the files.

Now, ECM may still have a potential use in my environment.  If it can do a good job of helping us manage AT&T, Sprint and Verizon, it might be worth having, as long as you can just use it to monitor the CradlePoints.

Final Words

CradlePoint, open up your config file format.

You’ll be more likely to get customers like us who want to automate everything ourselves.

April 13, 2015 at 9:52 pm 1 comment


July 2017
« May    

Posts by Month

Posts by Category