What do you do when you want to do something that the Opengear ACM5004 doesn’t support out of the box? You roll your own firmware, that’s what!
In reality, you only need to do this if you want to install packages that aren’t included already, or to make permanent changes to other core files, so it’s not something most people are likely to do. Still, I like to play around with hardware, and hopefully I can create a basic guide that’s helpful to anybody who wants to try it.
Ingredients for Opengear Firmware
To build your custom firmware, you will need:
- A 32-bit Ubuntu host on which to build your images (VM is fine), with permissions (i.e. root/sudo root) to install packages
- An Opengear Custom Development Kit (~150MB download)
- An Opengear linux tool-chain (~230MB download)
- The ability to transfer files in and out of the Ubuntu host
The Custom Development Kit (CDK)
Opengear make the CDK available for download by any user from http://opengear.com/download/cdk/ – a listed directory with a bunch of files in it. For the ACM5400 I guessed at a need for the 500x devkit, and I also grabbed the User Guide:
The first thing to note is that these files are dated July 2012, but the latest firmware versions are from October/November 2012. This is the first ‘gotcha’ when rolling your own firmware – the CDKs contain a version of firmware that you can alter, but the CDKs are not updated at the same time as the available firmware releases. In this case, the CDK contains firmware v3.5.3, whereas the latest available trains on the download page are actually v3.5.3u5 and v3.6.0. I understand that the CDK will be updated, but it lags the image release by at least a few months.
You’ll also want to go into the tools/ folder while you’re there, and grab one of the “tool-chains” within:
The ACM5004 is an ARM based platform, so I downloaded the arm-linux-tools-20061213.sh file as instructed by the User Guide. It’s not a standard shell script, but rather it’s effectively a self-extracting archive. Note – should you download using FTP – that the FTP URI given in the user guide (“ftp://opengear.com/tools/”) is incorrect – it should actually be ftp://ftp.opengear.com/cdk/tools.
Preparing Ubuntu
Base OS
The User Guide says that the instructions are for a 32-bit x86 installation of Ubuntu 10.04, and notes that the KCS and CMS product ranges will not build on a 64-bit distro. I actually installed Ubuntu 12.04 LTS Server 32-Bit in a VM on Oracle’s VirtualBox and the process seemed to work fine.
Required Packages
Next, we need to install some specific packages that are required for the build process. For ARM products (like the ACM5004) I needed to install zlib1g-dev (to confirm, that’s ZLIB1G for disambiguation purposes).
Installing the package itself was simple, but if you cut and paste the command from the User Guide, note that there’s another error – the guide shows “zliblg-dev” rather than “zlib1g-dev” (an L instead of a 1 before the g). The correct command is:
$ sudo apt-get install zlib1g-dev
For i386 products I would also need to install bin86, qemu and genext2fs, but in this case they don’t apply.
Tool Chain
Next I installed the linux tool-chain that I downloaded for use with Opengear ARM platforms:
$ sudo ./arm-linux-tools-20061213.sh
CDK Expansion
The CDK comes as a gzipped tar file (.tar.gz). You can extract the content easily with a single command. Go to the directory where you want the CDK expanded, ensure that the .tar.gz file is in the same directory, and issue this command:
tar -xzf OpenGear-ACM500x-devkit-20120718.tar.gz
This will expand the archive into the current directory. It’ll take a little while, because basically it’s extracting an entire linux installation (the one that’s going to be installed on the ACM device) into a new directory called OpenGear-ACM500x-devkit-20120718. Looking in the installation folder we now have the original gzip file and the new directory:
john@ubuntu:~/opengear$ ls -al total 152956 drwxrwxr-x john 4096 Jan 6 16:25 . drwxrwxr-x john 4096 Jan 6 16:24 .. drwxr-xr-x john 4096 Jul 17 12:31 OpenGear-ACM500x-devkit-20120718 -rw-rw-r-- john 156614121 Jan 6 16:23 OpenGear-ACM500x-devkit-20120718.tar.gz
Stepping into the new Directory, we can see the extent of the files that have been installed:
john@ubuntu:~/opengear/OpenGear-ACM500x-devkit-20120718$ ls -al total 13400 drwxr-xr-x john john 4096 Jul 17 12:31 . drwxrwxr-x john john 4096 Jan 6 16:25 .. drwxr-xr-x john john 4096 Jul 17 12:08 config drwxr-xr-x john john 4096 Jul 17 12:27 images drwxr-xr-x john john 12288 Jul 17 12:31 include drwxr-xr-x john john 4096 Jul 17 12:31 lib drwxr-xr-x john john 4096 Jul 17 12:26 linux-2.6.x -rwxr-xr-x john john 6805 Jul 17 12:31 Makefile drwxr-xr-x john john 4096 Jul 17 12:09 modules drwxr-xr-x john john 4096 Jul 17 12:20 openswan -rw-r--r-- john john 11034 Jul 17 12:31 README -rw-r--r-- john john 13636394 Jul 17 12:31 romfs.tar.gz drwxr-xr-x john john 4096 Jul 17 12:31 tools drwxr-xr-x john john 4096 Jul 17 12:30 uClibc drwxr-xr-x john john 4096 Jul 17 12:31 user drwxr-xr-x john john 4096 Jul 17 12:31 vendors
Making Changes
In my case, I didn’t initially have anything that I wanted to install, so I decided to make my syslog change to the email alert script so that it would be installed as the default in the new firmware. At this point, I went hunting for the ‘alert-email’ script that I would be editing:
john@ubuntu:...20120718$ find . -name "alert-email" -print ./vendors/OpenGear/Recovery_IM4004/etc/scripts/alert-email ./vendors/OpenGear/Recovery_CM4008/etc/scripts/alert-email ./vendors/OpenGear/romfs/etc/scripts/alert-email ./vendors/OpenGear/Recovery_IM42xx/etc/scripts/alert-email ./vendors/OpenGear/Recovery_CM41xx/etc/scripts/alert-email ./vendors/OpenGear/Recovery_ACM500x/etc/scripts/alert-email ./vendors/OpenGear/Recovery_CM4001/etc/scripts/alert-email
Hmm. Well, editing this file in a Recovery folder sounds wrong to me. However, /etc/scripts/alert-email is the proper location – but it’s apparently inside ‘romfs’. Looking back at the directory listing, that directory does not exist, but I do have ‘romfs.tar.gz’ – i.e. the ‘find’ command is looking inside the gzipped archive and showing me that the file I want sits within it. So to edit it, we’ll expand that too:
john@ubuntu:...20120718$ tar -xzf romfs.tar.gz
I now have a directory ‘romfs’, and can edit the alert-email script to my heart’s content.
Building The Image
Once I made my changes, I needed to build a new image. Since I had only edited a minor file, I jumped straight for a full make:
john@ubuntu:...20120718$ make [lots of log messages] john@ubuntu:...20120718$
Very helpfully, there’s no indication (either in Ubuntu or in the User Guide) of what to do next now the make is complete. The answer is that you look in the images/ directory:
john@ubuntu:...20120718$ ls -al images total 36396 drwxr-xr-x john john 4096 Jan 6 16:52 . drwxr-xr-x john john 4096 Jan 6 16:46 .. -rw-r--r-- john john 12930915 Jan 6 16:52 image.bin -rw-r--r-- john john 11382784 Jan 6 16:52 ramdisk -rw-r--r-- john john 11382784 Jan 6 16:52 ramdisk.gz -rw-rw-r-- john john 14002 Jan 6 16:51 romfs-inst.log -rwxr-xr-x john john 1548104 Jan 6 16:51 zImage
It’s blindingly obvious (that’s sarcasm, by the way) that you will want to copy the file ‘image.bin‘ to your usual computer (if Ubuntu is not your normal host) and use the Opengear web interface to upgrade the firmware using your new file.
Other Potential Changes
The User Guide confirms that within the space restrictions of the target device, you can modify the kernel and application set (via the config system – i.e. “make config”) and you can add custom binaries in the user/ directory. I may brave this shortly – whittle down the built-in apps to make some space, and install something new that I’d like. I suspect that will take time though, so I’ll come back to that perhaps at a later date.
Benefits of a Custom Firmware Image
The obvious benefit of a custom firmware image is that you can add an application that was not available to you before, albeit with some very tight space limitations. That could open up some remarkable possibilities for how the Opengear device could be used.
From an administrative perspective though, it might be very helpful to be able to ‘lock in’ some changes in the firmware so that nobody can alter them. Remember, most of the linux image is readonly so anything in a readonly location is protected even from a root user making changes. So for example, you could remove the code in the alert-email script that checks for a similarly-named script in the user space, thus ensuring that only your chosen (readonly) alert-email script is ever run and cannot be overridden.
The only down sides I can see to using a custom firmware image are:
- You’re not getting the latest firmware image, which means you are missing bug fixes and feature enhancements as they are released;
- Opengear support may not support you on anything they believe is as a result of your custom firmware tweaks.
Of those, if you’re happily installing custom apps and building firmware images, you’re probably smart enough to troubleshoot and fix any problems you caused. Not having the latest firmware though could be an issue. I understand that firmware 3.6.0 for example has a newer cellular driver than 3.5.3 – and if I create a firmware image today using 3.5.3, I therefore am not able to use that new driver. Depending on the feature or driver missing, this could be critical in some applications. On the other hand if you don’t have any issues with 3.5.3 (and there are no security issues known with that code), you may not care, and would be happy enough to roll that out.
Workarounds?
It might be possible, I suppose, to extract the file structure from a working 3.6.0 image file and see if those files would work when compiling from the existing CDK structure. I don’t know – but I can’t help suspecting that there must be a gotcha somewhere.
Conclusions
There are a few errors and omissions in the documentation, which could be fixed easily. I still don’t like being presented with a listed directory when I go to download files (sorry). And having out of date firmware images in the CDK is a little frustrating.
However, maybe I’m being a bit picky – or even slightly unreasonable. After all, how many other companies would allow you to mess with their firmware like this in the first place? It’s an amazing thing to be able to do. Perhaps a delayed CDK release schedule is the price we have to pay for this level of flexibility.
At the end of the day, this isn’t a task for Joe User, and it’s not intended to be. The bottom line is that the firmware creation process seems to work (with a note that I haven’t added software to it), and within a fairly short time I was uploading my own firmware image to the ACM54004-G. I can’t really argue with that.
Disclosure
Opengear was a paid presenter at Networking Field Day 4, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were provided. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative. Opengear provided me with an entry-level console management device (ACM5004-G), and more recently an ACM5004-G-E, both of which I am using as test hardware to create the content for these posts.
Please see my Disclosures page for more information.
Leave a Reply