As a matter of fact, there is. The excellent zbar package comes with decoders for many more types of barcodes than we actually use. Just using the demonstration zbarimg program gets answers for some of the backlog images. Some, but not enough.

Examining the images, it turns out that a lot of them are kind of faint. We need a way to darken the images enough for a barcode decoder to find the vertical bars. ImageMagick to the rescue! If there’s smething you need to do, programatically, to an image that ImageMagick doesn’t support I don’t know what it is. In this case it turns out that adaptive-blur is just the ticket: we can darken up the pixellated vertical bars that make a barcode, without filling the gaps between them.

This is my prototype toolchain: I zbarimg each image in the directory, then if I don’t find a Code 128 barcode in it, I run the adaptive blur and try again. For production use I’ll integrate these into a program, but this shows the general principle:


time (found=0; none=0; >barcodes.csv; >nobarcodes.txt;
for f in *.tif; do
barcode=`zbarimg $f 2>/dev/null | awk -F: '$1="CODE-128" {print $2}'`;
if [ -n "$barcode" ]; then
((found++));
echo $f ",1," `echo $barcode|sed -e 's/ /,/;'` >> barcodes.csv;
else
convert $f -adaptive-blur 2x1 mangled.tif;
barcode=`zbarimg mangled.tif 2>/dev/null | awk -F: '$1="CODE-128" {print $2}'`;
if [ -n "$barcode" ]; then
((found++));
echo $f ",2," `echo $barcode|sed -e 's/ /,/;'` >> barcodes.csv;
else
((none++));
echo $f >> nobarcodes.txt;
fi;
fi;
done;
echo "Scanned "$((found+none))" images, found barcode in $found, missed on $none")


Over 1,600 images (so far) the first pass is successful about 27% of the time, and the second pass another 43%. (Remember that the legacy barcode-decoder is getting the low-hanging fruit.) That still leaves us 100s of undecoded images – but a fair number of those are actually operator error anyway.

cpan is a useful little tool for downloading and installing Perl modules from cpan.org. In my work I often reach out for Perl modules, and I frequently use cpan to install them.

On one particular machine, though, cpan appeared to be broken. This machine sits behind a firewall/NAT, but big deal, they all do. I would say sudo cpan -i NewModule and cpan would hang endlessly, retrying various flavors of FTP until finally it would download its indexes, etc, over HTTP. Very annoying, because I could use wget and FTP exactly the same files in seconds from the command line.

Google around for this problem, and the answer is obvious. The firewall meant I needed to use passive FTP. Wait, not so obvious. I did export FTP_PASSIVE=1, and cpan was still unable to FTP. I also spent a while setting ftp_passive flags in various cpan config hidey holes, but in the end they didn’t do anything.

This finally dawned on me last week: I said sudo cpan -i NewModule. sudo, bless its pointy little head, tries to make the root environment more secure by filtering out environment variables! I checked, and yes indeed sudo had filtered out FTP_PASSIVE. I was busy flipping a switch on and sudo was sitting right next to me, turning it off!

The fix is laughably easy: in /etc/sudoers, look for the line with env_keep, and change it to read:


env_keep="... FTP_PASSIVE ..."


Now you can say export FTP_PASSIVE=1 in your .profile or wherever, and sudo cpan will actually see that setting. I suppose it’s possible that there’s some clever privilege escalation attack that uses FTP_PASSIVE sneaking through sudo, if your site is super-secure, you might want to look into this.

One thing that bugs me about this setup is that I hardcoded some IP addresses. This is a really bad idea, in fact half the reason DNS exists is to stop people from doing this. Someday the VPN administrators could decide to renumber their gateway, and then I would have to connect to each and every WRT and update the configuration, or all my customers would be cut off from the VPN.

I could stop hardcoding the VPN gateway pretty easily, by having it auto-update whenever the WRT boots. Look up the correct IP address and write it to /etc/hosts. (You need to be careful not to trigger the VPN autoconnect when you do the lookup, of course.)

The DNS servers are a little harder to fix. To look them up, we need to actually connect the VPN, and then pull out the nameservers that the VPN tells us to use. But this could be done automatically each time the VPN is connected, and it would make the whole setup more robust. Don’t forget to restart dnsmasq after you reconfigure it.

Another thing that bothers me is that there are a lot of gyrations before the VPN gets connected: a packet goes to a private IP address, matches on the vpn_trigger rule, which queues a message for the ulog daemon, which writes to a file, which causes the file to exist, and also causes tail to create some output, which finally causes the script to start vpnc. Whew!

One suggestion is to use inotify to watch the file, which is a good idea but still requires a file. (Also I don’t see inotify in the OpenWRT Kamikaze package list.) Another possibility would be to write a ulog plugin so that I can omit the file altogether. That might make VPN startup quicker, which would be a good thing.

Finally, if a customer wanted it, there are more sophisticated setups possible. It might be useful to connect to more than one VPN (either serially or at the same time), or to have the different LAN ports on the OpenWRT connect to different VPNs. All of these are possible if the scenario warrants it.

What are your ideas?

This process requires some knowledge about your VPN setup. To keep my post from getting too long, I’m assuming that you know your VPN domain name and IP address range, that you can quickly figure out the IP addresses of hosts and DNS servers, and that you have a working vpnc config file.

The first step is installing additional packages on OpenWRT. You can install these from the web interface, or using opkg install at the OpenWRT shell:

1. vpnc, the Cisco VPN client
2. ulogd-mod-extra, which pulls down the ulog daemon
3. kmod-ipt-ulog, kernel modules for iptables and ulog
4. iptables-mod-ulog, part of the tool for adding rules to iptables

Next, we need to make sure you can always reach the VPN gateway host. So we configure it into /etc/hosts. Look up the IP address (using nslookup, dig, or a similar tool) and add a line to /etc/hosts like:

aaa.bbb.ccc.ddd vpn.example.org


Now that we know we can reach the VPN gateway, we will redirect dnsmasq to always use the internal servers for the VPN’s domain. Look up the domain nameservers using nslookup or dig from inside the VPN, or just look at the nameservers in /etc/resolv.conf when you’re connected from your PC. Then edit /etc/config/dhcp on OpenWRT and add lines like this:

# EXAMPLE.ORG private servers
list server '/example.org/aaa.bbb.ccc.ddd'
list server '/example.org/aaa.bbb.ccc.eee'


Now, we need the script that will manage the VPN connection. Cut and paste this code into /usr/bin/autostart-vpn.sh:

#!/bin/sh
#
# Autostart vpnc
#
# From http://www.kaufmanfamily.net/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt
# DHK 4/17/2010

MYPID=/var/run/autostart-vpnc.pid
LOGFILE=/var/log/ulogd.syslogemu
PIDFILE=/var/run/vpnc/pid

is_vpn_connected() {
        connected=0
        if [ -s $PIDFILE ]; then
                ps=`ps | awk -v pid=\`cat $PIDFILE\` '$1 == pid && $5 == "vpnc" { print $0 }'`
                if [ -n "$ps" ]; then
                        connected=1
                fi
        fi
}

# Fill in our PID file
echo $$ > $MYPID

# Loop, monitoring the VPN
while true; do
	is_vpn_connected

	if [ $connected -eq 0 ]; then
		# VPN is not connected. Wait for a request, then start it

		# Wait for a log message, denoting that someone is trying to connect
		while [ ! -e $LOGFILE ]; do
			sleep 10
		done
		pkt=`tail -0 -f $LOGFILE | head -1`
		logger "autoconnect[$$] connecting due to $pkt"

		# Start the vpn
		date >> /tmp/autoconnect-vpnc.log
		vpnc >> /tmp/autoconnect-vpnc.log

		# Let the VPN settle
		sleep 2
	else
		# VPN is connected. Wait for it to drop, then clean up

		# Wait for the VPN to disconnect
		while [ $connected -eq 1 ]; do
			is_vpn_connected

			# sleep 10 seconds, check again
			sleep 10
		done
		logger "autoconnect[$$] disconnected"

		# Clean up route table
		if [ -f /var/run/vpnc/defaultroute ]; then
			outsidegw=`awk '{print $3}' /var/run/vpnc/defaultroute`
			currentgw=`netstat -rn | awk '$1 == "0.0.0.0" && $4 == "UG" {print $2}'`
			if [ "X$outsidegw" != "X$currentgw" ]; then
				if [ "X$currentgw" != "X" ]; then
					route delete default gw $currentgw
				fi

				# Restore exactly what was saved, except vpnc syntax is slightly wrong
				route add `sed -e 's/via/gw/;' /var/run/vpnc/defaultroute`
			fi
		fi

		# Clean up resolv.conf
		resolvconf -d
	fi
done

We’re almost there. Cut and paste the following code into /etc/init.d/autostart-vpn; this is the startup script that creates the iptables rules and starts the last script at boot time. Make sure you edit the script to list the correct networks for your VPN, and check that the locations (hardcoded, unfortunately) for inserting vpn_trigger in the FORWARD and OUTPUT rulesets makes sense:

#!/bin/sh /etc/rc.common
#
# From http://www.kaufmanfamily.net/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt
# DHK 4/17/2010
#
# Start after dnsmasq
START=80

VPN_NETWORKS="10.0.0.0/8 192.152.0.0/16"
EXT_IF="eth0.1"

check_firewall_rules() {
	trigger=`iptables -L vpn_trigger 2>/dev/null`

	if [ "X$trigger" == "X" ]; then
		# Fill in vpn_trigger ruleset
		iptables -N vpn_trigger

		for net in $VPN_NETWORKS; do
			iptables -A vpn_trigger -o $EXT_IF --dest "$net" -j ULOG
		done

		# Hook vpn_trigger into OUTPUT and FORWARD rules
		# Ought to do something smarter than hardcoding the position
		iptables -I OUTPUT  4 -j vpn_trigger
		iptables -I FORWARD 4 -j vpn_trigger
	fi
}

start() {
	check_firewall_rules

	/usr/bin/autostart-vpnc.sh &
}

stop() {
	if [ -f /var/run/autostart-vpnc.pid ]; then
		kill `cat /var/run/autostart-vpnc.pid`
	fi
}

One detail I skipped last time is that vpnc, as packaged for OpenWRT Kamikaze, will stomp on your resolv.conf file. Its default configuration just doesn’t work on OpenWRT. (The issue is that OpenWRT puts the WAN resolv.conf details in a non-standard place.) There’s an easy fix for this, though. Cut and paste the following code into /sbin/resolvconf. vpnc will find resolvconf and use it to manage /etc/resolv.conf correctly.

#!/bin/sh
#
# Simple resolvconf manager to integrate vpnc better with WRT
#
# Update /tmp/resolv.conf.auto, NOT /etc/resolv.conf. This affects the
# DNS resolver operation, which is actually the right thing.
#
# Usage:
#
#   resolvconf -a [if] < new-resolvconf
#
#   resolvconf -d [if
#
# We ignore the [if] argument.
#
# From http://www.kaufmanfamily.net/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt
# DHK 4/13/2010

BACKUP=/tmp/resolv.conf.bak
RESOLV=/tmp/resolv.conf.auto

if [ $1 == "-a" ]; then
	# Change resolv.conf

	if [ ! -e $BACKUP ]; then
		cp $RESOLV $BACKUP
	fi

	cat > $RESOLV
fi

if [ $1 == "-d" ]; then
	# Restore original resolv.conf

	if [ -e $BACKUP ]; then
		mv $BACKUP $RESOLV
	fi
fi

Now is a good time to make sure you’ve installed your VPN configuration into /etc/vpnc/default.conf. It’s a good idea to test out your vpnc config on another machine before running it on OpenWRT.

OK, let’s enable the services we need. You can do this from the OpenWRT web interface, or the command line:

/etc/init.d/ulogd enable
/etc/init.d/autostart-vpnc enable


Reboot your OpenWRT to get all the services set up. You’ll want to watch the system message log, so in one ssh connection run the log reader:

logread -f


and in another ssh connection start pinging a host in the VPN:

ping somehost.example.org


You should see a message in the system log, and after a short delay you’ll start getting ping responses. Make sure to test the auto-connect from a host plugged in to your OpenWRT’s LAN port as well as from the shell: if auto-connect works directly from the OpenWRT shell, but not from the LAN, then your iptables OUTPUT rule is correct but your FORWARD rule isn’t. (If the problem is reversed, then the rules are reversed.)

If auto-connection doesn’t work, you can check the log at /tmp/autoconnect-vpnc.log and then debug the process step-by-step:

1. First, check that your vpnc configuration works:
   vpnc
2. Then, check that the vpn_trigger iptables rule is being called by looking at the packet counts:
   iptables -L vpn_trigger -v
3. If vpn_trigger is being called, make sure that ulogd is writing to the correct file:
   cat /var/log/ulogd.syslogemu
4. check that the autoconnect script is actually running with ps

The hardest thing to check is that you have your DNS setup correct. I usually do this by checking the vpn_trigger rules first, then use nslookup to query a behind-the-vpn host.

I started with OpenWRT (of course!) and vpnc. So far I’ve deployed this setup using OpenWRT Kamikaze, versions 8.09.1 and 8.09.2. I’ll describe how the process works first, and then show the details in my next post.

The first thing we need to do is intercept DNS queries for the secure network. (Most secure networks will have a private DNS server behind the firewall, with lots of information that’s not in the public version.) OpenWRT uses the dnsmasq name resolver, and happily dnsmasq provides for exactly this case. So, we configure dnsmasq to know that the servers for the VPN domain are on its private addresses, and not to use the public servers.

Some companies might have the name of the VPN gateway in the same domain as their private, through the VPN environment. This could be a problem: how do we find the IP address for the gateway, if we need the VPN to talk to the domain servers? The easy answer for now is to just hardcode it in /etc/hosts on the OpenWRT.

OK, so we dealt with DNS name resolution, but how do we get the IP packets to go through the VPN? Actually, once vpnc connects, it will set up routing on the OpenWRT for us. So the only tricky bit is starting up vpnc at just the right time.

One way to do this would be to start vpnc whenever the WRT boots. This works, pretty much, but might be considered hostile by the VPN administrators. Instead we want to start the vpn tunnel whenever a user tries to access a machine in the private environment. To do this, we need to capture IP packets being routed to private IP addresses. This sounds like a job for iptables!

iptables is part of the Linux kernel which lets you define rules for handling IP packets. It does all kinds of cool things – filtering, QOS, NAT – but all we need it to do is tell us when someone is trying to connect through the VPN, so that we can start up the VPN tunnel. To do this, I used the iptables “ULOG” target: ULOG writes a message to a userspace daemon called ulogd, which acts like a hub (kind of like syslogd) and routes the messages to other programs. I kept it simple and just wrote the message to a file.

To tie it all together, I wrote a script which monitors the ulog file. The script gets automatically started at boot time: if the VPN isn’t up yet, it just monitors the ulog file. When a packet trace appears in the ulog file, we know it’s time to start the VPN up. Once the VPN is connected, the script hangs out, waiting for it to get shut down — either manually or by an idle timer. If the VPN gets shut down, then the script goes back to watching the ulog file.

OK, so we have DNS requests going to the private servers, and IP traffic causes the VPN to autoconnect. We’re done, right? Well, almost. It turns out that sometimes vpnc shuts down messily. It can leave the OpenWRT without a default route, or it can leave the resolv.conf file pointing to behind-the-tunnel servers. Either one of these problems is enough to prevent reconnecting the VPN! So I added a cleanup step to my script, which makes sure that vpnc has cleaned up after itself.

Add some logging and a simple web interface, and we’re all set. Details in my next post.

I was hoping you might have a solution to the problem of keeping /etc/config/system and /[flash|mnt]/config/system in sync.

and mentions another howto that does a bind mount of /etc between the flash and USB filesystems, so they stay in sync.

There’s an obvious problem with a bind mount of /etc, which is that the contents of /etc/config depend on the software in the rest of the filesystem. Let’s say you’re booted to the USB root filesystem. If you install a new package, or a new version of a current package, then you might inadvertently create a config file that’s incompatible with the software on the flash root filesystem. Most likely you won’t discover the incompatibility until it causes a significant problem. (Imagine if the webif or ssh doesn’t come up when you do an emergency boot off the flash root filesystem!)

My perspective is that having a completely separate root filesystem in flash is a feature, not a bug. When I deliver OpenWRT routers to remote locations, I configure the flash filesystem with the minimum requirements for remote maintenance: generally, this is the firewall, dynamic dns, and ssh with a key. Any added-value software goes on the USB root filesystem – generally this software is bigger or has more complex configuration.

If something goes wrong in the remote location, especially if somebody misconfigures OpenWRT, then recovery is easy: pull out the USB drive and reboot. (If the USB drive dies, simply rebooting is enough.) There’s a separate, known good configuration which will be sufficient for me to have remote access.

In a past life I helped design embedded network devices that got delivered to remote (unstaffed) locations. We used dual flash partitions and a custom boot ROM, to ensure that the devices would always be able to boot. Even a cosmic ray flipping the wrong bit wouldn’t brick the device: it would simply boot from the alternate partition. Similarly, software upgrades that affected the flash image would only be written to one partition, so you could fallback by booting the alternate.

My strategy for OpenWRT borrows from this prior experience, and also from the hidden “recovery” partition on many Windows computers, where there’s a stripped-down partition to allow restoring the original software in case of disaster.

Once again, I’ll show the configuration from /etc/config files. The first thing we need to do is define a network for the new LAN (in fact, I renamed the old LAN as well). The type is “bridge” so we can bridge it with the wireless LAN, as we noted last time. The interface is eth0.2, which is the new VLAN. This looks something like:

config 'interface' 'homelan'
option 'type' 'bridge'
option 'ifname' 'eth0.2'


Finally I wrote some iptables rules to prevent forwarding between the two LANs, and to prevent access to the router itself.
Then we need to add a section to the dhcp configuration. In this case we don’t want to run DHCP on this interface, so I set “ignore” to 1.

config 'dhcp'
option 'interface' 'homelan'
option 'ignore' '1'


Finally, and this is key, we need to add some sections to the firewall config file. First we need to define a “zone”, which is an OpenWRT concept. This (typical) zone allows packets to be transmitted or received on the homelan interface, but not to be forwarded between interfaces:

config 'zone'
option 'name' 'homelan'
option 'input' 'ACCEPT'
option 'output' 'ACCEPT'
option 'forward' 'REJECT'


Then we configure forwarding from the homelan into the WAN:

config 'forwarding'
option 'src' 'homelan'
option 'dest' 'wan'
option 'mtu_fix' '1'


The classic case of this usage is embedding the Linux kernel in the product. Linux is mature, actively-developed, and very modular – these are all attractive attributes. It’s also free, as in royalty-free, and the source code is similarly freely-available. The competition – embeddable kernels, often with a real-time flavor – is also mature, several options are actively-developed, but you pay for using the code, and presumably receive better support in your development. (The technical fit will depend on your application, I won’t address that here.)

Other classic examples include using gcc in your product, or building a web-based service around the Apache web server, or even using common tools such as Perl and PHP. Each one of these software packages is mature and actively-developed, and has competitive commercial products (depending on your application) that are also mature and actively-developed, but require payment.

One company I helped start made the decision (free or not free) several times during our lifetime, and changed the direction we went. Initially, we licensed a commercial embedded real-time operating system, bought a commercial suite of compilers, and used them to develop the first products. Later, in our 3rd-generation products, we switched to a Linux base. (We revised the physical designs at the same time, moving to a more off-the-shelf approach.) Our server application team made different decisions, building in more open source software from the beginning. All of these decisions had an impact on the business years later, and some of them led to last-minute rewriting of non-trivial parts of the product.

The problems we faced – and bigger problems that have been faced by much larger companies – evolved from that word “free”. When I described Linux and other open source projects as “free”, that was sloppy thinking, and in the case of this company it led to some sloppy management practices. (I was part of these practices, I share the responsibility.)

The Linux kernel is copyrighted, and that copyright is released under a license. In this way it is no different from the commercial products I called “competitors”. gcc is also copyrighted, and so are all other open source projects. (If there’s no copyright, we call the software public domain, and the rules are different.)

You wouldn’t found a startup – or start a new project – by saying “I’m going to steal this software and use it to build our next-gen best-seller.” No, you would say “we need to license this software package, and that will cost us X dollars up front with a per-unit royalty of $Y” (or whatever the vendor’s terms are). But, because the industry often calls open source projects “free”, we as software managers often forget to account for the licenses that control them.

Open source software is licensed. The choice to accept those licenses, and abide by their terms, is a business decision that needs to be made by the business managers. Just as you wouldn’t make an individual engineer responsible for counting the units-shipped of a commercial component, and paying the vendor’s royalty, you shouldn’t leave open source licensing decisions to engineers either. These are business decisions that need to be made by technically-savvy business managers.

We picked the the 520gU because it has 1 WAN port, 4 LAN ports, and a USB port, and becuase it runs OpenWRT well. We set up the root filesystem on an external USB stick (see previous posts). Then we had to work out how to have two separate networks on the LAN side.

OpenWRT sets up networks by tying together ports into VLANs (see fuller discussion on the OpenWRT site). Each of these groups of ports becomes a separate sub-interface of the master ethernet interface. For example, the standard configuration on a 520gU has (as I said) 1 WAN port and 4 LAN ports. But all of those ports are connected to the same switch: the only difference between WAN and LAN is that they’re on different VLANs, and some labelling onthe outside of the box. The master ethernet interface is eth0; the standard OpenWRT LAN is eth0.0, and WAN is eth0.1.

All of this is set up on the OpenWRT Network / Interfaces configuration page, which manipulates the file /etc/config/network. I’ll show you the examples in /etc/config/network, partly because it’s easier to have text examples and partly because there are 2 admin UIs for OpernWRT (LUCI, which comes with OpenWRT, and X-WRT, a parallel project that I use). Here’s the default setup:

config 'switch' 'eth0'
        option 'vlan0' '1 2 3 4 5*'
        option 'vlan1' '0 5'

vlan0, as I said, is the standard LAN, and vlan1 is WAN. But wait, I said there were 5 ports (1 WAN and 4 LAN) but the ports here are numbered 0-5. What’s the 6th port? Well, it’s the internal switch connected to the CPU, and it’s included in every group of ports. If it weren’t then OpenWRT couldn’t see the packets.

Here’s the configuration with two different LANs:

config 'switch' 'eth0'
        option 'vlan0' '1 2 5*'
        option 'vlan1' '0 5'
        option 'vlan2' '3 4 5'

vlan1 is still the WAN port, but now vlan0 is one LAN network, and vlan2 is the other. Next time I’ll show how we did the firewall rules to complete the job. But before we tackle the firewall rules, I need to set up the WiFi.

WiFi is different, and isn’t on the 6-port ethernet switch. Instead, WiFi works with its own master interface, and sub-interfaces for each WiFi network that you’re either a client on, or an access point for. Then you can bridge the WiFi subinterface to a LAN subinterface, to create a network with both WiFi and LAN access types.

The standard OpenWRT configuration bridges the LAN to wl0, the default and first WiFi subinterface. We were able to use this same configuration to bridge wl0 to the first LAN, eth0.0.

On a standard OpenWRT system, /var is a link to /tmp. This simplifies setup, but it means that /var gets wiped out on each reboot, because /tmp is a tmpfs (in-memory). Why do I care? Well, when you reboot you lose:

1. The package lists downloaded by opkg update
2. DHCP leases that OpenWRT handed out
3. Web pages that polipo, a caching proxy, has already loaded
4. System-specific Bluetooth configuration, especially paired devices

And I care about all of these. Also, the tmpfs is kind of small, which makes web caching harder.

Unfortunately, the assumption that /var is /tmp has leaked into a number of places, so you’ll need to fix those. Start with the USB Storage howto to setup your external filesystem, and with my pivotroot scripts as well. Make these changes when you’re booted off internal flash – don’t make them to your live filesystem.

I’ll assume your external USB stick is mounted on /mnt.

1. Undo the link. cd /mnt; rm var; mkdir -p var/etc
2. Fix the bootup scripts. Exceprts are below, but you need to fix references in etc/init.d/syslog and etc/init.d/boot on your USB stick

diffs for etc/init.d/boot:

--- /etc/init.d/boot    Sun May 10 21:09:45 2009
+++ boot        Sat Jan  1 00:08:59 2000
@@ -38,10 +38,14 @@
        config_load system
        config_foreach system_config system

-       mkdir -p /var/run
-       mkdir -p /var/log
-       mkdir -p /var/lock
-       mkdir -p /var/state
+       mkdir -p /tmp/run
+       [ ! -f /var/run ]   && ln -s /tmp/run   /var
+       mkdir -p /tmp/log
+       [ ! -f /var/log ]   && ln -s /tmp/log   /var
+       mkdir -p /tmp/lock
+       [ ! -f /var/lock ]  && ln -s /tmp/lock  /var
+       mkdir -p /tmp/state
+       [ ! -f /var/state ] && ln -s /tmp/state /var
        mkdir -p /tmp/.uci
        chmod 0700 /tmp/.uci
        touch /var/log/wtmp

diffs for etc/init.d/syslog:

--- /etc/init.d/syslog  Fri Jun 12 08:16:26 2009
+++ syslog      Sat Jan  1 00:09:22 2000
@@ -11,7 +11,7 @@
        local cfg="$1"
        local type file size ipaddr port IPCALC_CMD SYSLOG_CMD
        local DEFAULT_type="circular"
-       local DEFAULT_file="/var/log/messages"
+       local DEFAULT_file="/tmp/log/messages"
        local DEFAULT_size=16
        local DEFAULT_ipaddr=""
        local DEFAULT_port=514