Release Notes for Freifunk Firmware 1.7.0 ----------------------------------------- With the advent of recent hardware that is not supported by the old Whiterussian 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.7.0 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 http://luci.subsignal.org/ The 1.7.0 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. Update Procedure ---------------- 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/ IPv6 Support ------------ 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 maintain compatiblility. Hint: the 'ip4' script abbreviates 'ip -f inet $*' while the 'ip6' script abbreviates 'ip -f inet6 $*'. To check IP address config enter '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 featur, 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 feature. 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 your 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 smart-gateway. 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 e.g. BitTorrent. This is 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 then run every minute and check 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. To manually unblock, refer to the output of '/etc/init.d/S92zapp help'. It seems, that the Zapp 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 for users after some tweaks (see Skype Info page on the router after installation). After running the Zapp 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 also, that the /etc/init.d/S92zapp file also runs on OpenWrt/Kamikaze or OpenWrt/Backfire as well as on any other Linux system with connection tracking enabled. OpenVPN Support --------------- 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 page 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- Fileserver. * 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. Loadable Conntrack ------------------ 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 ff_debug=1;/etc/init.d/S45firewall restart'. 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. Note: if you do not offer an Internet gateway, you may want to disable the Zapp filter with the *-full.trx firmware variant. Go to Admin/Zapp and set the Threshold to zero. // Sven-Ola, May 2010