Personal tools
You are here: Home / Members / alex's Home / Slug Trails

Slug Trails

The Linksys NSLU2 (aka Slug) is an excellent platform for a remote data logging and forwarding. These are the steps I took to set things up to get data from a weather station onto our sailing club website.

When our sailing club was offered a brand new weather station, being the club's website maintainer, I wanted to get the data online as soon as possible -- if there's anything to unite a bunch of sailors, it's watching the weather.

The Linksys NSLU2, colloquially known as the Slug, is cheap -- at around £50 -- quiet, low powered, small and generally seems like an excellent choice for this kind of application.  I wanted something which could be installed and would just run without worry for a few years, much as you'd expect any other network equipment like routers or print servers to do.

Customizing a Slug is all about choosing which Linux based distribution to use to replace the Linksys default firmware.  There are two or three choices depending on the sort of application, but for the weather station software I wanted to use -- wview -- the easiest seemed to be to install SlugOS, as a package feed is available with wview already compiled.  Another good feature of SlugOS is that it's based on the OpenEmbedded platform, which I'd already used a while back when customizing my old Sharp Zaurus.  This pedigree suggested that it would be a good fit for the small amount of RAM available on the Slug.

Installing SlugOS is relatively painless.  I followed the instructions on the wview pages.  With the same instructions, I installed the right kernel module for my USB to serial converter.

The original intention of the NSLU2 is to act as a Network Attached Storage device and make USB based hard drives accessible over a network as SAMBA shares.  In my case, a hard drive was overkill and the current price of USB flash drives meant that a 4GB USB stick only added a few pounds to the overall price and provided plenty of space for installing software and storing weather data well into the next century.  I put the flash drive into the second USB slot and enabled the ext3 flash hack to avoid having the kernel constantly and unnecessarily flip bits around in the flash memory.

Now for internet connectivity.  Lately, "mobile broadband" is all the rage, offering the ability to plug a USB stick based mobile phone into your laptop and get broadband style, always-on, internet.  I opted for 3's Mobile Broadband package which, for £10 per month gives an always-on connection with a maximum traffic allowance of 1GB per month, which is plenty enough for the sort of data I want to get to our web server.  I ordered a Huwai E169G USB mobile modem and managed to get it going on the slug after a bit of work.

Firstly, plugging in the USB modem, it handily pretends to be a CDROM drive with an "Autoplay" CD in it, so that Windows users can happily give Administrator rights to third parties and have drivers automagically installed for them.  In our case, the kernel drivers for USB serial devices are already installed, but we need to do some USB magic to tell the modem that it really is a modem and not a CDROM drive.  For this I followed some advice from an EeePC user and compiled usb_modeswitch:

cd /tmp
ipkg install gcc gcc-symlinks
tar -jxvf usb-modeswitch-0.9.3.tar.bz2
cd usb-modeswitch-0.9.3
mv usb-modeswitch /usr/local/sbin/

After some hacking, I managed to get the modem recognized as a modem and configured PPP to dial up and create a connection.  The next step was to automate all of that so that the connection would come up at boot time.  Here are the extra ipkgs I can remember installing followed by the configuration files and scripts I used:

Extra Packages

  • dnsmasq -- I've also made the Slug a wireless hotspot by connecting up an old WAP54G wireless router.
  • gcc and gcc-symlinks for compiling usb_modeswitch
  • iptables, kernel-module-ip-tables, kernel-module-ipt-masquerade, kernel-module-iptable-filter, kernel-module-iptable-mangle, kernel-module-iptable-nat, kernel-module-nf-conntrack, kernel-module-nf-conntrack-ipv4, kernel-module-nf-nat, kernel-module-nfnetlink, kernel-module-x-tables, kernel-module-xt-conntrack, kernel-module-xt-state, kernel-module-xt-tcpudp
  • kernel-module-pl2303 for the USB to serial converter
  • kernel-module-ppp-async, kernel-module-ppp-deflate, kernel-module-ppp-generic
  • kernel-module-usbserial
  • mysql-client
  • openssh, openssh-scp, openssh-ssh, openssh-sshd
  • openvpn
  • ppp
  • setserial
  • update-rc.d
  • usbutils
  • wview-vpro-mysql



# start and stop the modem, if connected


  /usr/local/sbin/usb_modeswitch -v 0x12d1 -p 0x1001 -d 1 -H 1

  until [ -c /dev/modem ];
  do sleep 1; done
  stty -F /dev/modem speed 460800
  until chat -v ABORT 'CGATT: 0' "" ATZ OK AT+CREG\? OK AT+CGATT\? OK < /dev/modem > /dev/modem ;
  do sleep 10; done

case "$1" in
    sleep 10
    pppd persist call three
    killall inadyn
    echo "Usage: $0 {start|stop}"

exit $RETVAL


BUS=="usb", KERNEL=="ttyUSB*", ATTRS{interface}=="Data Interface", ATTRS{bNumEndpoints}=="03", ATTRS{bInterfaceNumber}=="00", SYMLINK+="modem"
BUS=="usb", KERNEL=="ttyUSB*", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="serial"

Note that these UDEV rules are to disambiguate the modem from the USB to serial converter, as they both present as serial devices -- in fact the modem presents a few serial devices and I pick the first.  Constraints with UDEV rules means that we can't choose attributes from multiple parts of the device path, but the above is specific enough to get things right on my setup.


/dev/modem 460800 crtscts modem
connect 'chat -v -f /etc/ppp/'


"" "ATZ"
OK "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0"
OK 'AT+CGDCONT=1,"IP","3internet"'
OK "ATDT*99#"

And since the nameservers given by 3's PPP connection aren't reliable, I use OpenDNS:



Adding the 'modem' script to startup is done using the update-rc.d command:

update-rc.d modem defaults 10

These configuration files should be enough to set the modem up and start a PPP connection at boot time.  Since I also wanted to be able to SSH into the Slug from outside, I was hoping to get a public IP address, but that only seems to happen every so often.  An email response to 3 technical support was only enlightening in that it reveals that they're neither technical nor supportive.

The easiest thing was to set up OpenVPN to add the Slug as a client to my VPN, after which I can just SSH in to the VPN address of the Slug.

Document Actions