Configuring Tomato....

I thought I'd add some notes on the setup I'm using for Tomato on the router, just in case anyone wishes to follow and finds them useful. Please note that these are simply the ways I've found of doing the things I find useful, they are not necessarily the best ways nor the only ways - so I'm open to suggestions...

Persistent Storage

The only persistent storage on most routers is NVRAM, this is limited both in size and life, ie. each write action diminishes the life of the module (much more so than with, say, a hard drive). The Tomato implementation makes the firmware read only, any files that need to be read/write are created under /tmp directories during boot and are lost in a power down or reboot.

This can be a nuisance if you use logging to create a long term record of bandwidth usage, useful with a capped mobile account. It also means there is no way to store your own programs or other files that are not part of the firmware.

It is possible to create a persistent file system within the router using JFFS. Tomato provides menu support to format JFFS so, providing the router has sufficient RAM available, this is one way provide persistence. I've created a jffs filesystem and my bandwidth log, system log, kplex and VPN certificates are kept on it. The jffs filesystem is enabled fairly early in the boot sequence so putting the system log on it, whilst it doesnt show a complete record, is perhaps a good compromise.

It is also possible, with TomatoUSB, to use USB storage devices. I have a micro SD card as part of the mobile dongle. That has been formatted as an ext2 filesystem, because this hardware also suffers from write limitations and ext2 has no journalling, to use with the router firmware. It is on this device that files not needed for day to day router operation are kept. These include kplex source, tomatoware, entware and couple of large utilities. When tomatoware or entware programs are required, that directory can be mounted on /opt or wherever else it is required. The firmware takes care of mounting the filesystem as a whole.

Bandwidth Monitoring

As said above, its useful to keep track of data usage if only to verify the information recieved from your ISP. Enabling bandwidth logging and putting the log file into the jffs filesystem means that usage data survives reboots. By excluding the wireless device traffic from the logging I can ensure that the kplex NMEA traffic is not added to the internet data traffic. I have verified this by comparison with ISP records.

VPN

I currently use the Astrill VPN service. Astrill provide an install script for Tomato and DD-WRT which adds an explicit menu item to Tomatos user interface. However, what this actually does, given the firmware filesystem is read only, is place a script into NVRAM which is executed at boot to download and install the Astrill menus and operating files. This only works if the router has a working internet connection at boot time, not guaranteed on board. It also uses some 2.5k of valuable NVRAM space with all the variables it sets up.

It is also possible to obtain the VPN access certificates from Astrill, then configure the VPN access 'manually' storing the certificates, which are user unique, on the jffs filesystem. The downside is that its slightly more difficult to change end points but the advantages are that the VPN service is always there ready to use, start up of the service is far quicker than the cumbersome Astrill provided scripts and there is very little NVRAM used - the advantages far outweigh the disadvantage.

Utilities

WinSCP and putty, both invaluable. WinSCP to transfer files from Windows and make editing much easier on the router (I dont have to struggle with vi :)).

All that said, I'm planning to try implementing OpenWRT instead of Tomato fairly soon. I think that might resolve, or provide the tools to resolve, the problems I'm seeing with conflicting serial devices.

Disributing NMEA through a router

Whilst setting up my router, I was browsing a thread on one of the YBW forums and wondered if I could also use the router to distribute NMEA data on the boat wirelessly. I use OpenCPN (OCPN) as my primary navigation tool and chart plotter, copying routes to a handheld Garmin GPS72, using GPS Utility, for cockpit use. Very occasionally it is useful to be able to move the laptop running OCPN into the cockpit but the cabling doesnt easily permit this.

Initially, I looked at using the features of OCPN 3.1+ to retransmit NMEA data received by OCPN using IP addresses. This worked well, passing the data wirelessly through the router to another laptop running OCPN in the cockpit. However this requires twice the power so it would be better to have the NMEA going straight into the router and being distributed from there.

At this point I was directed to kplex by its author, Keith Young. Now kplex looked to be able to do exactly what I wanted, and much more, but had so far only been compiled to run on Linux (Intel), OSX and the Pi. It was, however, written as a POSIX compliant program so any platform running a suitably compliant OS should also run the program. My main router, the RT-N16, with its Tomato firmware is exactly that as the underlying OS is Linux. So, I set about looking into a cross-compile environment because the hardware that runs the RT-N16 is a Broadcom MIPSEL based processor.

At this point things get messy as sorting out how to create a MIPSEL cross compile environment on the Linux image of my laptop took a while. Although I got one working, there were still some false starts to get it configured properly to compile kplex, its probably 20 years since I did this stuff. Eventually those were worked through and I got a program that compiled and ran when transferred to the router, hurrah! Except Keith pointed out that the segmentation violations I saw when some invocations were a bit wrong shouldnt happen and shutting the program down required a 'kill -9'. Now anyone with a bit of UNIX recognises that -9 is a bit like taking out a mafia contract on your program, there is extreme prejudice involved, which shouldnt be necessary for a well behaved program. Keith was fantastic in trying to offer notated versions of his code to track down what was happening but to no avail, subsequent events show that kplex was not in error - my compile environment was the problem. Nonetheless, I had a working program.

Next job was to make it useful. The first diagram shows the wired connections to my laptop and the way the data flowing through the connections is used. Getting the GPS and AIS inputs configured was relatively easy, but first you do need to get the USB connections recognised. Fortunately the serial-USB converters I have are FTDI and Prolific, both of which have drivers available within Tomato. The 'shibby' variant of Tomato provides both drivers including the current version of the FTDI driver. These are not made part of the OS at boot time but must be added in using 'modprobe -a ftdi_sio pl2303'. Once this command is run and the USB cables connected, the two adapters are given USB port numbers and can be addressed by programs running on the router.

Now we are cooking: configuring kplex and OCPN took several trials. What seems to work well is combining the GPS and AIS data streams using kplex to multiplex those onto port 10110 of the router. Then configuring OCPN to use the router IP address and port, 192.168.20.10:10110, as a data connection in the same way as a directly attached COM port.

Getting the output portion of the data stream to the autopilot was less obvious. Any attempt to combine inputs and outputs using kplex and OCPN talking to the same port on the router led to OCPN freezing its data stream until the output connection was disabled. What worked was setting up OCPN with a connection on the laptop to a unique port, 192.168.20.118:10111. Then using kplex as a TCP client listening for data from that port on the laptop. So the autopilot output data stream is a separate connection in OCPN talking to a kplex client on the router, though the kplex client then outputs the received data down the same USB connection as the GPS input. At present OCPN closes the output connection data stream when the 'options' dialog is open, the lack of data can cause kplex to close the client down unless it uses the 'persist' option available from version 1. The two kplex invocations are shown below:

<!-- This one does the inputs -->
kplex -o mode=background
serial:name=AIS,direction=in,filename=/dev/ttyUSB0,baud=38400 serial:name=GPS_IN,direction=in,filename=/dev/ttyUSB1
tcp:mode=server,port=10110

<!-- This one does the output -->
kplex -o mode=background
serial:name=AUTOPILOT,direction=out,filename=/dev/ttyUSB1 tcp:mode=client,persist=yes,address=192.168.20.118,port=10111

The message filtering required for the output could be done by either kplex or OCPN, I've chosen to use OCPN. The only messages output are ECRMB, ECRMC and ECAPB. These are all generated by OCPN containing position, waypoint and route information ensuring that only OCPN derived routes are followed. This stops any transfer of 'goto' data deriving from the GPS 'talker' on the NMEA system, the Furuno GP32, to the autopilot. The wiring of my boat forces the Furuno to autopilot connection to be indirect, this could be bridged by using kplex to send data out by defining input and output stream in the same instance with appropriate filters.

The configuration described here, rather long windedly, is shown in the second diagram of this piece. All this has now been working reliably for about a month, running kplex in parallel with the routers main function of making internet connections available to all on board.

Even better I recently found another method of compiling kplex which makes it behave as it should :) This makes use of 'tomatoware' running on the router, a utility I found through Tomato's forums on linksysinfo. Its author, a lovely bloke called Lance, helped me out with compile options (-zmuldefs -static) to make kplex standalone with all its function self contained. So now I think I have a version of kplex that should run on any MIPSEL device using Linux based firmware.

There is, of course, a gotcha to all this good stuff. Sadly the mobile dongle support in Tomato, remember that ??, doesnt like having other serial devices around when it tries to reconnect. This will happen from time to time as you move around and change cells or just as the signal fades in and out. I'm still trying to work out whats going on here, but in the interim the Ericsson box is plugged into the WAN port on the router and the SIM card is in the Ericsson box

Connecting to the Interweb - II (2013)

The project for 2013 mostly stemmed from a desire to be able to share both a wifi range extender and the VPN service but, as most projects do, has suffered some scope creep!

The Alfa solution of an AWUS036 + R36 creates a wifi range extender / wireless access point (AP) pair and is used by many cruisers, however it wouldnt do the VPN part. It could have been used, with hindsight, as a WAN input to a domestic router however I chose to use a Ubiquiti Bullet as the range extender. The choice was based on its having an ethernet interface and powered through power-over-ethernet (PoE). I felt a long ethernet cable to be a better solution than either a long USB cable (potential 5v power loss) or a long aerial (signal losses).

The choice of the Bullet was partly based on that device having support from DD-WRT, an open source wireless router firmware project, which also supports OpenVPN. As I subsequently discovered, the developers on that project dont consider either the processor or memory of the Bullet sufficient to run VPN in addition to base function. The Bullet has been reconfigured with Ubiquiti's original firmware as the wifi 'scan' function is easier to use so it is solely used a wifi extender.

So I looked elsewhere for a solution to providing VPN centrally.

Where I ended up was with an ASUS RT-N16, a popular domestic router, which has a reasonable processor and good memory for the price - oh, and a 12v power supply. It has a WAN port so both the Bullet and the Ericsson boxes can be plugged in directly via ethernet. Another facet of this project, as it developed, was that I should be able to plug a mobile dongle into the router and have that provide the mobile ISP connection rather than the Ericsson box. The ASUS has two USB 2.0 ports so should support a dongle with the right firmware. I then tried several variants of firmware, including DD-WRT, before settling on TomatoUSB. Specifically the 'shibby' variant of TomatoUSB for reasons that I will outline later.

Configuring this was relatively straightforward, especially when using the original ASUS firmware as this points you in the right direction for later work with other firmware. Particularily in that the WAN devices need to be on different sub-nets to the AP function in the ASUS. I've used a convention of having the AP sub-net as 192.168.20.xxx and the WAN devices with 192.168.10.xx addresses.

In fact the firmware I'm currently using does an adequate job of connecting through a mobile ISP using a dongle, in my case a Huawei E367. Configuration is straightforward using the Tomato built-in browser interface.

There are a number of guides to configuring various devices to be found through Google. Most useful were the initial ones on setting up the Bullet for travelling use, although mainly aimed at US RV users.

Connecting to the Interweb - I (2011/2012)

As a a preamble to this, I'm not convinced that the current trend in computing towards the 'cloud' is entirely useful to the cruising yachtie. The main reason is that, by nature of our movement, the connection we may get to the internet is often poor or expensive or both. The connection we have is likely to be capped if from a mobile provider. Thus we cannot really migrate data or applications in daily use to the cloud as there is a good chance they will be unavailable or unaffordable when we actually need them.

A good example is email, I use the Thunderbird email client to trawl the several accounts I have for new mail which is transferred to my laptop. Thunderbird can make use of an otherwise iffy connection because the data transfer is smaller than the overhead of conecting with each email provider online, there are no ads or other extras adding to the data transferred. Thunderbird can also be configured to download a maximum of so much data, so if your mates send you all thier holiday snaps they stay on your email providers server until you choose to go get them (but you do know they are there as Thunderbird will have a partial message registered). Its a bit like getting text messages, they can pop up when you dont know a connection exists (provided everything is hooked up).

However, the internet is an invaluable resource for all sorts of things which I'm loathe to be without. So, we left the UK expecting primarily to gain internet access by buying a data SIM card in each country. To facilitate this, and make the connection shareable by all onboard, we had been given an Ericsson W25. This is an early form of MiFi device, in that you slip your SIM card into the device, configure it with PIN/APN etc and it connects to the mobile ISP whilst providing a wifi access point on board.

This has worked well in Spain, Portugal and Italy (MASMovil, Vodafone & WIND respectively) but failed in France (SFR) where the purchased service did not deliver. In Spain we had a data allowance of 5Gb/month which was marginal, we blew it occasionally - expensive; in Italy we have 10Gb which, for two people, gives a margin of comfort and allows both to indulge our interests and download an hour or so of TV each week.

I would also suggest that anyone with a capped mobile connection installs adblockers to their browser.  A little experimenting showed that when using the YBW forums, ads added a 30% overhead to the data traffic - extrapolate that out and you lose a significant proportion of your data to stuff you dont want.

On those occasions where we had access to a wifi signal, in marinas mostly but once or twice at anchor in France, we have a USB WiFi booster with an external aerial that could be hauled up a flag halyard. Without some work this restricts the signal to one device so we had to take turns using it. We also subscribed to a VPN service for two main reasons; first, to increase the security of our data between each laptop and the internet; second, to appear to be in the UK mostly for broadcast material access. The VPN service is a single login so could only be used one at a time.

All this worked well for us through 2011 & 2012 but for 2013 I wanted to make some changes and be able to share more.

Introduction: What this blog is about

This is likely to be a very occasional blog about some of the techy bits of living aboard whilst cruising.

The boat is a Rival 41 called Spring Dawn, previously Greebo. She is a centre cockpit Peter Brett design, built in Southampton in 1983 by Rival Yachts at Willments Shipyard, Woolston. My association with Springy began in 2009 when I bought her through Berthons in Lymington. She was out of the water for much of that year, initially at Berthons and later at Saxon Wharf in Southampton. This was partly because I wanted to coppercoat her bottom and partly because I had no other mooring arranged. She was launched in October 2009 and spent her first winter in Swanwick Marina, moving down to a pontoon on the Hamble in early April 2010.

In 2010 we sailed the west country and learned that the sails were really as bad as they looked, worse even. So in the winter Peter Sanders made a new main and furling genoa. The main is vectran with 5 battens, the jib dacron and about 120%. The old genoa had been around 130% but was heavy to handle when close hauled, hence the slightly smaller replacement. Winter 2010 was again spent in Swanwick.

In June 2011 we left the Hamble to go cruising, this story is told in our cruising blog.

btw, the photo appears slightly cropped as taking another step back just wasnt an option :)