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.

Comcast blocking Plex? Probably not…

Last summer I used Plex quite extensively.  I took my daughters to swimming practice and instead of driving home, waiting 30 minutes, then driving back to get them, I decided to simply stay there and watch something via Plex on my iPhone while I waited.

Since then, I’ve only used Plex occasionally from outside the home.  Some months ago, I noticed that Plex stopped working when I wasn’t at home.  I briefly looked at it but not too closely.

I decided to dig into it tonight to try to figure out what was going on.

To test, I turned Wifi off on my iPhone and attempted to connect to Plex via LTE.  No dice.  In Plex, I went to Settings > Server > Remote Access.  It complained that Plex was unreachable from the outside.  I noticed that my firewall logs did not show any connection attempts against port 32400, the Plex default.  Interesting.  After trying a few things, I decided to try a different port.  So, I changed the Plex service object (TCP Port 32400) on my Firewall to TCP Port 34200, ensuring the NAT rule still pointed to port 32400 on my Plex machine, and updated the TCP Port setting in Plex.  Within a few moments, it showed “Fully accessible outside your network”.  I validated that I could connect from my iPhone.  Worked great.  In my firewall logs?  Yep, I’m getting hits on 34200 now.

So, is Comcast blocking Plex in NE Florida?  (*GASP*)

I’m leaning toward user error on my part (even though I don’t see an error, and it was working at one point…)

Anyhow, I’m working now…  If I suddenly can’t connect on this new port in a few weeks, I’ll revisit my theory…