Download Airmesh The Flying Mesh Network

Airmesh
The Flying Mesh Network
Students
Andreas Hechenberger
Lennart Oldenburg
Max Rosin
Supervisor
Michael Döring Telecommunication Networks Group
TU Berlin
January 2016
1. Abstract
Our “Airmesh” project was part of the students project “Ingenium” at TU Berlin.
Ingenium’s goal is to provide a wireless network for communication during recovery
in areas that were struck by a disaster. They want to build stationary airships equipped
with routers which are connected via a mesh network and provide network access to
clients on the ground.
Our task was to evaluate the hardware and software requirements for a network infrastructure in such a situation. We researched different software and hardware technologies
to be able to decide which ones are suitable for Ingenium’s project. The major aspects
were bandwidth, power and range restrictions. Based on these decisions we also built
a prototype of the network with three routers to put our theoretical research to the
proof.
We found out that WiFi is a suitable technology for this kind of disaster recovery network
and that hardware in an acceptable price range is able to handle the meshing and client
connections without too much power consumption.
At the end of our project we verified our results with the Freifunk community and can
confirm that our proposed networking part of Ingenium’s project should be feasible to
realize.
1
Contents
1. Abstract
1
2. Ingenium - The Big Picture
3
3. Airmesh - Our Part of Ingenium’s Project
4
4. Project Requirements
4
5. Current Situation and Project Decisions
6
6. Routing
6.1. HWMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3. B.A.T.M.A.N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
7
8
7. Airmesh Solution
8
8. Theoretical limits
11
8.1. Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Practice
9.1. Our Development Setup
9.2. Router Configuration . .
9.3. Tests . . . . . . . . . . .
9.3.1. Range Test . . .
9.3.2. Bandwidth Tests
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
15
16
17
17
10.Conclusion
21
11.Future Work
22
Appendices
24
A. User Guide for Setting Up an Airmesh Network
A.1. Requirements . . . . . . . . . . . . . . . . .
A.2. Setting Up . . . . . . . . . . . . . . . . . . .
A.2.1. Defining Your Configuration File . .
A.2.2. Flashing the Storage Cards . . . . .
A.3. Starting Up . . . . . . . . . . . . . . . . . .
24
24
25
25
26
26
B. Source Code of the Airmesh Deployment Tool
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
2. Ingenium - The Big Picture
Our Airmesh project at the Telecommunication Networks Group (TKN) originated from
the collaboration of two independent TU Berlin projects.
The first one is called “Ingenium – Nachfragebasierte Entwicklungszusammenarbeit”1 , a
students project in the TU Berlin “tu project” track2 . The goals this group of students
set out to accomplish include a disaster recovery solution in terms of communication and
aiding management based on airships. In a catastrophe region, these stationary airships
are imagined to be deployed at heights between 60 - 75 meters. As payload they carry
among other equipment sensors, a battery pack and a router with two wireless cards.
The solution Ingenium envisions is a group of airships providing wireless connectivity
for a region suffering from a natural disaster. As the area covered by multiple airships is
thought to be one joint network instead of one isolated network per airship, some kind
of inter-connectivity is needed in order to connect all airships, a mesh network.
As this project is meant to be inter-disciplinary the part of router setup (provisioning),
network setup and deployment as well as testing this setup was out sourced to be build
by one students group in the TKN “Projekt Kommunikationstechnologien” or “Project:
Advanced Network Technologies”.
Figure 1: Ingenium’s vision of one of their
airships3 .
1
http://www.ingenium.de.com/
https://www.tu-berlin.de/?101577
3
https://static.wixstatic.com/media/66e6e0_6ee8047ebd194d33bc765988b3524845.
jpg/v1/fill/w_548,h_260,al_c,q_75,usm_0.50_1.20_0.00/66e6e0_
6ee8047ebd194d33bc765988b3524845.jpg
2
3
The “Projekt Kommunikationstechnologien”4 or “Project: Advanced Network Technologies”5 are bachelor’s respectively master’s projects offered at the Telecommunication
Networks Group (TKN) at TU Berlin. The main focus of these projects is to have
groups of students work on topics directly derived from current research efforts at the
TKN chair. This makes these both projects a perfect fit to develop such a mesh network
setup Ingenium envisions.
3. Airmesh - Our Part of Ingenium’s Project
We named our part of the project “Airmesh - The Flying Mesh Network”. The main
focus of our project was to find out how a disaster recovery network could look like and
what can be achieved with it. This provides the basis for Ingenium’s project and can be
used to define hard- and software choices suitable for the project. To achieve this goal
we divided the project in two main parts: a theoretical one and a practical one.
In the theoretical part we researched about existing technologies. We took a look at
different mesh routing protocols, power consumption limits and range limits for WiFi
networks. We used this as knowledge to make some decisions for the practical part.
In the practical part we built a prototype of the mesh network with three routers and
used it to evaluate our theoretical work on range and bandwidth limits. We also built a
tool to configure the routers fast and easy. This tool was not only useful for us during
the experiments but will also be useful for Ingenium because it provides such an easy
way to setup the routers for their real deployment scenarios.
4. Project Requirements
The setting of the intended field of operation of the mesh network is a region hit by
a natural disaster or a comparable situation. The primary use case is a breakdown of
exchanging information including communication infrastructure. Therefore commonly
used communication methods that rely on connectivity of a network won’t work, examples include centralized versions of instant messaging, mail, (micro-)blogging and social
networking services. Among all resulting problems for people suffering from such connectivity loss there are two that play an important role for our network requirements.
The first one being the possibility for inhabitants to quickly inform their family and
friends about their status regarding health, location etc. Secondly, these platforms
4
http://www.tkn.tu-berlin.de/menue/tknteaching/modules/outline/0432_l_358_pj/parameter/
de/
5
http://www.tkn.tu-berlin.de/menue/tknteaching/module/outline/l_358_pjkn_4sws/
parameter/en/
4
provided a mean to organize help on a local basis, one example being connecting people
with boats with people in need of a transport possibility. It has to be kept in mind that
all these self-organizing procedures worked before Internet connectivity was common and
by no means are dependent on such network being available. However, having a way to
distribute organizing efforts quickly to a lot of people scattered over an area certainly
helps inhabitants as well as aid organizations a lot, if done reliably.
Therefore, in order to enable the majority of people to have access to this disaster
recovery network, there are certain requirements for such a network. In the following
we try to explain why each of them is important, either for the intended use case or for
Ingenium. A disaster recovery network has to:
• be cheap. This is primarily a concern for Ingenium as the production costs for a
students project obviously have to be kept at the lowest possible. Other than the
costs for each airship this includes the items: router, WiFi cards, antenna, battery.
• support a lot of diverse clients. Legacy hardware support is an important
concern for a network solution in places with probably a very heterogeneous device situation. It can not be assumed that every network participant takes part
via a device capable of communicating in the most modern, energy efficient and
throughput-optimized protocols such as LTE, Bluetooth Low Energy or even WiFi
in 5 GHz frequency mode.
• be fast and easy to deploy. As Ingenium focuses on the hardware part of the
airships, they need to be able to deploy our set up network as easy and fast as
possible. This means that one of our tasks was to develop a convenient way to
provision the routers.
• be able to run for 24 hours with one charge. The airships are supposed
to be run as independent of human maintenance as possible. This includes an
automation to exchange the batteries equipped to the airships. Our requirement
is to reach an operation time on airship equipped batteries so that an exchange
has only to happen every 24 hours.
• consume very limited weight. Obviously the airships have to be as light as
possible to keep their size within reasonable and affordable limits. This resulted in
constraints we had to keep for what each airship could carry. We had to calculate
what dimensions in terms of battery capacity and therefore weight our setup would
need, with the goal not to cross 2 kg for the whole equipment on each router.
5
5. Current Situation and Project Decisions
In this chapter we want to describe the technological possibilities which we can use to
fulfill our project. There are different radio technologies, hardware solutions, meshing
algorithms and wireless transmission protocols. We looked into them and decided which
one is the best for our project.
There are a lot of technological solutions for radio transmissions, such as 2.4 GHz, 5
GHz, LTE or GPRS/UMTS. Because of our disaster recovery scenario we have to use a
technology which is widely used in the world. LTE is only available in newer smartphones
and GPRS/UMTS could be broken if the antennas are destroyed. So we decided to use
2.4 GHz and 5 GHz wireless technology. Because if you have a smartphone, which is one
of the main requirements, you have at least WiFi in 2.4 GHz frequency available.
We had the possibility to get real hardware from the TKN department. We can test
and play around with three Alix boards, the alix2d26 . These boards are equipped with
two wireless cards. One for 2.4 GHz and one with 5 GHz. We made some researches
how much they cost and if its affordable for the project. The Alix boards are not very
cheap7 but there is cheaper hardware available with similar specifications.
For the communication between the airships we wanted to use a meshing technology
based on wireless. There are two technologies how to setup wireless cards. The first one
is the infrastructure mode the other is the adhoc mode. All meshing algorithms assume
to use the adhoc mode. A wireless card which is set into adhoc mode allows to connect
to a different card and build a mesh, in the infrastructure mode the wireless card acts
as a host where different clients can connect to the host. So we needed to use the adhoc
mode for our mesh network. Which every wireless card should support, but not every
wireless driver has it implemented.
There are different ways to route the network traffic in the mesh network. We will
discuss advantages and disadvantages of them in the next section.
Our boards support OpenWRT8 as an operating system. It would also have been possible to use another Linux-based system like a customized Debian but OpenWRT is
a well-known router distribution with excellent driver support. So we decided to use
OpenWRT.
6
http://www.pcengines.ch/alix2d2.htm
http://www.alix-board.de/produkte/alix2d2.html
8
https://openwrt.org/
7
6
6. Routing
As mentioned earlier we wanted to use a meshing technology based on WiFi. While
it was clear to use the wireless ad-hoc mode to connect the routers we had to make a
decision how the routing in our mesh network should work. First, we needed to decide
whether to use static or dynamic routing.
Static routing has the advantage that it avoids management network traffic overhead.
But at the same time it comes with an enormous amount of manual administration
because the routing tables on every router have to be maintained. This affected especially
our scenario where the physical network topology can change quite often when nodes go
up or down.
Dynamic routing does the opposite. It produces management network traffic overhead
to reduce the amount of manual administration. We decided to use dynamic routing
so the mesh network needs as little administration as possible. The additional network
overhead compared to static routing is acceptable for us.
So we needed a dynamic routing protocol to find the best path through the mesh network.
Our research about routing protocols yielded the following three candidates.
6.1. HWMP
The 802.11s [2] standard defines a default meshing algorithm called Hybrid Wireless
Mesh Protocol (HWMP). There are existing implementations of HWMP but they are
only proof of concept implementations without active development. Also HWMP has
to recalculate and build its tree of the network [7] on every topology change. Based on
this lack of a production ready implementation we decided against HWMP.
6.2. OLSR
The Optimized Link State Routing (OLSR) protocol is optimized for mobile ad-hoc
networks. So at first glance it seemed to be perfect for our scenario. But it has also
some major disadvantages. Every router has to know the complete network topology to
calculate its routing table. This causes OLSR to perform bad in dynamic networks with
a lot of link changes due to the heavy usage of CPU and bandwidth resources. As our
mesh network has regular down times to recharge the batteries and could also change
its topology when network connectivity is needed in different areas during the recovery
process we decided that we won’t use OLSR in our mesh network.
7
6.3. B.A.T.M.A.N.
Our third candidate was the Better Approach To Mobile Adhoc Networking protocol
(B.A.T.M.A.N.). In contrast to OLSR the routers know only their neighbours and
not the complete network topology. This reduces the amount of recalculations for
topology changes which makes B.A.T.M.A.N. pretty resource friendly [3]. Additionally, B.A.T.M.A.N. proves to be faster in reaction to network changes due to the fact
that it is a layer 2 protocol [8]. This also means that it is possible to run any network
layer protocol above B.A.T.M.A.N. Moreover, B.A.T.M.A.N. has a really big community
and testbed because it is used by many Freifunk communities9 .
Based on these advantages compared to HWMP and OLSR we decided to use B.A.T.M.A.N.
as the routing protocol in our mesh network.
Because B.A.T.M.A.N. is an integral part of our network we want to explain how it
finds the best paths through the mesh network. Every router, also called originator, in
the mesh network sends regular originator messages (OGM) as broadcast to inform all
neighbours about its existence. Every neighbour should forward the OGM via another
broadcast. So at best every router receives every OGM and knows that it can reach
the originator via the router which broadcast the OGM. The time an OGM needs to
travel through the network depends on the quality and saturation of the used mesh links.
When a router receives multiple OGMs with the same id from the same originator it will
choose the path of the earliest received one because this indicates the best link quality.
7. Airmesh Solution
With all decisions made which technologies to choose and our requirements set, we
started building our three router mesh network prototype. Three routers were the minimum number of routers we needed to build a mesh network that differs from a normal
non-mesh network.
The first problem to tackle was to build a convenient way to flash the operating system
onto the boards. One of the reasons why we chose the Alix boards was that they run
of Compact Flash Cards. This made it quite easy to replace an old configured system
with an updated one as no special network boot (de-bricking) actions were needed and
the whole process was automatable.
In order to avoid manual reconfiguration each time we had to re-flash the cards and with
the intention to pass the solution on to Ingenium for fast and easy router provisioning,
we decided to invest time into a setup tool. Thus we wrote a script in Python with the
9
http://freifunk.net/wie-mache-ich-mit/community-finden/
8
niceties of providing a simple YAML10 configuration file and a folder with OpenWRT
specific configurations concerning system, user and network setup, and the tool would
put everything together on a prior mounted external storage device.
With that one could insert the storage card of a router to provision, start the tool with
the ID of the router and the file system path to the storage device, put the card back
into the router and deploy it, ready to take part in an existing mesh network already up
in the air.
Listing 1: Exemplary Airmesh configuration file for five routers
openWRTImagePath : "/home/ flashbot / airmesh / openWRT / image / openwrt
.img.gz"
openWRTConfigPath : "/home/ flashbot / airmesh / openWRT / configs /"
dropbearHostKeyBasePath : "/home/ flashbot / airmesh / openWRT /host keys/"
1:
name : "router -001"
clientSubnetName : "airclient -001"
2:
name : "router -002"
clientSubnetName : "airclient -002"
3:
name : "router -003"
clientSubnetName : "airclient -003"
4:
name : "router -004"
clientSubnetName : "airclient -004"
5:
name : "router -005"
clientSubnetName : "airclient -005"
Next we had to integrate into our configuration of OpenWRT and B.A.T.M.A.N. how
we imagined the network to function as a whole, meaning how the mesh would be
built between the routers and how they would provide WiFi networks for clients on the
ground.
Each of the Alix boards has two miniPCI slots, which in our case were equipped with
CM9-GP cards. These cards provide 802.11a/b/g WiFi functionality with data rates
ranging from 1 to 11 Mbps (b), 6 to 54 Mbps (a) and 1 to 54 Mbps (g) [1]. To avoid
interference of the mesh and the client network and support future IEEE 802.11 standards, for the B.A.T.M.A.N. mesh network one card was allocated operating in the 5
10
YAML Ain’t Markup Language - http://yaml.org
9
GHz band. The other cards on each router were designated to provide the client WiFi
networks in the 2.4 GHz band for legacy hardware support.
The question now was, how to enable connections between clients in one router client
network to clients in a client network of a router located at the other end of the mesh
network. As we will talk about more deeply in section 9.2 “Router Configuration” we
went for a static IP address assignment in the mesh network and therefore simply added a
route to each other router into the network configuration flashed via our deployment tool.
The final view of a client participating in one of the client networks is the following:
Figure 2: From client view all client networks connected transparently via the mesh
network appear to be reachable as one.
With that set we had a proper network setup done in a maintainable way. This leads to
the following project setup for testing and evaluation:
10
Figure 3: Our final Airmesh setup for evaluating the network’s parameters.
8. Theoretical limits
8.1. Power
In order to provide Ingenium a figure to calculate the needed battery capacity on each
airship, we estimated the maximum power consumed for our whole equipment based on
the available data in the respective data sheets. The Alix boards accept an operating
voltage in the range between 7V and 20V, with our test power supply delivering at
18V.
Firstly, according to their data sheet [5] the Alix boards are consuming 3W to 4W when
running an idling Linux and up to 6W without cards and USB devices at full load. For
our worst case battery capacity limit we are going to calculate with the 6W value.
Secondly, for this calculation we are going to assume that the two equipped wireless cards
are sending and receiving in 802.11g mode at their maximum with equal time shares
of sending and receiving. Their input voltage is 3.3V. This yields 400mA (sending)
and 350mA (receiving), for two cards resulting in an aggregated consumption of 0.75A.
With those values we can provide the following simple calculation to estimate the needed
battery capacity:
2 cards: 0.75A at 3.3V → 2.475W.
Board + 2 cards: 6W + 2.475W = 8.475W → per hour: 8.475Wh.
11
We can therefore estimate that following amount of energy will be needed to run our
setup independently of external power supply over 24 hours:
Needed energy: 8.475W over 24 hours → 203.4Wh.
At 14.8V: about 14Ah.
At 12V: about 17Ah.
After we reported our estimations to Ingenium, we were told that they are going to
calculate with 12V input voltage. Therefore we recommend to equip at least 17Ah of
battery capacity onto each airship if our hardware setup was used. What might also
impact these calculations are environmental aspects such as temperature in which the
airships are deployed as well as the gradually decreasing capacity of the batteries over
their lifetime.
8.2. Bandwidth
Our hardware supports the WiFi standards 802.11a, b and g. The advertised maximum
throughput rates for these standards are between 11 Mbps for b and 54 Mbps for a and
g. These are the nominal throughput limits which will not be achievable on transport
layer in reality. In fact, in [4] TCP throughput limits of 5.6 Mbps for b and 27.3 Mbps
for a and g were measured. Therefore we assumed to get approximately 27.3 Mbps.
During our research we came across the impact on bandwidth when adding additional
hops [9]. Each hop inbetween the source and the destination in a mesh network will cut
the throughput in half. This will lead to bigger problems when the network grows.
Also in theory each joining client will decrease the throughput for the clients which are
connected to the same router.
The capacity of mesh networks in terms of throughput has been researched heavily over
the last years. Already in 2000 there was a paper by Gupta and Kumar [6] which stated
that in a mesh network with n nodes each transmitting at speed W the throughput from
one node to a randomly chosen other node is estimated by Θ( √ W
). Of course, this
n·log(n)
applies to our mesh network. The more nodes take part in our disaster recovery mesh
network, the worse the achievable throughput from one node to another will inevitably
get, additionally to the already quite low starting point according to above formula.
After these research results we were skeptical if WiFi was the right technology for our
disaster recovery use case.
With our available equipment it was quite hard to test the impact of a lot of clients in the
WiFi client networks. In order to provide a dimension of what client load each router will
be able to take, we therefore had to look in other places. The Freifunk community has
great experience and useful statistics about serving Internet to many people. They keep
12
monitoring statistics of their various sites online11 which provide system level information
about load, memory usage and traffic characteristics of the connected interfaces. From
conversations with people from the core Freifunk community we came to know that
access points in the same hardware specifications area as the Alix boards will be able to
handle 50 concurrently connected clients. While this does not mean that these clients
will be able to transmit all at the same time, it provides a figure of how many clients
are viable per router to keep the network operational.
Another very valuable information is that instant messaging services are heavily used
in refugee camps which are supplied with Internet connectivity by Freifunk. As the
disaster recovery aid application running on top of our mesh network will - in our vision
of it - provide that functionality, we can draw the conclusion that such a network usage
will be no problem for routers in the same league as the Alix boards. As one Freifunk
community noted, for messaging use cases bandwidth is mostly not the critically needed
resource.
8.3. Range
To determine the theoretical limits in terms of coverage the routers could achieve we
had to rely on the values we were able to get from the data sheets [1] of the WiFi cards.
The values for distance state how far a router is able to send signals with these cards at
given circumstances.
The circumstances that were most fitting for our setup were on the one side the outdoor
scenario which obviously allowed greater distances than the indoor setting. On the other
hand we were using the 802.11g frequency band for the client networks on the routers.
Therefore we found that the CM9-GP cards were supposed to be sending data over 350
meters far at 6 MBps in an outdoor scenario.
To get from a distance to an area value, we performed following simple calculation:
3502 = 602 + x2
⇒ x2 = 3502 − 602
√
√
⇒ x2 = 118900
⇒
x = 344.818792991 ≈ 344.82 meters
To visualize all values we created the following model that displays the height of the
routers above ground, the theoretical transmitting distance according to our scenario
and the calculated radius of the area they are able to cover down on ground:
11
http://monitor.berlin.freifunk.net/
13
Figure 4: The theoretically coverable area based on the wireless card’s data sheet limits.
Taken from this we can derive how big the coverable area Atheo with r = 344.82m of
each router is:
Atheo = π · r2
⇒Atheo = π · (344.82)2
⇒Atheo = 373537.98157355125 ≈ 0.374 km2
9. Practice
For more reliable results additionally to the theoretical consideration we built a prototype
and performed tests on it. In the following chapter we want to discuss which hardware
we used, how we worked with it and what tests we performed.
9.1. Our Development Setup
During our development we had to reset the routers quite often and needed an easy
way to re-install and re-configure OpenWRT on them. For this purpose we wrote a
deployment tool in Python. The tool is not only convenient during development but
also usable for real deployment scenarios by Ingenium.
The Alix2d2 boots its operating system from a CompactFlash card. After connecting the
card to a computer we were able to run our deployment tool which reads a configuration
file, installs OpenWRT and B.A.T.M.A.N. on the card and configures them regarding
to the configuration file.
The script has two parameters which have to be set. The -r or –router flag specifies
the ID the router will have once the card is inserted back into it, in our case an ID
between 1 and 254. For the IP assignments the script uses the configuration file which
14
is described above (chapter 1). The second parameter, -c or –compactflash, points to
the storage/device where the OpenWRT image should be copied.
For development we connected the three routers and our laptops to a switch. By this
controlled channel we were able to connect to the routers for debugging and configuration
without interfering with the wireless networks.
Figure 5: Our development setup
9.2. Router Configuration
Our routers are operating on OpenWRT in the current stable release called Chaos Calmer
(15.05). We installed following packages and their dependencies:
•
•
•
•
•
•
•
batctl
kmod-batman-adv
libpthread
kmod-tun
kmod-lib-crc16
libc
iperf
We also installed further packages like screen, tcpdump, zsh, iw, . . . for debugging
and testing purposes. We configured the client network to work in the 2.4 GHz frequency band and set the meshing interfaces to 5 GHz. The distinction between the layer
B.A.T.M.A.N. works on (layer 2) and the mesh network abstraction it provides to upper
layers (e.g. our IP address assignments on layer 3), we visualized in figure 6.
15
Figure 6: Differentiation between layer 2 and layer 3
Each router gets a static IP of a 10.22.5.0/24 network for the B.A.T.M.A.N. interface.
For the client network each router is assigned a /24 network in the 172.16.X.0 address
space, where X is the ID of the router. With this scheme we can provide 254 routers, each
of them theoretically able to serve 253 clients with IP addresses via DHCP. Normally,
for exchanging routing information between networks you use a protocol like BGP12
or RIP13 . We decided that we can reduce the communication in the network if we put
static routes to all possible mesh destinations into each router directly. This means we
generated in total 253 routes per router and added them to their network configuration.
9.3. Tests
We performed two different types of tests. The first one was a simple range test to figure
out what connection distances our routers were able to manage. The second ones were
multiple bandwidth tests which we will examine below.
12
13
Border Gateway Protocol
Routing Information Protocol
16
9.3.1. Range Test
The data sheet [1] provided us a possible range of 350 meters transmitting range at
6 Mbps. At the building (lower left endpoint) we had one of our Alix boards and we
connected a notebook to the board. We walked away and tested every 50m how good
our transmission rate was. We were able to achieve nearly 200 meters in direct sight;
after this we lost the connection and were not able to perform another successful test.
Figure 7: Range test
9.3.2. Bandwidth Tests
We used the iperf tool14 which is a widely used cross-platform bandwidth testing tool.
The server is the receiving endpoint where the connected client is sending data to. We
decided to use TCP as transport protocol because our network will mostly be used for
HTTP connections in the real world environment.
To recap, our assumptions from section 8.2 were that we get a bandwidth of 27.3 Mbps
[4] on a single hop connection in our network, the throughput will cut in half for each
additional hop between sender and receiver [9] and adding more clients will further reduce
the throughput for each of them. With the following tests we want to prove or refute our
assumptions and get a rough idea whether our project will work out or not. The lines
in our test setup images are representing only the distance between our devices. The
devices are connected via WiFi. The S stands for the iperf server and was a MacBook
14
https://github.com/esnet/iperf
17
Pro. C1 and C2 were two Lenovo ThinkPads with the same hardware configuration and
C3 was a OnePlus One smartphone.
Figure 8: First test setup
Figure 9: First test results
In the first bandwidth test we connected one client, two clients and three clients to one
router and tested the bandwidth. The above boxplot 9 shows that we can reach 4 Mbps
18
with one client, with two clients we reach near 8 Mbps. Also adding an additional third
client doesn’t change the maximum throughput to a higher value.
Figure 10: Second test setup
Figure 11: Second test results
In the second test we added a second router and moved the iperf server to the added
19
router. That router was placed in such a way that it was part of the mesh network while
not handling any clients except the server. This resulted in one more hop between the
clients and the iperf server. In the first measurement in figure 11 (one client) we see that
the throughput has doubled compared to the first measurement in figure 9. The other
two measurements don’t yield different results from the first test.
Figure 12: Third test setup
Figure 13: Third test results
20
In the last test we attached the last third router in between the first and the second
router without handling any clients. Therefore the added router solely was taking part
in the mesh network, forwarding traffic from the client networks on both of the other
two routers. In this test we had three hops between the clients and the iperf server.
The throughput for each of the connection settings in figure 13 (one, two and three
simultaneous clients) doesn’t show a huge difference to the other tests.
Our tests and the results showed us that not all assumptions we had stood firm. The first
assumption was that we achieve a bandwidth of 27 Mbps on a single hop connection. All
tests showed that we can reach a maximum of 8 Mbps, which is less than expected. To
prove the second assumption the results would had to show that with every additional
hop we added the throughput was cut in half. But unfortunately we could not observe
that either. The last assumption was that more clients on the same WiFi decrease the
throughput further for each client. This behaviour is visible in all three tests where we
had first one client, then two and at the end three clients and every time we added a
client the throughput for each client alone was reduced significantly.
10. Conclusion
Let’s get this out right away: We are quite satisfied with the results even our small
test network was able to achieve. After the initial enthusiasm about using WiFi as the
technology to build a mesh network between airships, we had our research phase to get
to know the technology situation better. This gave us quite a bit of a setback as multiple
sources drew more of a pessimistic image about what speed and distance orders could
be achieved with WiFi ([6], [4] and [9]).
Then we started to build our test network consisting of the three mentioned Alix2d2
boards and were pleasantly surprised about what these boards in combination with the
equipped WiFi cards could achieve in terms of distance. For a disaster recovery network
with the goals to be as cheap as possible and use as few airships as possible, distance
is a very important metric. The observed bandwidth was not great in terms of typical
multimedia heavy usage but definitely enough for a bandwidth-light application designed
for disaster recovery. It has to be mentioned that we did not have a testing environment
with the same conditions as the airships will be deployed in because we had quite a lot of
interference from neighbouring WiFi networks. This will probably not be the case in a
disaster scenario where the airship network would be used. Additionally, the number of
real clients we had available to test is not representative to what a final network would
be able to serve. For real world experiences we recommend to have a look at the Freifunk
statistics, covered in section 8.2.
Overall, from the setup perspective working with OpenWRT, B.A.T.M.A.N. and our
deployment tool was very convenient and resulted in a provisioning time for our network
21
of three boards of about five minutes from the point of flashing OpenWRT onto the cards
until the routers were running, had found their meshing companions and were able to
send traffic.
From a hardware perspective we already mentioned that we were quite satisfied with
the performance and the features of the Alix2d2 boards in combination with the WiFi
cards. Nonetheless we would recommend Ingenium to have a look at the comparison of
router models DKØTU and Freifunk members compiled as it provides further information on energy consumption and extensibility15 . Taken from that project, the MikroTik
Routerboard RB433UAHL16 or RB435G17 could be very interesting options.
All in all, the performance of the built Airmesh network was sufficient. When we reported back our findings to Ingenium they also were comfortable with the results and
had already planned with distances and bandwidth values in the area we reached. To
conclude we are cautiously optimistic that a network built in the fashion we did with our
Airmesh network in combination with a bandwidth-light and fault tolerant aid application on top will be able to achieve the goals we defined in our project requirements.
11. Future Work
In this last section we want to give ideas in which directions the next research could
go. The recently finalized WiFi protocol 802.11ah [10] operates on a different and lower
frequency which leads to a better range but the advantages and disadvantages have to be
researched for projects such as this one. Another nice concept could be to change some
part of the mesh network to be LTE-based and build a higher hierarchy which hopefully
could help to achieve better coverage of an area. Taken from one of the Freifunk meetings
we expect that there is a lot of potential to improve the network’s performance by using
specialized antennas. For example it could be a good idea to use an omnidirectional
(doughnut) antenna for the meshing network and a cone antenna for the client network.
The community of Freifunk also told us that there is an upcoming version two of OLSR.
Therefore it would be interesting to compare B.A.T.M.A.N. against OLSRv2.
15
http://www.dk0tu.de/Projekte/PicoPeering/Off-grid_Backbone/Links/#router
http://routerboard.com/RB433UAHL
17
http://routerboard.com/RB435G
16
22
References
[1] Wistron NeWeb - CM9-GP Approval Sheet. http://www.pcengines.ch/pdf/cm9.
pdf. [Online]. Accessed: 25.01.2016.
[2] IEEE Standard for Information Technology–Telecommunications and information
exchange between systems–Local and metropolitan area networks–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) specifications Amendment 10: Mesh Networking. IEEE Std 802.11s-2011
(Amendment to IEEE Std 802.11-2007 as amended by IEEE 802.11k-2008, IEEE
802.11r-2008, IEEE 802.11y-2008, IEEE 802.11w-2009, IEEE 802.11n-2009, IEEE
802.11p-2010, IEEE 802.11z-2010, IEEE 802.11v-2011, and IEEE 802.11u-2011),
pages 1–372, Sept 2011.
[3] Corinna Aichele. The OLSR.ORG story. https://www.open-mesh.org/projects/
open-mesh/wiki/The-olsr-story. [Online]. Accessed: 14.02.2016.
[4] Matthew Gast.
When Is 54 Not Equal to 54?
A Look at 802.11a, b,
and g throughput. http://archive.oreilly.com/pub/a/wireless/2003/08/08/
wireless_throughput.html. [Online]. Accessed: 22.01.2016.
[5] PC Engines GmbH.
PC Engines - ALIX.2 / ALIX.3 series system
boards.
http://resources.mini-box.com/online/MBD-P-ALIX-2D2/
MBD-P-ALIX-2D2-manual.pdf. [Online]. Accessed: 25.01.2016.
[6] Gupta, Piyush and Kumar, Panganmala R. The capacity of wireless networks.
Information Theory, IEEE Transactions on, 46(2):388–404, 2000.
[7] Venkat Mohan.S and Dr. Kasiviswanath.N.
Routing Protocols for
Wireless
Mesh
Networks.
http://www.ijser.org/researchpaper%
5CRouting-Protocols-for-Wireless-Mesh-Networks.pdf. [Online]. Accessed:
13.01.2016.
[8] Pojda, Jakob and Wolff, Andreas and Sbeiti, Mohamad and Wietfeld, Christian.
Performance analysis of mesh routing protocols for uav swarming applications. In
Wireless Communication Systems (ISWCS), 2011 8th International Symposium on,
pages 317–321. IEEE, 2011.
[9] Inc. Strix Systems. Solving the Wireless Mesh Multi-Hop Dilemma. http://www.
strixsystems.com/products/datasheets/StrixWhitepaper_Multihop.pdf.
[Online]. Accessed: 12.12.2015.
[10] Weiping Sun, Munhwan Choi, and Sunghyun Choi. IEEE 802.11ah: A Long Range
802.11 WLAN at Sub 1 GHz. http://riverpublishers.com/journal/journal_
articles/RP_Journal_2245-800X_115.pdf. [Online]. Accessed: 17.12.2015.
23
Appendices
A. User Guide for Setting Up an Airmesh Network
This guide provides a comprehensive way to set up an Airmesh network with the help
of the deployment tool we developed for this project (appendix B) and involved configuration files.
A.1. Requirements
In order to set up an Airmesh you will need the following items:
• Alix boards, each with power supply, equipped WiFi cards and a storage card (in
our case Compact Flash Cards)
• One computer with either an integrated card reader or an USB port for an external
card reader
• If needed: an external card reader
• Our code base containing the deployment tool and involved configuration files
In the following, X will be used as the ID of a router. This will be needed for a generalized
description of configuration files and command line parameters. So each time X is read,
replace it with the corresponding ID of the router.
Furthermore, it will be assumed the working directory for this guide is located in
/home/flashbot/airmesh/ with the following directory structure:
− airmesh−c o n f i g s
|− e t c
|− c o n f i g
|− d r o p b e a r
|− i n i t . d
|− r o o t
|− airmesh−setup− i n s t a l l . sh
|− p a c k a g e s
− airmesh−d e p l o y . py
− c o n f i g . yaml
− openwrt
|− openwrt . img . gz
24
A.2. Setting Up
The process of provisioning your Alix boards to build up a mesh network involves two
major parts: constructing a configuration file with references to needed files and a per
router definition; and flashing everything ready to build a mesh network onto each
storage card of the routers.
A.2.1. Defining Your Configuration File
Open up config.yaml in the editor of your choice and define the paths to the needed
files in the first three lines of the file; similar to this:
openWRTImagePath : "/home/ flashbot / airmesh / openWRT / image / openwrt
.img.gz"
openWRTConfigPath : "/home/ flashbot / airmesh / openWRT / configs /"
dropbearHostKeyBasePath : "/home/ flashbot / airmesh / openWRT /host keys/"
Leave one line empty and per router append following generalized lines adapted for each
router:
X:
name : "router -00X"
clientSubnetName : "airclient -00X"
A complete example of how the configuration file should look like for a set up of five
Alix boards building the mesh network you can find in listing 1.
In line 53 of the deployment tool (appendix B) fill in the password for the root account
on each router in the appropriate /etc/shadow file format. This password is needed
to protect the root account of each router from unauthorized access which could result
in serious damage of your setup. Therefore choose a uniquely used, strong, random
password containing characters from the whole spectrum of alphanumeric letters (a-z,
A-Z, 0-9). For length, choose a password at least 20 characters long.
To generate the password in the appropriate format, on a UNIX machine with the
openssl command available you can use:
$ o p e n s s l passwd −1 YOUR STRONG PASSWORD HERE
Put the output between the two colons in line 53. The old line
s e l f . rootPassword = ” r o o t :ROOT PASSWORD HASH: ”
25
could after that look something like this:
s e l f . rootPassword = ” r o o t : $1$krwyj19l$pTzwnwyJ6RDPtJkLwk97T0 : ”
A.2.2. Flashing the Storage Cards
After you are done specifying all needed configuration lines and the root password, you
are ready to flash the configured system onto the router cards.
When you insert the storage card of a router into your internal or external card reader
make sure to memorize the exact device node of the card. In the following examples it
will be assumed the card got mapped to /dev/sdc.
In the working directory /home/flashbot/airmesh/ invoke the following command for
each router:
$ . / airmesh−d e p l o y . py −r X −c / dev / s d c
This command will take a while, make sure not to interrupt until the program execution
returns to the prompt. The output of the command will be helpful to understand what
is going on.
After you have completed this step for each router involved, insert the cards into the
corresponding routers and power them up.
A.3. Starting Up
You are done with configuring and flashing the operating system and involved drivers
onto the cards and have powered up all routers. Give them some time to execute their
initial setup scripts. As these will install packages on the system, it might easily take
up to five minutes to complete. This will only be executed once for a newly provisioned
router.
At this point you are ready to use your Airmesh network! The routers should be up and
running, configured to build a mesh network via B.A.T.M.A.N. in the 5 GHz frequency
and ready to handle clients in their own 2.4 GHz client networks.
26
B. Source Code of the Airmesh Deployment Tool
#! / u s r / b i n / env python3
# −∗− c o d i n g : u t f 8 −∗−
#
#
#
#
Airmesh
Deployment s c r i p t t o automate t h e c o n f i g u r a t i o n o f our
r o u t e r s and s e t t i n g up t h e mesh network t o be t e s t e d .
Part o f t h e TKN P r o j e c t .
# Import system s p e c i f i c p a c k a g e s
import sys , os , t r a c e b a c k
# Import time p a c k a g e
import time
# Import r e g u l a r e x p r e s s i o n p a c k a g e
import r e
# Import YAML c o n f i g u r a t i o n markup p a c k a g e
import yaml
# Import t e m p f i l e p a c k a g e
import t e m p f i l e
# Import a r g p a r s e p a c k a g e t o have p r o p e r command l i n e
# argument s u p p o r t
import a r g p a r s e
# Import sh p a c k a g e t o have f u l l y f l e d g e d s h e l l c a p a b i l i t e s
import sh
# Import f i l e i n p u t t o r e p l a c e l i n e s i n c o n f i g u r a t i o n f i l e s
import f i l e i n p u t
### C l a s s e s ###
c l a s s Router :
c o n f i g P a t h = ” c o n f i g . yaml ”
def
i n i t ( s e l f , r o u t e r I D , compactFlashPath ) :
s e l f . ID = r o u t e r I D
s e l f . compactFlashPath = compactFlashPath
s e l f . prefixIP = ” 10.22.5. ”
s e l f . prefixSubnet = ” 172.16. ”
s e l f . ip = s e l f . p r e f i x I P + str ( routerID )
s e l f . clientSubnet = s e l f . prefixSubnet + str ( routerID ) + ” . 0 ”
27
s e l f . rootPassword = ” r o o t :ROOT PASSWORD HASH: ”
def p r i n t V a l u e s ( s e l f ) :
print ( ” Router ID : ” + s e l f . ID )
print ( ”Compact f l a s h path : ” + s e l f . compactFlashPath + ” \n” )
print ( ” P r e f i x f o r r o u t e r meshing network : ” + s e l f . p r e f i x I P )
print ( ” P r e f i x f o r c l i e n t s u b n e t s : ” + s e l f . p r e f i x S u b n e t )
print ( ” Router IP : ” + s e l f . i p )
print ( ” Router ’ s c l i e n t s u b n e t : ” + s e l f . c l i e n t S u b n e t )
### F u n c t i o n s ###
# Read i n t h e airmesh c o n f i g u r a t i o n f i l e and add
# important values to the router c l a s s .
def b u i l d C o n f i g ( r o u t e r ) :
# Load t h e YAML c o n f i g f i l e
with open ( r o u t e r . c o n f i g P a t h , ’ r ’ ) a s f :
c o n f i g F i l e = yaml . l o a d ( f )
try :
c o n f i g F i l e [ r o u t e r . ID ]
except :
print ( ” Router ID not found i n c o n f i g u r a t i o n f i l e ” + r o u t e r .
configPath + ” . ” )
print ( ” P l e a s e s t i c k t o t h e naming scheme f o r your r o u t e r s . ” )
print ( ” E x i t i n g . \ n” )
sys . exit (1)
r o u t e r . openWRTImagePath = c o n f i g F i l e [ ”openWRTImagePath” ]
# I f t h e read OpenWRT image p a t h i s s e t t o an empty s t r i n g ,
# assume we want t o use t h e c u r r e n t w o r k i n g d i r e c t o r y
# ( e . g . the checked out g i t ) .
i f r o u t e r . openWRTImagePath == ” ” :
r o u t e r . openWRTImagePath = ” openwrt / openwrt . img . gz ”
r o u t e r . openWRTConfigPath = c o n f i g F i l e [ ”openWRTConfigPath” ]
# I f t h e read OpenWRT c o n f i g p a t h i s s e t t o an empty s t r i n g ,
# assume we want t o use t h e c u r r e n t w o r k i n g d i r e c t o r y
# ( e . g . the checked out g i t ) .
i f r o u t e r . openWRTConfigPath == ” ” :
r o u t e r . openWRTConfigPath = ” airmesh−c o n f i g s / ”
r o u t e r . dropbearHostKeyBasePath = c o n f i g F i l e [ ” dropbearHostKeyBasePath ” ]
# I f t h e read b a s e p a t h t o t h e h o s t k e y s i s s e t t o an empty s t r i n g ,
# assume we want t o use t h e c u r r e n t w o r k i n g d i r e c t o r y
# ( e . g . the checked out g i t ) .
i f r o u t e r . dropbearHostKeyBasePath == ” ” :
28
r o u t e r . dropbearHostKeyBasePath = ” airmesh−host−k e y s / ”
r o u t e r . name = c o n f i g F i l e [ r o u t e r . ID ] [ ”name” ]
r o u t e r . clientSubnetName = c o n f i g F i l e [ r o u t e r . ID ] [ ” clientSubnetName ” ]
r o u t e r . mountPoint = t e m p f i l e . mkdtemp ( p r e f i x = ” airmesh−” )
# Unmount a l l p a r t i t i o n s o f a g i v e n d e v i c e
def unmountAll ( d e v i c e ) :
# Extract the device part of the given device path
try :
d e v i c e I D = r e . s e a r c h ( ’ ( [ a−z0 −9]+)$ ’ , d e v i c e ) . group ( 1 )
except :
print ( ”No matching d e v i c e found . P l e a s e t r y a d i f f e r e n t one . ” )
print ( ” E x i t i n g . \ n” )
sys . exit (1)
# Get t h e amount o f p a r t i t i o n s matching t h e d e v i c e i d e n t i f i e r
n u m P a r t i t i o n s = int ( sh . wc ( sh . g r e p ( sh . l s b l k ( ) , d e v i c e I D ) , ”− l ” ) )
# Unmount each one o f them
for x in range ( 1 , n u m P a r t i t i o n s ) :
try :
sh . umount ( d e v i c e + s t r ( x ) )
except :
print ( ” Could not unmount p a r t i t i o n ” + d e v i c e + s t r ( x ) + ” . ” )
print ( ” Probably a l r e a d y unmounted . C o n t i n u i n g . \ n” )
return True
# Ask u s e r a q u e s t i o n and e x p e c t an answer ’ y e s ’ or ’ no ’ .
def yesNoQuestion ( q u e s t i o n ) :
# Only t h e s e b o t h answers a r e a c c e p t e d
v a l i d A n s w e r s = { ” y e s ” : True , ”no” : F a l s e }
# Make s u r e t h a t t h i s d e v i c e r e a l l y s h o u l d be o v e r w r i t t e n
while True :
# Ask on STDOUT and r e t r i e v e answer
s y s . s t d o u t . w r i t e ( q u e s t i o n + ” [ y e s /no ] ” )
c h o i c e = input ( ) . l o w e r ( )
i f c h o i c e in v a l i d A n s w e r s :
return v a l i d A n s w e r s [ c h o i c e ]
else :
print ( ” P l e a s e answer with e i t h e r ’ y e s ’ o r ’ no ’ . ” )
# Replace s t r i n g in f i l e h e l p e r .
def r e p l a c e S t r i n g I n F i l e ( i n p u t F i l e , l i n e T o D e l e t e , lineToAdd ) :
29
with f i l e i n p u t . F i l e I n p u t ( i n p u t F i l e , i n p l a c e = True ) a s i F i l e :
for l i n e in i F i l e :
print ( l i n e . r e p l a c e ( l i n e T o D e l e t e , lineToAdd ) , end = ’ ’ )
# This f u n c t i o n e n a b l e s t h e c l i e n t n e t w o r k i n g
# i n Airmesh . As we use a s t a t i c r o u t i n g approach t o
# enable c l i e n t in d i f f e r e n t router subnets to
# t a l k t o each o t h e r , we need t o d e p l o y r o u t e s
# t o each s u b n e t w i t h e v e r y r o u t e r .
def b u i l d R o u t e s T o C l i e n t S u b n e t s ( r o u t e r ) :
r o u t e s S t r i n g = ””
# Range o v e r a l l p o s s i b l e IP ’ s i n t h e mesh network
# and add r o u t e s t o a l l o t h e r c l i e n t s u b n e t s , as l o n g as
# t h i s i s not t h e r o u t e r ’ s own ID .
for r in range ( 1 , 2 5 5 ) :
i f r == r o u t e r . ID :
continue
r o u t e s S t r i n g += ” c o n f i g r o u t e \n\ t o p t i o n i n t e r f a c e ’ bat0 ’ \ n\ t o p t i o n
t a r g e t ’ ” + r o u t e r . p r e f i x S u b n e t + s t r ( r ) + ” . 0 ’ \ n\ t o p t i o n netmask
’ 2 5 5 . 2 5 5 . 2 5 5 . 0 ’ \ n\ t o p t i o n gateway ’ ” + r o u t e r . p r e f i x I P + s t r ( r ) +
” ’ \ n\n”
# R e p l a c e p l a c e h o l d e r i n network f i l e w i t h a l l r o u t e s
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / c o n f i g / network ” , ”
CONFIGURE CLIENT SUBNET ROUTES” , r o u t e s S t r i n g )
# F l a s h an OpenWRT image onto t h e s u p p l i e d compact
# f l a s h car d .
def f l a s h I m a g e ( r o u t e r ) :
# Unmount a l l p a r t i t i o n s on t h e compact f l a s h card
unmountAll ( r o u t e r . compactFlashPath )
# Make s u r e t h e d e v i c e s h o u l d r e a l l y be c o m p l e t e l y o v e r w r i t t e n
o v e r w r i t e = yesNoQuestion ( ”IMPORTANT: Are you s u r e you want t o c o m p l e t e l y
o v e r w r i t e ” + r o u t e r . compactFlashPath + ” ? ” )
i f overwrite :
# FLAAAASH
f l a s h P r o c e s s = sh . dd ( sh . g u n z i p ( ”−c ” , r o u t e r . openWRTImagePath ) , ” o f l a g
=d i r e c t ” , ” bs=4M” , ” o f=” + r o u t e r . compactFlashPath , bg = True )
print ( ”\ n F l a s h i n g s t a r t e d . . . ” )
f l a s h P r o c e s s . wait ( )
print ( ” F l a s h i n g done . \ n” )
else :
print ( ”You c h o s e not t o o v e r w r i t e ” + r o u t e r . compactFlashPath + ” . ” )
print ( ” E x i t i n g . \ n” )
30
sys . exit (1)
# Wait two s e c o n d s t o make s u r e t h e d e v i c e s a r e r e a d y
sh . s l e e p ( 2 )
# Unmount a l l p a r t i t i o n s on t h e compact f l a s h card
unmountAll ( r o u t e r . compactFlashPath )
# Wait two s e c o n d s t o make s u r e t h e d e v i c e s a r e r e a d y
sh . s l e e p ( 2 )
# Mount t h e newly c r e a t e d OpenWRT image and c o n f i g u r e
# e v e r y t h i n g s p e c i f i c t o Airmesh ne ed s .
def c o n f i g u r e I m a g e ( r o u t e r ) :
# Mount t h e newly c r e a t e d image t o t h e s p e c i f i e d mount p o i n t
sh . mount ( r o u t e r . compactFlashPath + ” 2 ” , r o u t e r . mountPoint )
# Copy airmesh s p e c i f i c network c o n f i g s i n t o t h e mounted image
sh . r s y n c ( ”−rv ” , r o u t e r . openWRTConfigPath , r o u t e r . mountPoint + ” / ” )
# S e t a r o o t password
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / shadow ” , ” r o o t : : ” , r o u t e r .
rootPassword )
# Change r o o t ’ s l o g i n s h e l l t o z s h
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / passwd ” , ” : / r o o t : / b i n / ash ” ,
” : / root : / bin / zsh ” )
# I n s e r t a u s e f u l hostname ( e . g . ” r o u t e r −007”)
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / c o n f i g / system ” , ”
REPLACE WITH ROUTER HOSTNAME” , r o u t e r . name )
# Copy t h e s a v e d d r o p b e a r s s h h o s t k e y s t o c o r r e c t l o c a t i o n
sh . cp ( r o u t e r . dropbearHostKeyBasePath + r o u t e r . name + ” /
d r o p b e a r d s s h o s t k e y ” , r o u t e r . mountPoint + ” / e t c / d r o p b e a r / ” )
sh . cp ( r o u t e r . dropbearHostKeyBasePath + r o u t e r . name + ” /
d r o p b e a r r s a h o s t k e y ” , r o u t e r . mountPoint + ” / e t c / d r o p b e a r / ” )
# S e t c o r r e c t p e r m i s s i o n s on some f i l e s
sh . chmod ( ” 0600 ” , r o u t e r . mountPoint + ” / e t c / d r o p b e a r / a u t h o r i z e d k e y s ” )
sh . chmod ( ” 0700 ” , r o u t e r . mountPoint + ” / r o o t / airmesh−setup− i n s t a l l . sh ” )
# Link our s e t u p b a s h s c r i p t t o run a t b o o t on t h e r o u t e r s
sh . l n ( ”−s ” , ” . . / i n i t . d/ airmesh−setup− i n s t a l l ” , r o u t e r . mountPoint + ” / e t c /
r c . d/ S100airmesh−setup− i n s t a l l ” )
# I n s e r t r o u t e r ’ s IP a d d r e s s
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / c o n f i g / network ” , ”
REPLACE WITH ROUTER MESH IP” , r o u t e r . i p )
# Replace p a l c e h o l d e r s f o r subnet with c o r r e c t v a l u e s
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / c o n f i g / network ” , ”
REPLACE WITH ROUTER CLIENT SUBNET IP” , r o u t e r . c l i e n t S u b n e t [ : − 1 ] + ” 1 ” )
31
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / c o n f i g / network ” , ”
REPLACE WITH ROUTER CLIENT SUBNET BROADCAST” , r o u t e r . c l i e n t S u b n e t [ : − 1 ]
+ ” 255 ” )
# I n s e r t a d i s t i n c t c l i e n t s u b n e t name
r e p l a c e S t r i n g I n F i l e ( r o u t e r . mountPoint + ” / e t c / c o n f i g / w i r e l e s s ” , ”
REPLACE WITH ROUTER CLIENT SUBNET” , r o u t e r . clientSubnetName )
# Add r o u t e s t o a l l c l i e n t s u b n e t s
buildRoutesToClientSubnets ( router )
# Wait two s e c o n d s t o make s u r e t h e d e v i c e s a r e r e a d y
sh . s l e e p ( 2 )
# Unmount a l l p a r t i t i o n s on t h e compact f l a s h card
unmountAll ( r o u t e r . compactFlashPath )
### Main ###
def main ( ) :
# Parse s u p p l i e d p a r a m t e r s
p a r s e r = a r g p a r s e . ArgumentParser ( d e s c r i p t i o n = ’ S e t s up t h e \
OpenWRT c o n f i g u r a t i o n and mesh network f o r t h e s u p p l i e d \
c o n s e c u t i v e r o u t e r number on t h e compact f l a s h c a r d \
s u p p l i e d v i a parameter , t o o . ’ )
p a r s e r . add argument (
’−r ’ ,
’−−r o u t e r ’ ,
action = ’ store ’ ,
dest = ’ router ’ ,
help = ’ P r o v i d e an i n t e g e r v a l u e between 1 and 2 5 4 . This \
number w i l l be t h e ID o f t h e newly c r e a t e d r o u t e r and \
d e f i n e s which IP and c l i e n t s u b n e t t h e r o u t e r w i l l g e t . ’ ,
type = int ,
r e q u i r e d = True )
p a r s e r . add argument (
’−c ’ ,
’−−c o m p a c t f l a s h ’ ,
action = ’ store ’ ,
d e s t = ’ compactFlashPath ’ ,
help = ’ P r o v i d e t h e path t o t h e compact f l a s h c a r d t h a t \
w i l l be i n s e r t e d i n t o t h e new r o u t e r . The c a r d w i l l be \
c o m p l e t e l y o v e r w r i t t e n , s o be s u r e you p r o v i d e t h e c o r r e c t \
path . ’ ,
r e q u i r e d = True )
args = parser . parse args ()
# Creat e new r o u t e r c l a s s w i t h p r o v i d e d arguments
r o u t e r = Router ( a r g s . r o u t e r , a r g s . compactFlashPath )
32
# B u i l d r o u t e r c o n f i g from c o n f i g f i l e
buildConfig ( router )
# F l a s h OpenWRT onto compact f l a s h car d
flashImage ( router )
# C o n f i g u r e network and e v e r y t h i n g on t h e image
configureImage ( router )
# Clean up and e x i t
o s . r e m o v e d i r s ( r o u t e r . mountPoint )
sys . exit (0)
if
name
main ( )
== ’
main
’:
33