Decentralized administration concepts for wireless community mesh networks

Thomas Huehn‡

‡Deutsche Telekom Laboratories, TU , Berlin, {[email protected]}

Abstract—The lack of widely available broadband internet mesh network has two main clouds per village with a high access available in all parts of Germany was the main motivation density of nodes running all on the same channel, channel to build community mesh networks to share ADSL lines. As many 1 (2412 GHz) in 802.11g-only mode. All mesh nodes are are unable to easily obtain an ADSL line, we built a covering our two home villages. Singe we began, we equipped with an omni-directional antenna mounted to be have included 60 households running their own 802.11 wireless outside of the roof. A singe ADSL line, serving 6000 kBit/sec routers based on commodity hardware on rooftops within the downstream and 520 kBit/sec upstream, is the only Internet unlicensed 2,4 GHz frequency band. But how would someone gateway we are currently using and sharing between us. The administrate such a network consisting of 60 different ”micro” Fig. 1 represents the topology snapshot from 28th of April 09 providers without having a central administration instance? This paper describes the mechanisms that make our decentralized based on OLSR [2] routing table calculations. administration concept a trust-based, efficient, and scalable so- lution for community mesh networks. We then describe the main concepts of how to deploy new OpenWRT based firmware-images in a decentralized manner. We then detail the most challenging aspect of the project, granting access for mobile devices among the entire mesh distributed among the node owners. Moreover we argue that conventional administration concepts fail when running such a mesh network and provide new approaches to run networks where every participant has root privileges.

I. INTRODUCTION Fig. 1. Topology of the wireless mesh in Sundhausen/Urleben. Starting in 2003 many community driven mesh networks called Freifunk communities have tried to bridge the gap in Starting from the gateway node, we build a 5 GHz wire- Germany’s ADSL accessibility by deploying 802.11 wireless less backbone between six Freifunk mesh nodes, connected routers on rooftops. The kind of Freifunk based networks vary via separated point-to-point links. The backbone nodes are from totally unplanned city meshes like in Berlin and Leipzig equipped with Atheros miniPCI cards operated in 802.11a with up to 800 nodes to structured meshes such as in our turbo mode. Marked by yellow lines, Fig. 1 also depicts the village Sundhausen with 60 active nodes. The development of backbone links, connected as a layer 2 bridge between the the Freifunk firmware is realized in a decentralized manner. red dotted mesh nodes. All of the six Freifunk routers are The first part of this paper describes our mesh network located in a full switch broadcast domain, where their OLSR routing in Sundhausen and Urleben (Germany). Questions regarding daemon assumes to have a direct link to each other backbone the firmware distribution process and how to enable network router. With this setup we were able to reduce the number access for mobile devices in a decentralized manner are of maximal hops within the shared 2,4GHz band from 4.5 to covered within the second part. 2.5 on average. The minimal achievable net bandwidth from a II. COMMUNITY MESH IN SUNDHAUSEN/URLEBEN mesh node to the nearest backbone node is at least 4 MBit/sec with an average delay of 3.6 ms. Table I summarizes the main In parallel to the growing Freifunk [1] communities in Ger- parameters of our deployment and our hard- and software man cities, we started simultaneously building a wireless mesh setup. to cover our village Sundhausen. Since we began, we have included 38 households within Sundhausen and extended our B. Security mesh to include our neighbor village Urleben, with currently 22 nodes. We do not use any encryption on the wireless interface at all. The intra mesh access is free for all, however the internet A. Architecture & Topology access is restricted to nodes which are registered on a central Our wireless mesh network is based on a 2-tier archi- web page. This represents the basis of the so-called white list tecture. The mesh consists of consumer hardware with an of allowed nodes. This concept is used to exclude misbehaving OpenWRT [3] firmware as open-source operating system. The nodes or users. TABLE I CHARACTERIZATION OF THE WIRELESS MESH IN SUNDHAUSEN/URLEBEN on what the user selected, the firmware is downloaded and flashed in an unattended fashion or the user is otherwise Evaluation Paramter Freifunk Sundhausen/Urleben informed about a possible update on his router’s status page. Deployment Covered area 12 km2 Max. diameter 4.5km Our experience shows that the sum of users who have chosen Population Sundhausen 371 (Dec. 2007) ”brave” and ”normal” mode has a stake of around 45% each. Population Urleben 449 (Dez. 2007) Less than 10% go with the most conservative update strategy. Max. concurrent users 112 Software Operating system OpenWRT linux With this concept we were and we are still able to have a fully Kernel version Kernel 2.4.30 unattended update automatism to distribute at least all stable Routing algorithm OLSR version 0.5.4 rc4 firmware releases for more then 90% of all mesh nodes in our Hardware Meshrouter platform 48x Buffalo WHR-HP54G network. The user is in no case directly forced to be part of 12x Linksys WRT-54G Meshrouter antennas Omni-directional (3-9 dBm) that automatic update process. Backbone platform Asus W-500gP Backbone antennas Directional (14-24 dBm) B. Distributed Access Control for mobile devices Node owners may use their mobile devices to access the mesh network without having the OLSR daemon. This access C. Economics is based on the MAC address of the device, where each Within our mesh, the single-node owner can be seen as a node owner can specify his own web-based whitelist of MAC kind of a mini provider who invested about 100 Euros in a set addresses on the mesh router. But how could someone realize of common hardware components and who pays the energy a mesh-wide access control scheme with such local white- costs to operate his node. The range of the mesh network listed information? Our approach combines a local storage increases with new participants and their packet forwarding of access restrictions with a global distribution to provide ability. Besides other Freifunk networks, where voluntary the elements of evidence for deciding on possible mesh-wide users share their Internet connection with the community, we access. Therefore each router announces its whitelist of MAC founded a registered co-operative called ”Evernet e.G.” The addresses via the OLSR service plug-in all over the mesh. task of this registered co-operative is to rent the ADSL Internet While the OLSR daemon handles the service distribution, line so that no single user is responsible for the activities on every node matches the number of equal MAC addresses the network. The use of the mesh network and, therefore, received from different nodes. If a node has received a MAC the use of the Internet connectivity are free of charge. Our address announcement generated by more than 3 different mesh network is more or less a voluntary network without any sources, it will add this MAC address to its own access list. contract between the users, but with some more centralized Respectively it will adjust its iptable rules in the manner approaches compared to other Freifunk meshes e.g. the one in to grant wireless access for this specific MAC, as long as Berlin [4]. the announcement rule is valid. This leads to considerable advantages: the user is able to obtain mesh wide client access III. CONCEPTS OF DECENTRALIZED ADMINISTRATION by finding at least 3 different node owners, trusting in him A. Automated Firmware Deployment and adding his MAC address to their own whitelist. From Conventional administration concepts to deploy new an administration standpoint, the task to control the wireless firmware images are not applicable to our mesh and the access is distributed among the group of users. Such a trust distributed firmware development process. Each single node based mechanism ensures a lower bounded entry threshold. owner is given root privileges with the power to decide We do not claim this concept to be secure at this point of what to install and adjust on his node via ssh or https. In development, but it is utilized by our users and could be seen summary the firmware development process over the last 3 as a first step towards a distributed access control dynamically years created new firmware beta-releases on a bi-weekly basis handled within the mesh network. and a stable major release every 6 month. To prevent avoid the IV. CONCLUSION development of an entirely inhomogeneous firmware distribu- Within these two pages we presented a condensed descrip- tion, we introduced a staged update profile. The web based tion of our real wireless mesh installation in the villages Sund- firmware administration allows the user to choose between hausen and Urleben in Germany. Furthermore, two concepts 3 different update strategies. Namely ”brave” - every beta and practical implementations are described which enable version is flashed, ”normal” - only firmware images marked as automated firmware updates and distributed access control in stable are considered and ”paranoid” - the automatic update is a community-driven mesh network. deactivated, are selectable. Each strategy represents the trade- off between running the latest, most featured firmware while REFERENCES risking an unstable system and deactivating the automatic up- [1] Freifunk project homepage, http://start.freifunk.net/node/1. date, possibly leading to incompatibilities with the remainder [2] Olsr project homepage, http://www.olsr.org. [3] Openwrt project homepage, http://www.openwrt.org. of the mesh. We leave this decision to be made by each node [4] R. K. A. Pescape and T. Huehn. Challenges in 2nd generation wireless owner. Our update scheme checks on a nightly basis if there is mesh networks. EURASIP Journal on Wireless Communications and a newer firmware version in our central repository. Depending Networking, JWCN/274790, August 2008.