OpenWRT update on an NSLU2 (and some minor OSX stuff mixed in as well)

This is my first blog post in quite a number of years. I had to rescue my website from some unknown corruption that prevent it from being visible a few weeks ago, so I figured I should at least do something with it again. Not sure how regular I’ll be at posting, but I wanted to get this down so that I don’t forget how to do it again in a few years. Maybe it will be helpful to others as well.

Background on the NSLU2

The original use of the NSLU2 (or slugs people started calling them since the name is a few letters off and NSLU doesn’t exactly roll off the tongue) was to act as a very basic home NAS device before they became semi-mainstream (at least to tech people) and inexpensive compared to multi-drive raid configurations with full enclosures. It has two USB 2.0 slots on the back, a 10/100 Ethernet port, and had a basic linux build with SAMBA to share the drives and a simple web GUI to configure the shares and permissions. I’ve owned a pair of slug’s for a while; I picked up my first one at Bookmans, a cool, local used books and entertainment store and another as a good deal off of an online auction site in case I bricked the first one.  I just dusted both off after they sat around for a doing not much after we packed up everything to move into our house a year and a half ago to try to put them to good use. Side Note: I don’t purport to having been the original source any of this software or directions, I’m just stringing together the works of many other people into a useful platform for myself to play with in the little spare time that I have now that we have a lil one to help take care of at home.

A Sprinkling of OSX

One of the primary websites detailing the installation of alternate operating systems on a slug suggested either Macports or HomeBrew for running the scripts needed to reprogram the slug hardware in recovery mode from the OSX computer.  I’ve toyed with Macports in the past; it’s been a bit of trouble to get things working just right, so I went with HomeBrew this time around to allow the use of some linux scripting and tools on my mac laptop. Once Homebrew is installed and all issues with it have been wrung out by running brew doctor, download the slug updater software maintained here by running the following command:
brew install
Homebrew stores everything within the /usr/local/Cellar directory, so go there and then dig into the upslug2 directory structure to find the binaries needed to reprogram a slug.  To be able to run the script properly, however, you’ll have to make sure that your user has appropriate access to the sudo command. If you’re account on your machine is an administrator on that computer, you should be OK to proceed (though you should think strongly about revoking administrator rights from yourself in favor of having one account that you don’t use for anything other than installing and setting up the system for security’s sake).  If you do not have admin rights, you can make sure you can run the sudo command doing the following from the terminal:

su <administrator user name>

sudo visudo

Then make sure that your username is listed in there as having rights to use sudo.  One potential setting is as follows within the privilege specification section:

<normal user name> ALL=(ALL) ALL

Preparing beforehand

The next step after getting the software installed on your computer is to determine what the slug’s MAC address is; this is required by the upslug2 software to update the OS from the command line.  You may be able to get this from a web GUI for the slug, however there are other ways to determine the MAC.  Note: the most reliable way of communicating with the slug is to hard-code the address of your network card to something on the same subnet as the slug, physically connect to the slug directly that network card, and to turn off all other network connections. If you know the IP address, do a quick ping <ipaddress> from the command line followed by an arp -a, which will show you a result similar what I found:

? (192.168.1.xx) at 0:f:66:7b:ea:5 on en0 ifscope [ethernet]

If you don’t know the IP address you can run nmap -v -sn (or whatever your network subnet address is set to) to locate hosts denoted as being up on the network followed by a ping of that address and an arp.  As an FYI, the arp command truncates the hex values to shorten them to a single hex digit; when using it in the following steps, you’ll have to expand to the full MAC address to be 00:0F:66:7b:ea:05.

Download to the latest OpenWRT Build

Prior to this update endeavor, I had older OpenWRT Kamikazi-based versions of the Embedded Linux OS installed on both devices.  Due to size restrictions of only having 8MB of FLASH to store everything, it wasn’t just a simple “go to website and select new firmware to update device” like a lot of routers support or even the normal command line update method within OpenWRT. After a little digging around the download site at OpenWRT, I found that the latest main-line build of OpenWRT still supports a minimal build tailored for the slug.  The openwrt-nslu2-squashfs.bin file within either the (Experimental) or (Stable) directories is the one you want to download to a convenient location on your computer.  As with all critical software downloads, it’s prudent to check the md5sum of the binary file with the reference one stored within the md5sums file within that same directory.

Entering failsafe Mode on the a Slug

For this next step, I find it easiest to use a small jeweler’s screwdriver or a paperclip.  While the slug is plugged in and turned off, hold the reset button on the back of the device, turing on the slug, and wait roughly 10 seconds for the red light to start blinking to denote failsafe mode is running.

Updating the Firmware

Just a quick warning, this next step is quite time consuming (I’m not sure how long exactly as I tended to kick this off prior to going to sleep at night).  The software has to fully erase almost all of the FLASH on the slug, transmit the new software in small blocks of code to the failsafe software running on the slug, write the chucks to memory, and then after writing all of the updated OS to the memory, it verifies the contents of the FLASH.  If you’re ready to go with doing this, return to the /usr/local/Cellar/upslug2/<version number>/sbin directory and run the following:

sudo ./upslug2 -d en0 -t <MAC address located in prior step> -i <Full path to OS update binary file>

Upgrading LKG7BEA05 00:0f:66:7b:ea:05 . original flash contents  * packet timed out ! being erased                  – erased u being upgraded            U upgraded v being verified                V verified Display:   <status> <address completed>+<bytes transmitted but not completed> Status:   * timeout occurred + sequence error detected   * d4cbf+0005c0 …UUU*———————————————————


Configuring the Slug’s Network Settings

After being reprogrammed, the slug comes up with a default IP address of and has it’s SSH client disabled until a root password has been set.  Telnet into the box, run the passwd command to set the password, and then exit telnet and connect to the box with SSH. Interestingly, this version of the OS doesn’t include a web page to manage the NSLU2, so all of the rest of the settings have to be done old-scool, by hand from the command line until enough has been configured to allow the slug to see the world when you place it back on your network. The slug has VI installed as it’s basic file editor, so use that to modify the /etc/config/network file to update the IP address and add a few other mandatory settings to allow the slug to talk to the world (in bold):

vi /etc/config/network

config interface ‘lan’

option ifname ‘eth0’ option type ‘bridge’ option proto ‘static’ option ipaddr ‘192.168.1.xxoption gateway ‘’ option dns ‘’ option netmask ‘’ option ip6assign ’60’

Following that change, you can unplug the slug’s direct ethernet from the computer and it should now play well with your network.  Once you’ve plugged it into the network and turned it back on again, ssh back in and run a ping of a major website to make sure the NSLU2 can get there.

root@OpenWrt:~# ping PING ( 56 data bytes 64 bytes from seq=0 ttl=55 time=33.224 ms 64 bytes from seq=1 ttl=55 time=33.210 ms ^C — ping statistics — 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 33.210/33.217/33.224 ms

Installing the LuCI Web Control Panel

At this point, I noticed that the /etc/init.d/ directory didn’t have a startup point to run a webserver and the LuCI web control panel wasn’t installed.  A little searching on OpenWRT’s website found this page with instructions on how to install and get everything running. A few quick command line command and you’re up and running with a shiny new NSLU2 running OpenWRT that can be used to do just about anything you want. Run opkg update to update the installation tool with points to the latest versions of all software

root@OpenWrt:~# opkg update Downloading Updated list of available packages in /var/opkg-lists/barrier_breaker.

Run opkg install luci to install the luci web control gui for OpenWRT and then opkg install luci-ssl to enable secure https web access to the server.  The first command automatically installs the uhttpd web server since it’s a dependency of the luci package, so the slug is just about ready to run at that point.  Just issue the following command to start and enable the webserver to start on power on and you can then easily manage the slug without ssh-ing into it to manager.

root@OpenWrt:~# /etc/init.d/uhttpd start Generating RSA private key, 1024 bit long modulus Generating selfsigned certificate with subject ‘C=DE;ST=Berlin;L=Berlin;CN=OpenWrt;’ and validity 2014-01-12 20:32:03-2016-01-12 20:32:03 root@OpenWrt:~# /etc/init.d/uhttpd enable

What’s Next?

The LuCI GUI allows you to install packages from the web and do a lot of other customizations to the hardware without touching a command line.  You can use that to install scripting languages or even small compilers to write your own software to run on the slug (or you can cross compile local to your computer and move the software onto the slug to run if there isn’t enough room for a compiler).  I’m thinking of installing the USB support drivers for serial ports and then connecting a simple serial LCD to the unit to display status information for a project I have in mind.

Here’s a helpful script that I found on this blog; to update all installed packages run the following command from the command line:

eval $(opkg list_installed | sed 's/ - .*//' | sed 's/^/opkg upgrade /')



Comments are closed.