Open Source does matter, and it is inherently more trustable than closed source because you can verify it yourself, and so can lots and lots of other people. The current distribution method for the source is a large .tar.gz file, with this series of posts I am trying to make the critical bits of the source code more open and accessible to more people, this makes it more trustable, and potentially more secure (if issues are found and fixed).

# Firewall script, specific for OpenWrt: permits traffic from chilli clients to Internet restricts inter-interfaces traffic
. /etc/functions.sh
. /tmp/network-config

config_load fon

WL=”$wifi_ifname”
WAN=”$wan_ifname”
LAN=”$lan_ifname”

iptables -N NET_ACCESS 2>&- >&-
iptables -F NET_ACCESS

# WAN_HOOK will contain rules to restrict traffic to the wan network
iptables -N WAN_HOOK 2>&- >&-

# ChilliSpot
iptables -A NET_ACCESS -p tcp –dport 3990 -j ACCEPT

# DNS is always allowed from the tunnel
iptables -A NET_ACCESS -p udp –dport 53 -j ACCEPT
iptables -A NET_ACCESS -p tcp –dport 53 -j ACCEPT

# Access control for the hotspot
config_get wan access hotspot_wan
enabled “$wan” 0 || iptables -A NET_ACCESS -j WAN_HOOK

config_get lan access hotspot_lan
if enabled “$lan” 0; then
iptables -t nat -A POSTROUTING -o “$LAN” -j MASQUERADE
else
iptables -A NET_ACCESS -o “$lan_ifname” -j DROP
fi

config_get wan access lan_wan
enabled “$wan” 1 || iptables -I FORWARD 1 -i “$LAN” -o “$WAN” -j WAN_HOOK

# allow regular wan traffic
[ -z "$WAN" ] || {
iptables -A NET_ACCESS -o “$WAN” -j ACCEPT
iptables -A NET_ACCESS -i “$WAN” -j ACCEPT
}

iptables -A NET_ACCESS -o “$LAN” -j ACCEPT
iptables -A NET_ACCESS -i “$LAN” -j ACCEPT

# drop everything that we haven’t explicitly allowed
iptables -A NET_ACCESS -j DROP

# — INPUT PART –
iptables -N INPUT_CFG 2>&- >&-
iptables -F INPUT_CFG 2>&- >&-
iptables -I INPUT 1 -i tun0 -p tcp –dport 80 -j DROP
iptables -I INPUT 2 -i “$LAN” -j INPUT_CFG
iptables -I INPUT 3 -i tun0 -j NET_ACCESS

# — FORWARD PART –
iptables -I forwarding_rule 1 -i “$LAN” -j INPUT_CFG
iptables -I forwarding_rule 2 -o “$LAN” -j INPUT_CFG
iptables -I forwarding_rule 3 -i tun0 -j NET_ACCESS
iptables -I forwarding_rule 4 -o tun0 -j NET_ACCESS

# Drop all unmanaged traffic from the public interface
iptables -t nat -A PREROUTING -i “$WL” -j DROP

ACTION=ifup INTERFACE=wan sh /etc/hotplug.d/iface/20-firewall

I wanted to see what exactly is in this .fon file so I downloaded the source code. You can get this from here. This is an 88.7MB file called fonera.tar.bz2. (The .tar.bz2 extension means it is a compressed file for Linux known as a tarball, a bit like a .zip file). I uncompressed this and had a look inside.

First thing I noticed is the file dates are mostly October 4th 2006, I don’t think this is the source for version 7.1.1. I couldn’t find any indication of what version it actually is, which is a bit of a shame. I used the “find” command to produce this List of files in fonera.tar.bz2 so you can see the structure of it without downloading the whole thing yourself.

One part I was a bit surprised at was finding ./binary-only-modules/ar531x-wdt.o this is a binary driver for the Atheros AR531x chip which provides the wireless functionaility. The initial release of the source code for the Fonera was delayed for a while because Fon were working on GPL compliance with Atheros I guess they were hoping to get the source code to this module released, but failed in the end. Binary kernel modules are fairly common and I think are within the letter of the GPL if not the full spirit of the GPL.

Most of the code is fairly standard stuff taken from the OpenWrt project, I am only really interested in the bits that Fon have customised, so I started by looking for all the filenames containing “fon” here they are:

./package/iptables/files/firewall.fon
./package/base-files/default/etc/config/fon
./package/base-files/default/etc/resolv.conf.fon
./package/base-files/default/etc/fon_version
./package/base-files/default/etc/fon_revision
./package/base-files/default/etc/fon_device
./package/foncheckrsa
./package/foncheckrsa/files
./package/foncheckrsa/files/etc
./package/foncheckrsa/files/etc/public_fon_rsa_key.der
./package/foncheckrsa/src
./package/foncheckrsa/src/rmd160.h
./package/foncheckrsa/src/bigint.h
./package/foncheckrsa/src/rmd160.c
./package/foncheckrsa/src/bigint_impl.h
./package/foncheckrsa/src/foncheckrsa.c
./package/foncheckrsa/src/bigint.c
./package/foncheckrsa/Makefile
./package/chillispot/files/chillispot-fon.init
./package/chillispot/patches/100-fon.patch

The ./package/foncheckrsa/* files are a small package for checking digital signatures. The comment in foncheckrsa.c explains it rather well:

/*
* foncheckrsa.c
*
* Verifies a file against an RSA crypted RIPMD160 signature
*
* 20060728 Pablo Martín Medrano
*
* The signature is created using openssl as follows:
* openssl dgst -rmd160 -sign signature
*
* This creates a signature of the same length of the key (512 bytes),
* that is made _decrypting_ the RMD160 checksum of the file, after
* padding it to expand it to 512 bytes using the padding mechanism
* described as PKCS#1 v1.5 in RFC 271.., using the private key.
*
* This program performs the check, by _crypting_ the signature using
* the RSA public key, getting rid of the padding bytes, and comparing
* the resulting RMD160 checksum with the one it calculates by itself.
*
* RIPEMD-160 software written by Antoon Bosselaers,
* available at http://www.esat.kuleuven.be/~cosicart/ps/AB-9601/.
*
* The bignumber implementation have been liberally taken from the code
* of axSSL
*
* This is just a small wrapper to make it work alltogether in an
* embedded device
*
* The same verification can be performed with openssl by issuing:
* openssl dgst -rmd160 -verify \
* -signature
*
* But OpenSSL is too bulky to be included in a 4MB of flash router
*
* $Id: foncheckrsa.c 50 2006-07-31 13:57:43Z pablo.martin $
*
*/

I will carry on digging and blogging about interesting bits I find over the next days and weeks.

This blast from the past is now being brought up to date with the Skype Wifi phone with La Fonera. Now I can see that this is a cool thing to have in your home, a digital cordless phone that has the call costs and quality of Skype (which has a much greater frequency response than a regular phone or even a SIP phone), and of course having a Fon hotspot is great too. The bit I don’t get is the idea of roaming about with it in search of hotspots. I can completely understand WiFi roaming with a laptop, if you find a hotspot you can stop and use it, if you don’t, you just work locally. With a mobile phone however there are two big reasons that this isn’t good enough, firstly it’s only function (well apart from silly games and perhaps a camera) is to communicate with other people whenever and wherever you might be. Secondly a phone also takes incomming calls, and you can’t really synchronise your visits to a hotspot to coincide with an inbound call.

I might still get one as a home device, but I certainly wouldn’t get one for the purpose it seems to be aiming at. Fon is cool, VOIP is cool, but VOIP+Fon is not a mobile phone network.