[Berlin-wireless] Release Notes FFF 1.6.38
Do Mai 6 10:44:36 CEST 2010
uebernaechstes WE ist das Wireless-Community-Weekend. Puenktlich dazu wird es
wohl die OLRD-Stable-0.6.0 geben (Henning?) und zeitgleich dazu eine neue
Version der alten Firmware. Ich hab' alles erledigt - QS fehlt noch. Darum
derzeit nur auf http://download.berlin.freifunk.net/sven-ola/testing/
Ich hab' heute einen Draft fuer die RelNotes fertiggestellt - FYI im
Release Notes for Freifunk Firmware 1.6.38
With the advent of recent hardware that is not supported by the old
Whiterussion toolchain, I plan to shut down development for the BCM4710-based
Freifunk Firmware. Mainly because it's much work and I don't want to compete
with the OpenWrt/LuCI firmware which should replace the Freifunk Firmware in
the future. However, I was requested to support existing router deployments
from some fellows. For this reason, the current 1.6.38 exist.
In short: if you have non-WRT54GL hardware, want to use recent 2.6.x-kernel
based wireless drivers, play with enhanced IPv6 features or simply want more
recent software please use the OpenWrt/LuCI firmware instead. Go to
The 1.6.38 firmware (besides fixes) introduces the current olsr.org routing
daemon (stable version 0.6.0), adds OpenVPN with GUI, limits P2P traffic in a
uniqe approach and comes with IPv6 support. Updating to this version should
be straightforward if you already use an older version of this firmware.
However, you should read the following notes because the new features may
interfere with you current installation.
The firmware uses one additional 64k flash block compared to the older
version. If your device has only 8Mb RAM, please use the GUI to update the
firmware which requires you to restart in read-only mode in order to update.
To update via the command line, please follow this procedure:
- Do 'killall crond' to prevent cron.minutely from restarting olsrd
(You have 5 minutes now to complete, otherwise kernel-crondog restarts!)
- Do 'killall olsrd' to free up RAM (8 Mb RAM devices only!)
- Transfer the "_trx/openwrt-freifunk-1.6.38-xx.trx" file to /tmp
- Issue 'echo > /dev/misc/crondog' to re-trigger the crondog
- Issue 'firmware-burn /tmp/openwrt*.trx'
Warning: updating the firmware leaves your NVRAM configuration intact.
However, locally changed files are lost. Please do a 'find /rom/jffs/ -type
f' first and check for files you may have created/changed manually, e.g.
config files in /rom/jffs/etc/
To assist upcoming IPv6 mesh networking, the Firmware offers a 'freifunk-ipv6'
package. The ToDo list on the Admin page suggests installing additional
software. On devices 16Mb RAM or more (e.g. WRT54Gl)
the 'freifunk-recommended' package is suggested which in turn
includes 'freifunk-ipv6'. On devices with only 8Mb RAM/2Mb flash,
the 'freifunk-ipv6' is suggested. This package can be installed on 2Mb flash,
provided that you do not install any other software.
The IPv6 package basically starts a second olsrd which sends/receives on the
same interfaces as it's IPv4 counterpart. Examine
the /var/etc/olsrd-ipv6.conf config file for details. You do not need any
configuration, because the IPv6 address configuration is done automatically.
No IPv6 firewalling, no NAT/NIIT/SIIT and such is supported. The Freifunk
Firmware router simply participates with the IPv6 routing domain - nothing
more. Note, that the incompatible "etx_ffeth" LQ algorithm is used for IPv6
which prefers Ethernet links automatically. IPv4 LQ algo is unchanged to
Hint: the 'ip4' script abbreviates 'ip -f inet $*' while the 'ip6' script
abbreviates 'ip -f inet6 $*'. To check IP address config to 'ip4 a' or 'ip6
a'. Similar, the 'neigh' and 'neigh6' scripts exist as well as 'ping'
and 'ping6'. Also 'nc6' offers a IPv6-compatible netcat which is also
required to query olsrd-txtinfo with http://[::1]:2006 in the neigh6 script.
OLSR Smart Gateway
The stable olsr.org 0.6.0 version maintains compatiblity with older versions.
However, there is a feature which deserves your attention: Smart Gateways. We
all know, that switching the gateway disconnects e.g. an ongoing download
because the new gateway does not know how to continue the TCP connection due
to the NAT typically used to translate e..g the single public DSL IP address.
To overcome this, olsr-0.6.0 and the Freifunk Firmware offer the SmartGW
features, which you may enable on the Admin/OLSR page for your router. A
smartgw server then configures an ipip tunnel endpoint (tunl0 device) which
can be addressed by a smartgw client. The selected ipip tunnel endpoint does
not change, even if the standard-default-route chain selects another gateway
due to wireless conditions. Note, that this feature is experimental and that
you may not reach you preferred gateway if this does not offer the smartgw
To realize this, the default route added by olsrd is moved to a separate
routing table. This is also used, if the smartgw feature is switched off! To
query the current defaut gateway config, simply use the Status page or issue
the 'def' command. Also a 'gw' command lists the smartgw servers available in
your mesh. Note, that 'gw' only works if you switched on this feature.
Gateway owner should be aware, that if you offer a smartgw anyone in the mesh
can select his gateway manually. This may include the nerve wrecking
p2p-bloke at the other end of the city that was filtered out on another
gateway in the past.
Note, that currently no olsr-plugin exist to manually select the
Filesharing Filter (aka 'Zapp')
We have problems with laywers due to some mesh users which cannot resist to
use the open Internet access for their file sharing needs. Because the
L7filter in the gateway-package only filters out un-encrypted P2P traffic,
there's a new approach to limit this based on the connection tracking
required to NAT/MASQUERADE internal IP addresses on the Internet gateway.
Install the 'freifunk-zapp-de' or 'freifunk-zapp-en' package to activate the
filter. The /etc/init.d/S92zapp script will run every minute and checks the
conntrack table for extensive connections. If a mesh user opens too much
connections to different external IPs, his Internet access is blocked and his
HTTP is hijacked to a spash page. The user may re-enable TCP (e.g. to browse)
on this page, but UDP besides the also-hijacked DNS is blocked until a
timeout or manually unblock from the gateway's admin.
It looks like, that this script does a good job. E.g. in the first month after
deploying I got ~20 alarms, mostly from Skype users complaining to be
blocked. For this reason, the package contains a Skype configuration and a
socks proxy to allow this service after some tweaks (see Skype Info page on
the router after installation). After running this filter for some time now,
only a single alarm reached me last month. Looks that it is effective.
Please: this is still experimental, so be kindly if you are blocked or if you
(as a gateway owner) got an alarm. This may be simply caused by a virus
triggering extensive SMTP connections.
Note, that the /etc/init.d/S92zapp file should run on OpenWrt/Kamikaze or
OpenWrt/Backfire as well as on any other Linux system with connection
Manually setting up OpenVPN overstrain much people because of too much config
options and the complex X.509 key/certificate stuff.
The 'freifunk-openvpn-de/-en' package tries to relieve this by offering a GUI
to configure OpenVPN servers or clients. Because of the required flash space,
there's a separate 'freifunk-openvpn-easyrsa-de/-en' package to generate
X.509 keys/certificates. Besides technical details, here's an example what
can be done with that packages:
* In my company, I have a spare old DSL line (reachable on styx.commando.de).
* I attached a WRT54Gv3 to that DSL line and added OpenVPN configs.
* One OpenVPN connects to the Berlin mesh (Point-to-Point mode)
* A second OpenVPN allows me to dial in to my company. To add company access,
e.g. on a Windows PC, I simply click "add client key" on the OpenVPN-RSA
and download the config.tar to that PC. Then I start OpenVPN-GUI and click
select "connect/mycompany". This is a tap-connection because of the Windows-
* A third OpenVPN offers the same company access on a TCP port
* A forth OpenVPN redirects any Mesh-Internet-Traffic to a VPS server in the
USA. This calms down misgivings of my boss, that others may mis-use that
company DSL lines for filesharing and such.
Up to 4 openvpn instances can be managed and there's also a non-ssl version
of the package which does not require openssl which is rather large.
Benchmarks show, that connection tracking costs routing performance. Even if
you do not add iptables rules to activate this feature. For that reason, the
conntrack kernel module is loaded on demand now. If you switch off
NAT/Firewall (e.g. because the Freifunk router does not serve any
LAN-connected clients) the conntrack module is not loaded. Also, the kernel
module contains an extension ("notrack") to limit NAT/Conntracking to
non-mesh IP addresses. If you need to debug this, use 'nvram set
Firmware with Pre-Installed Softs
While you can flash the standard (small) firmware image and add e.g.
the 'freifunk-recommended-xx', 'freifunk-openvpn-xx'
and 'freifunk-openvpn-easyrsa-xx' packages, there is not much flash space
left on a 4Mb flash device after this. For example: no space for
the 'freifunk-gateway-xx' package which offers the gateway accounting.
Because squashfs compresses much better than JFFS2, there is now
an '*-full.trx' file which includes lots of pre-installed packages:
- freifunk-recommended (stats, tcpdump, horst, dnsmasq, https, viz, map, ipv6)
- freifunk-zapp (conntrack-based P2P filter, socks proxy)
- freifunk-portfw (incoming port forwarding)
- freifunk-dyndns (add DNS name to dynamic dial-up IP addess)
- freifunk-pppoecd (required to control DSL modesm)
- freifunk-dhcpsplash (nerve-wreck-page for WIFI-DHCP users)
- freifunk-openvpn (VPN tunnels, including OpenSSL)
- freifunk-openvpn-easyrsa (Manage X.509 keys for OpenVPN)
This leaves approx. 1Mb in JFFS which is enough to install e.g.
the 'freifunk-gateway-xx' package on top. Also - there's now
a '*-madwifi.trx' which comes with a pre-installed MadWifi driver, e.g. for
updating an Asus-WL500g-deluxe with an a/b/g minipci-card over-the-air.
// Sven-Ola, May 2010
Mehr Informationen über die Mailingliste Berlin