A blueprint for low cost urban wifi based on mesh technology

Transcription

Paul Scollon
B.Sc. IT Management 2012
Dundalk Institute of Technology
Acknowledgements
Acknowledgements
•
My long suffering fiancée Mary, who has not only taken over the majority of
our wedding arrangements while I completed this paper, but listened to me
speculate endlessly about how much wireless mesh networks would change
the lives of people all over the world, even though she doesn't quite see it!
•
Brendan Minnish, CTO at Westnet.ie for his advice on the Irish Linux Users
mailing list and his subsequent participation in the interviews during Chapter
4.
•
Robert Henderson, ICT Operations Manager for The Convention Centre in
Dublin for his participation in Chapter 4.
•
Chris Murphy at Image IT Group, Drogheda for his participation in Chapter 4.
•
Brenda at the Dundalk Chamber of Commerce for her help getting my user
survey questions out to local business owners.
•
Martin McCourt, my project supervisor, for his endless advice and insight into
the issues raised in my project.
•
All the other lecturers I've had over the last 3 years, who allowed me to
interrupt their classes with questions and never once blamed me for the fact
they couldn't login to Moodle, even though I probably did have something to
do with it.
i
Abstract
Abstract
Imagine leaving a tap running outside your business and telling people, thirsty
people on a hot summer afternoon, that they are not allowed to drink this water
because you pay the rates and they do not. Instead, you would rather let the water
just wash away down the drain.
As crazy as this analogy sounds, this is what happens in town centres every day with
small businesses paying for flat rate broadband that only they use for a couple of
minutes a day in total. The public cannot access this bandwidth as it is either not
advertised or is encrypted in some way. Wouldn't it better if each business could
share out a portion of their unused bandwidth to a larger network for customers and
tourists all over the town to use?
Wouldn't it be better again if customers connected to this network where informed of
special offers? If visitors were directed to the nearest restaurant and able to view the
menu online?
All this would be possible by implementing a community mesh network using local
small businesses as gateways to the Internet. A wireless mesh can be seen as a
special implementation of a wireless ad-hoc network with a more planned
configuration, and is usually deployed to provide dynamic and cost effective
connectivity over a large geographic area like a town or city.
However, urban mesh networks are not very popular in Europe, and are not even
considered as a solution in Ireland. Why is this? Is it awareness? Do people know
they exist? Maybe there are technical reasons why they just won't work? Or is it
because most mesh projects are Open Source and are therefore dismissed as a
hobby for 'nerds' or 'geeks'?
This project aims to explore all facets of mesh networks, from defining what exactly
they are, exploring the available technology, gathering public feedback to
implementing an actual working model and making recommendations to anyone
planning their own implementation. The outcome will be everything you need to know
about wireless mesh and other technologies required to build a working network in
your town.
ii
Table Of Contents
Table of Contents
Abstract...................................................................................................................... i
Acknowledgements....................................................................................................ii
Table of Contents......................................................................................................iii
List of Figures............................................................................................................ v
List of Tables............................................................................................................. vi
Chapters
1 - Introduction...............................................................................................1
Fictional Scenario............................................................................2
Researching the Topic.....................................................................4
Expected Outcome..........................................................................6
2 - Literature Review......................................................................................7
Defining Wireless Mesh Networks (WMNs).....................................7
Advantages of WMNs....................................................................10
Uses of WMNs...............................................................................12
Security Concerns.........................................................................14
Routing Protocols..........................................................................17
Deployment Issues........................................................................21
Conclusions...................................................................................24
3 - Technology Review.................................................................................28
Overview........................................................................................28
Wireless Mesh Networking Principles..............................32
OLSR - Our Protocol Of Choice?.....................................33
Hardware.......................................................................................37
Firmware........................................................................................46
Dashboards...................................................................................53
Content Filtering............................................................................59
Filtering with a Proxy........................................................60
Filtering with DNS............................................................66
Conclusions...................................................................................70
4 - Case Study...............................................................................................71
Overview.......................................................................................71
Survey...........................................................................................76
Interviews......................................................................................78
Site Visit.........................................................................................83
Conclusions...................................................................................86
5 - Investigation............................................................................................87
Building Your Own Mesh Network..................................................87
Configuring and Deploying Hardware...............................87
Dashboard Configuration.................................................88
iii
Table Of Contents
Implementing Content Filtering........................................92
Desktop Configuration for (hidden) secure SSID............100
Adding Web Technologies............................................................106
Captive Portal Setup......................................................106
Mesh Community Website.............................................108
Other Considerations...................................................................109
6 - Results...................................................................................................115
Cost Analysis...............................................................................116
Technical Feasibility.....................................................................118
Deployment Checklist..................................................................119
Recommendations.......................................................................122
7 - Conclusion.............................................................................................127
Appendix A................................................................................................................ vi
Appendix B.............................................................................................................. ix
References.............................................................................................................. xx
Glossary................................................................................................................. xxii
iv
List Of Figures
List of Figures
Fig. 1. Typical Wireless Mesh Network ...................................................................................1
Fig. 2. Mesh Network utilising Solar Panels ...........................................................................9
Fig. 3. Smartdust .................................................................................................................. 14
Fig. 4. 802.1x authentication ................................................................................................. 16
Fig. 5. Optimized Link State Routing ....................................................................................19
Fig. 6. non-overlapping channels (1, 6, 11) ...........................................................................22
Fig. 7. Uses of Mesh Networking ..........................................................................................21
Fig. 8. Monitoring mesh nodes via a dashboard ...................................................................31
Fig. 9. Network plot of mesh with backbone .........................................................................32
Fig. 10. OLSR Multihopping .................................................................................................. 34
Fig. 11. Linksys WRT54g Hardware .....................................................................................38
Fig. 12. Meraki Mini .............................................................................................................. 39
Fig. 13. Open-mesh OM1P ................................................................................................... 40
Fig. 14. OM1P mesh device connected to LAN port of a standard D-Link Router ................42
Fig. 15. Firetide Outdoor 7020 .............................................................................................. 43
Fig. 16. Meshing with Firetide Hardware ..............................................................................45
Fig. 17. OpenWRT Firmware ................................................................................................ 47
Fig. 18. Upgrading Firmware on WRT54G Device ...............................................................48
Fig. 19. Freifunk Firmware .................................................................................................... 48
Fig. 20. Robin-Mesh Firmware ............................................................................................. 49
Fig. 21. Nightwing Firmware ................................................................................................. 51
Fig. 22. CloudTrax Dashboard .............................................................................................. 54
Fig. 23. OrangeMesh Dashboard .........................................................................................55
Fig. 24. CloudTrax with Google Maps plugin ........................................................................59
Fig. 25. Filtering traffic transparently with Squid/SquidGuard ...............................................60
Fig. 26. Filtering traffic transparently with Squid/SquidGuard on a mesh network ................63
Fig. 27. Using our own DNS server to cache address lookups .............................................69
Fig. 28. Outdoor Enclosure Casing for OM1P ......................................................................70
Fig. 29. Proposed positioning of Mesh APs and GWs in Phase 1 ........................................71
Fig. 30. Paths created by default configuration in Phase 1....................................................72
Fig. 31. In Phase 2 businesses in or near town centre are asked to host gateway nodes.....73
Fig. 32. In Phase 3, businesses with no existing broadband and residents...........................74
Fig. 33. APs off the main town still have multiple paths to the nearest gateway ...................75
Fig. 34. Setting max upload /download via CloudTrax ..........................................................75
Fig. 35. The Drogheda wifi is far from being a mesh, in fact it is 4 separate networks..........85
Fig. 36. Creating a new network on cloudtrax.com................................................................89
Fig. 37. Adding a new node on cloudtrax.com.......................................................................90
Fig. 38. Configuring the Public SSID.....................................................................................91
Fig. 39. Speed test from a mesh AP......................................................................................92
Fig. 40. SSH Session to the DNS Server..............................................................................93
Fig. 41. Installing dnsmasq using the APT Repositiories in Ubuntu.......................................94
Fig. 42. SSH Session to a mesh node...................................................................................96
Fig. 43. Alternate Server configuration on Cloudtrax.............................................................97
Fig. 44. Blocked Page on the mesh network as result of content filtering..............................98
Fig. 45. Private SSID configuration on Cloudtrax................................................................101
Fig. 46. Our own Secure Network Configuration Tool..........................................................102
Fig. 47. Splash Page for the Nice One Network..................................................................107
Fig. 48. Website at http://www.niceonedundalk.net.............................................................108
Fig. 49. Mobile Application (app) to view nearby nodes.......................................................110
Fig. 50. Evolution of the Mesh Potato..................................................................................111
Fig. 51. Using a grid to address where there is no coverage...............................................120
Fig. 52. Node required at grid reference A10.......................................................................121
Fig. 53. Splitting the mesh network into four to ease scalability...........................................123
Fig. 54. Sample QR Code................................................................................................... 131
Fig. 55. Application of a QR Code.......................................................................................132
v
List Of Tables
List of Tables
Table. 1. Nodes = 100, Packet length = 50,000 bytes ..........................................................34
Table. 2. Nodes = 100, Mobility = 30(m/s). ...........................................................................35
Table. 3. Overall performances of protocols .........................................................................35
Table. 4. Results of survey with local business owners.........................................................77
Table. 5. Total cost of deployment........................................................................................117
vi
Introduction
1. Introduction
Wireless mesh networks is a recent emerging technology that realises the dream of
a truly wireless world. Unlike standard wireless modems and routers, a mesh access
point need not be connected to any physical infrastructure whatsoever, and can even
be powered by solar panels when no power outlet exists. This allows for mesh points
to be mounted almost anywhere, spreading wireless networking not just out into your
garden, but down the street and even across your town or city.
Mesh "nodes" are usually configured with specific firmware that allows them to
interact with each other and the larger network using a process known as dynamic
routing. Only one (or a few) nodes need to be physically wired to the network. Those
nodes share their connection with their "wireless" neighbours, so if a node has no
access to the Internet, it passes the request along to the next node, which does a
similar check and so on until a gateway is found.
In my project, I propose to produce a guide on how to implement an urban wifi
(sometimes “WiFi” or “wi-fi”) solution using wireless mesh technologies like those
described above, and investigate the practicality of such a network in a real world
scenario.
Fig. 1. Typical wireless Mesh Network (Jun and Sichitiu, 2008)
A fictional scenario I have created for this project is detailed on the following page.
1
Introduction
1.1. Fictional Scenario
The Dundalk "Nice One Network" is a free community wireless network for shoppers
in Dundalk Town Centre and is an extension of the Nice One Dundalk Campaign.
Anyone with a wireless receiver in their laptop, computer or mobile device can freely
access the network for casual browsing while in the town centre.
Based on mesh technology, the idea is to expand the network as far as possible
across the town by piggy-backing on existing Internet connections at business
locations. The more locations that come on board, the faster and more dynamic the
network becomes.
The network is free because all components are donated by different parties based
on the fact that they weren't using them anyway. Dundalk Institute of Technology, for
example, kindly donated a server and some bandwidth to manage the controller
software for the network, local broadband company Digiweb kindly donated one of
their virtual servers to assist with the filtering of the Internet traffic, and so on.
1.1.1 Phase 1
Phase 1 is sponsored by local authorities, and involves providing network
connectivity to the town centre. When complete, anyone at the centre of town will be
able to connect to the Internet for free, piggy-backing on the main Internet gateway,
with backup DSL connections provided by local authorities. Several 'sponsored'
devices will hopefully also be placed in certain buildings/structures in the vicinity to
spread the load.
This will start the spread of the network down the neighbouring streets that lead to
town centre.
1.1.2 Phase 2
Local businesses with existing broadband connections will be asked to donate some
of their (unused) Internet bandwidth to the mesh and hook on to the connections
created in Phase 1. This will create extra points and help expand the network (as
2
Introduction
well as speed it up!). It's quite simple - all that is required is for the business to install
a small mesh device (a router configured by ourselves using 3 rd party firmware or an
off the shelf mesh AP) for about 50 euro. It plugs into their existing router's LAN port
but keeps their private network firewalled away from the mesh. It's perfectly safe,
and can be switched off at any time.
In return for donating some bandwidth to the project, businesses will be given an
advertisement banner on the portal website, linking to their own business website,
permanently. They can also have the wireless point at their business location redirect
to their own website on login, if they wish.
1.1.3 Phase 3
In Phase 3 small shops without existing Internet connection and anyone living in
town centre will be asked to host a standalone point. These points will hop local
users off to the nearest connected points created in Phase 2 (which is how a mesh
really works!). Where the signals overlap, this is where the network will be at it's
strongest.
These users don't get a sponsor logo on the website or a free email address, but
they DO get a free wireless Internet connection on their premises for a once off fee
of 50 euro. The connection for these Phase 3 units is very limited, so please note
that participating in this manner is by no means a substitute for a business having
their own fast broadband service.
User's from Phase 2 can also use additional standalone units to expand their existing
mesh points and provide coverage in previously uncovered areas. An outdoor casing
is available should anyone wish to install a device in an outside area.
When complete, as well as forming totally free urban wifi network, the mesh will
become a self-healing entity. For example, if a business using eircom broadband
suffers network outage because eircom have a technical issue, users at that point on
the mesh will remain online because traffic will be continuously diverted until a mesh
point is reached that is not connected to eircom eg. a Digiweb or Imagine router.
Alternatively, if a node point on the mesh fails for some reason, traffic will take a
3
Introduction
different route to direct a user to the Internet.
1.2. Researching the Topic
The research studies mostly available on mesh technology and chosen for the
Literature Review in Chapter 2 focused on Deployment Issues in Enterprise Wireless
LANs, particularly those relating to security and the high overhead involved in both
deploying and maintaining such a network.
Several of the source articles came from Computer Communications, The
International Journal for the Computer and Telecommunications Industry, and it
seems to be the main source for publication for experts in this particular field. I also
investigated research by members of the Department of Computer Science, Stony
Brook University, New York and several other academic sources.
The main whitepaper studied was "From Applications to ROI: System Architecture for
Wireless Meshes." by the Farpoint Group, but other papers were also read in some
detail. The main book reviewed, and one I will be referencing throughout this project,
is Hossain, E. and Leung, K, (eds), 2007, 'Wireless Mesh Networks Architectures
and Protocols' New York, Springer. This book has 12 chapters by multiple authors, all
experts in their field, with crucial chapter titles such as 'Channel Assignment
Strategies for Wireless Mesh Networks' and 'Security Issues in Wireless Mesh
Networks'.
Keywords used when searching online databases were wireless, mesh, urban,
deploy, routing, security, issues.
The main things I would hope to achieve from the literature review are as follows:
•
A solid definition of what a wireless mesh network (WMN) is and what
distinguishes it from a mobile adhoc network (MANET)
•
Some of the uses and obvious advantages of wireless mesh networks in the
modern world
•
A list of the various routing protocols used in wireless mesh technology today
and hopefully an ideal candidate for deployment
4
Introduction
•
The types of security issues to consider and how best to protect against them
•
Deployment issues to consider and prepare for in the planned network rollout
For the Technology Review in Chapter 3, I would hope to explore the different
packaged solutions for building a mesh network, as well as make some comparisons
between available hardware devices, firmware for these devices and web-based
dashboard solutions for monitoring and controlling the devices.
I need to also establish the best method for filtering traffic on the network, so a
comparison of proxying versus DNS-based filtering will be necessary.
In Chapter 4 I will detail some interviews with individuals working in the field of
wireless technology, as well as a survey of local business users in an attempt to
gauge how people feel about the overall concept and gather specific data needed
later on.
In Chapter 5 I will begin to document my “howto”, and start to actually build a
functional mesh network. All the various components will be detailed and explained
as I go.
Chapter 6 is a review of the process, with a breakdown of costs encountered and a
description of actual technical feasibility for such a project in the hands of nonprofessionals. This chapter will also include a checklist of what to do and in what
order if building a mesh network, based on my findings. Some basic
recommendations are made prior to making final conclusions.
1.2.1. Me, myself and I
When possible I will try and write using first person narration, but sometimes this rule
needs to be bent for contextual reasons. You will be able to carry out steps in
configurations and sometimes we will see what happens next. This deviation from
the normal point of view is unavoidable sometimes in this kind of paper. I have tried
to use “I” in all places, but there were instances where it just did not feel right. I hope
this does not interfere with the reader's experience.
5
Introduction
1.3. Expected Outcome
The outcome of my investigations will be a blueprint for anyone wishing to build a
public wifi network using existing infrastructure in a scenario similar to the one
described here. The 3 main parts will be cost analysis, technical feasibility and a step
by step guide on how to deploy with detailed milestones and per-requirements for
deployment.
In addition, I have planned to build a small working model of such a network, layered
on top on the DkIT wired infrastructure (simulating the business users) using 3 or 4
mesh access points, for demonstration at the end.
I will provide (at least) basic content filtering for this mesh and demonstrate
deployment configuration via a third party dashboard (either vendor or open source
based, depending on outcome of the Technical Review). I will also be adding at least
2 SSIDs to the network, one secure and one 'open' using Captive Portal or similar –
again, solutions will be determined during the Technical Review. A setup program for
auto configuration of devices with complex security settings for the second SSID* will
be provided.
Finally, I plan to build and demonstrate a website, perhaps a “walled garden” solution
only available to users on the network. This site will be critical for gathering user
feedback, promoting new features on the network, informing users of security issues,
displaying node information etc. I will use PHP and MySQL to build this site,
technologies I am quite familiar with. If time allows, I may add Social Networking
components to the site to show how businesses can use the network for usertargeted marketing and service promotion. As you can see, my project has as many
practical components as it has written. Configuration files and code snips will be
made available as we go.
* service set identifier, a 32-character unique identifier attached to the header of packets
before transmission over a wireless network, ensuring only authorised devices can connect.
Although there are 2 types, the Extended Service Set Identification (ESSID) and the Basic
Service Set Identification (BSSID, used in ad hoc wireless network with no access points),
the ESSID is still referred to as the SSID quite often. Note that these 2 terms will
interchangeable in this project.
6
Literature Review
2. Literature Review
2.1. Defining Wireless Mesh Networks (WMNs)
Wireless Mesh Networks (WMN for short) are a good example of the common
phrase “necessity is the mother of invention”, which can be taken to mean “difficult
problems usually give rise to ingenious solutions”.
Vasseur and Dunkels (2010) state that in 1900 only 13 per cent of the world
population actually lived in urban areas. By the middle of this century that number is
expected to be more like 70 per cent, and remember that the world population is also
increasing constantly (our 7 billionth inhabitant was recently announced). At this rate
of expansion, and with public spending getting lower and lower, how can current
infrastructure support such a high population, who with each generation get more
and more “connected” and more reliant on Internet services and IT in general?
They go on to point out that the integration of information technology with
development projects can change the urban landscape, resulting in so called “smart
cities” encouraging businesses to invest and promoting sustainability.
This idea that wireless connectivity “on tap” will help promote business has appealed
to me from the start, and if you think about it, it makes sense. The idea gets even
more appealing if you consider wireless technology that is itself smart and capable of
“self-healing”.
Also, smart cities could take advantage of mesh technology in many other ways than
general Internet use for the residents, and I'll get to that in while.
So what constitutes a mesh network exactly? Moskaluk (2010) states that a wireless
mesh network is made up of three or more wireless access points, all working in
harmony with each other to create an interconnected electronic pathway for the
transmission of data between computers. It is useful to know that 3 points or more
qualifies as a wireless mesh, and I will use this assumption when it comes to the
testing phase later.
7
Literature Review
A WMN however must also contain mesh routers, where the mesh routers* form a
wireless backbone and interwork with the wired networks to provide multihop
wireless Internet connectivity to the mesh clients (Hossain and Leung, 2007). Note,
the mesh client is not the end user - the mesh APs themselves are the clients in the
network.
The mesh clients (or “nodes” or sometimes APs) are small devices with built in radio
transmitters. They generally require power either directly from a power source or
using Power Over Ethernet (POE) technology. The requirement for power does
somewhat limit where the nodes are placed, but using mesh technology frees us up
to put them anywhere power exists (eg. mounted on a street light) and not have to
worry about network connectivity. The node will simply hop the user traffic to the next
node and so on until the traffic reaches one of the backbone routers (or gateways).
Other variations on the definition of a WMN include:
“A WMN typically consists of a set of static mesh routers that use multi-hop
transmissions to form a backbone network for facilitating communications between
mesh clients”. (Pal and Nasipuri, 2011)
and
“In its general form, a WMN is a set of wireless nodes that can communicate with
each other, forwarding each others packets. Like in MANETs, each node is both a
host and a wireless router. ” (Jun and Sichitiu, 2008)
* Routers in this case means Layer 2 routing, as opposed to Layer 3 routing. Layer 2
networks forward all traffic, including ARP and DHCP broadcasts. Anything transmitted by
one device is forwarded to all devices. By contrast, layer 3 devices restrict broadcast traffic
such as ARP and DHCP broadcasts to the local network. Layer 2 routing is therefore better
for mesh networks.
8
Literature Review
So far so good – the accepted definition for what a WMN actually is matches up with
what I thought it was quite well. Several of the sources have mentioned MANETs
also, so best to clarify at this point what those are and how they differ from WMNs. I
should also note similarities and shared technologies.
MANETs are a kind of wireless ad hoc (also written “adhoc” or sometimes “ad-hoc”)
network that usually has a routeable networking environment on top of a Link Layer
ad hoc network. Referring back to Jun and Sichitiu (2008) and their work on
proposing a new routing protocol for mesh networks, they explain that WMNs are
actually an implementation of MANET (mobile ad hoc networks) rather than an
alternative to it. What differentiates WMNs, they explain, is that all traffic either
originates or terminates at the gateway. Also, in WMNs, nodes are neatly classified
as either stationary (providing connectivity and coverage) OR they are mobile (using
the coverage provided by the stationary nodes).
It is assumed that in MANETs nodes can be can be in both states at the same time –
they have 'homogeneous mobility characteristics'. Lastly, in WMNs, traffic flows
between the clients and the Internet. In MANETs, it is more likely that any particular
node is the source or destination of the traffic.
WMNs are also not to be confused with WDS (Wireless Distribution Systems). WDS
is a system that allows for the interconnection of multiple 802.11 access points over
a wireless network. WDS is a simple point to point link. It normally will have
everything on one channel, and very indeterminate behaviour (particularly if your
network is cross-connected, resulting in network loops which will cause all kinds of
issues). The general rule of thumb is if you are intending to provide coverage to a
single building then use WDS. If it's for a neighbourhood or urban area network, then
use meshing.
It might be worth noting also the similarities between wireless networks and mobile
phone networks. “A base station in the cellular networks corresponds to an access
point in the wireless LANs, and a mobile phone in cellular networks corresponds to a
client device in wireless LANs. Several of the deployment problems have been
extensively studied in the context of cellular networks. ” (Chiueh, 2003). It would not
be a huge leap to assume that solutions applied to mobile phone coverage in urban
9
Literature Review
areas could be applied to WMNs.
I have also confirmed that WMNs are self-configuring, self-organising and selfhealing (Muogilim et al, 2011) They are also incredibly scalable, flexible and cheap
to deploy (more on these advantages later).
So the Literature Review has given us a clear definition of what a wireless mesh
network actually is. I will now investigate if the accepted advantages of such
technology are similar to those speculated upon in the introductory chapter.
2.2. Advantages of WMNs
The Farpoint whitepaper reviewed (From Applications to ROI: System Architecture
for Wireless Meshes, 2007) claims than urban wireless networks (or "metro-scale"
wifi as they call it) have 3 key advantages, namely:
•
Architectural Flexibility
•
Application Support
•
Total Cost of Ownership (TCO)
The TCO mentioned is interesting, and can be evaluated with variables like the the
number and cost of the mesh nodes, number and capacity of wired backhaul links
(originally designed to carry only voice traffic but now having to cater for high
bandwidth) and non-recurring installation costs. This warrants further investigation
and when I come to costs of deployment later I will probably need to revisit this
material in detail.
However, surely there are more obvious advantage to this technology? Referring
back to the Wireless Mesh book I read:
Different from traditional wireless networks, WMN is dynamically self-organized and selfconfigured. In other words, the nodes in the mesh network automatically establish and
maintain network connectivity. This feature brings many advantages for the end-users,
such as low up-front cost, easy network maintenance, robustness, and reliable service
coverage. In addition, with the use of advanced radio technologies, e.g., multiple radio
10
Literature Review
interfaces and smart antennas, network capacity in WMNs is increased significantly.
Moreover, the gateway and bridge functionalities in mesh routers enable the integration
of wireless mesh networks with various existing wireless networks, such as wireless
sensor networks, wireless-fidelity (Wi-Fi), and WiMAX. Consequently, through an
integrated wireless mesh network, the end-users can take the advantage of multiple
wireless networks. (Gungor et al. 2007)
Jun and Sichitiu (2008) list the main advantages of WMNs (in comparison with
traditional network technologies) as dramatically cheaper to fund and deploy, as well
as the 'market coverage' (especially in and around parks, high buildings, any kind of
obstruction really). They also make reference to reliability and provision for mobile
user access.
The literature review I carried out uncovered a fairly concise list of advantages of
wireless mesh networks. The main ones are, in no particular order of importance:
1. Cost – reduced cabling can drastically reduce deployment costs for the network
2. In stark contrast to regular wireless networks, in WMNs the more nodes you rollout,
the bigger, faster and more reliable your network becomes
3. WMNs rely on the same standards (802.11a/b/g) already in place
4. Convenience – mesh networks can be easily deployed where Ethernet wall sockets
already exist
5. They do not depend on 'Line Of Sight'. Mesh networks will always adjust and try to
find a clear path
6. WMNs are self-configuring – new nodes are automatically incorporated without the
need for configuration (“zero conf”)
7. WMNs are self healing – the network always finds and uses the most reliable path
8. Mesh networks are fairly easy to install and even easier to expand as required
It's also worth noting that Vasseur and Dunkel (2010) went so far as to say that mesh
networks will dramatically improve the quality of life itself in the local population, and
this, if true, is a very important advantage indeed. It is also one that this researcher
whole-heartedly agrees with and believes in.
The biggest advantage of all has got to be that wireless mesh networks are TRULY
wireless (How Wireless Mesh Networks Work, 2007). Most traditional wireless APs,
11
Literature Review
even the expensive kit found in Dundalk Institute of Technology, still needs to be
connected to a physical network via Ethernet cable. This usually means running and
terminating cables, configuring switches etc. Mesh APs can be put anywhere as long
as there is power, and some of them can even function with the use of solar or wind
power (Sayegh et al, 2007)
Fig. 2. Mesh Network utilising Solar Panels (http://www.jessan.com/)
2.3. Uses of WMNs
The Farpoint Group (2007) firmly believe that mesh nodes are not just becoming
fixtures but an expectation on a global scale. Wireless mesh networks, in their most
basic form, can provide infrastructure and testing environments for research and
education, public sector infrastructure and outdoor wireless access for the general
population.
“Typical applications are, broadband home network, enterprise network, community
network, metropolitan area network, intelligent transportation network, Industrial
automation network, sensor network, and emergency or rescue networks.”
(Kandikattu and Jacob, 2008).
12
Literature Review
These are very general uses, so perhaps some real world examples would make the
applications of WMN make a lot more sense.
Real world examples come from exploring website of actual WMN projects, as well
as dissecting the generic scenarios presented in some of the literature and applying
it on a local level.
For Dundalk, I would list the following application for a mesh network:
•
Shoppers and visitors to Dundalk could check their email, social media and get
tourist information on the move
•
Local authorities could monitor the diagnostics of the town's power and water supply
by installing nodes in sewerage facilities, generator stations etc. No need to dig up
roads or run cabling
•
DkIT could broadcast the eduroam SSID (an idea that really caught HEAnet's interest
when I suggested it) around town, so students and others (eg. visiting academics)
could access not just DkIT services but services at their own home institute right from
the centre of town
Mesh can of course be used not just in towns, but in faraway, less developed places
where there is no infrastructure, not even telephones or electricity. Solar powered
nodes like those described by Sayegh et al (2007) would be used in these instances.
Then comes the stuff of science fiction – things like “smartdust”, autonomous
sensing and communication in cubic millimetre units developed and funded by
DARPA due to the potential military applications of mesh-based technology
(Smartdust, 2010).
Imagine scattering this stuff over a battlefield and have it deliver important strategic
data back to high command before sending in troops. The enemy ignore it because,
well, it's just “dust”.
Companies have been developing low power solutions for smartdust with in-field
operations times in excess of one and a half years. They have achieved such low
power consumption by combining smart and efficient power management techniques
13
Literature Review
with communication methods that impose minimum requirements on bandwidth.
Fig. 3. Smartdust (http://robotics.eecs.berkeley.edu)
Now imagine scattering smartdust over urban areas to achieve 100% wifi coverage.
All possible in the foreseeable future.
2.4. Security Concerns
No network is without security issues, and wireless networks even more so as actual
“physical access” in not required. All a potential attacker needs is a wireless device
(which is pretty much anything these days) some custom software and the knowhow.
For this reason, an important part of the literature review is to uncover the potential
security risks with wireless mesh technology.
According to Zhang et al (2007), for any application (not necessarily on WMNs), the
following general goals are desired to ensure security.
1. Confidentiality or Privacy: The communication between users must be secure
2. Integrity: The paths must be protected to ensure the messages are not altered
3. Availability: Applications should provide reliable delivery of messages
4. Authentication: There should be some processes to identify the user to prevent
fabrication
5. Authorisation: There should be mechanism to ensure users have the correct
14
Literature Review
permissions
6. Accounting: Some process should be able to measure the resources the user
consumes
The shared nature of wireless, the absence of a globally trusted central controller,
and the lack of any physical protection of mesh routers pose the main challenges for
securing a WMN.
Kandikattu and Jacob (2008) are convinced that without some pre-established
security associations, especially over wireless and dynamic connections, building
low-cost secure network is still a challenge, and will be for some time. Some of the
immediately obvious security issue with mesh technology are worms and viruses (as
all devices belong to different users and no form of Network Access Control is used)
and nodes being compromised by unverified router information and network status
messages. A not so obvious security concern is actual physical damage, accidentally
or through an act of vandalism.
Further reading, particularly the work of Muogilim et al (2011) reveals a multitude of
security concerns, almost enough to put you off building a WMN at all! They range
from the common Denial of Service attack (DoS) and the even worse Distributed
Denial of Service attack (DDoS) to signal jamming (an attacker jams the interface of
a transmitting or routing node on the physical channel) to forging, where the attacker
forges network notification messages and broadcasts incorrect notification about the
network status.
Some of the techniques discussed are just plain nasty, but also quite ingenious and
not to be ignored. Here is a list of other types of attack not mentioned already:
•
Batter exhaustion attacks
•
Wormhole attacks
•
Blackhole attacks
•
Location Disclosure attacks
•
False message attacks
•
Rushing attacks
•
Resource depletion attacks
15
•
DNS Spoofing
•
Route cache and Table Overflow
Literature Review
and there are probably more.
While the security of WMNs is a fairly new research topic, there are still very obvious
ways to secure at least the user session. 802.1x authentication is a good candidate,
where the network is secured using EAP/PEAP encryption with MSCHAPv2 and
Radius Authentication. Server side certificates prevent rogue APs pretending to be
gateways, resulting in a very secure network where the user does not need any extra
software or even a copy of the certificate installed.
Fig. 4. 802.1x authentication
However, the downside of this is that your radius server usually points at a directory
system (Active Directory, eDirectory or maybe OpenLDAP), but in an urban wifi
network, advertising free public access, how do we know who our users actually
are? How do we issue them with passwords and ensure their laptop is configured
correctly for WPA2 (not so easy on Windows, but I have recently researched this and
I will present solutions later on in the project) and 802.1x?
16
Literature Review
A proper urban mesh should have 2 SSIDs really, one for public access secured by a
Captive Portal solution (not so secure, but the user will be made aware of this) and
one for use by public officials and emergency services, secured using WPA or
WPA2. All other security will need to be handled behind the scenes, using firewall
scripts on the nodes themselves and inside the actual routing protocols chosen for
the WMN.
So a list of all security measures to investigate during such a project would look like
the following:
•
Authentication
•
Cryptography and Encryption
•
Firewall (either hardware of software)
•
WPA or WPA2
•
AES (not TKIP, it's no longer considered secure)
•
Intrusion Detection
•
Access Lists
•
Mesh Security Management Software
I have also concluded that a secure MAC layer would be a really good idea as it
would ensure that all traffic from the mesh network is authorised, and that perhaps, if
possible, a traffic engineered multi-protocol solution would safeguard against all the
issues listed.
2.5. Routing Protocols
Zhang et al (2007) claim that in WMNs, the data travels via multiple wireless hops
from the source node to its destination. The routing protocols for WMNs are
designed to achieve 3 main functions:
1. Self-configuration of the routing tables.
2. Self-adaptation to changes in the wireless link quality.
3. Maximised performance metrics such as end-to-end delay, throughput and packet
loss rate.
17
Literature Review
The routing protocols for wireless ad hoc networks have very similar requirements
such as routing through wireless multihop links, self-configuration and selfadaptation. Without proper protection, the routing mechanisms on a WMN could be
attacked by either external or internal attackers (like those listed earlier), so choice of
routing protocol plays a part in security as well all the above listed functions. Also,
routing protocols have to be designed with security in mind, not just quality and
delivery of service.
OLSR, An ad hoc wireless mesh routing daemon and probably the most commonly
used, is based on the Inria (the National Institute for Research in Computer Science
and Control in France) implementation, and it is an optimised link-state, table-driven
protocol originally designed for MANETs. It is a proactive link-state routing protocol,
using HELLO and topology control messages to discover link state information on
the network. Individual nodes use this topology information to calculate next hop
destinations for all nodes in the network using shortest hop forwarding paths. OLSR
is a good candidate for wireless mesh networks for the following reasons:
1. Routes to all destinations within the network are available within the standard routing
table
2. The routing overhead generated does not increase with the number of routes
3. Default and network routes can be injected into the system allowing for connection to
the Internet or other networks
4. Timeout values and validity information is contained within the messages conveying
information allowing for differing timer values to be used at differing nodes
However, the original definition of OLSR does not include any provisions for sensing
of link quality and assumes that a link is up if a certain number of HELLO packets
have been received. This is no good.
Enter the B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking) routing
protocol (http://www.open-mesh.org), under development several years now and
intended to replace OLSR. A version of B.A.T.M.A.N. is also implemented in RobinMesh, a popular, easy-to-use open source firmware for small, widely available
routers such as the Linksys WRT54G series and the Open-Mesh OM1P (more later).
18
Literature Review
This researcher has had experience with several flavours of Robin in the past,
particularly as the previous version of the DkIT wireless network was built using
WRT54GL routers, and we looked into implementing mesh using the Robin-based
Freifunk firmware at one point. I also must confess to having played with the OpenMesh OM1P devices in preparation for this project.
So let's say I like OLSR, and to be more specific, it's intended successor
B.A.T.M.A.N. (disregard Robin for the moment). Does this protocol tick the boxes for
the 3 functions specified earlier? Remember, the ideal candidate must be selfconfiguring, self-adapting and maximise all available performance metrics while
retaining a decent level of security.
Koksal (2008) shows how to define a relay-quality aware routing as an extension of
OLSR easily, partly due to it's proactive routing scheme. He conforms that OLSR
involves regular exchange of topology information among network nodes and
employs designated nodes called Multi Point Relays (MPRs) to facilitate controlled
flooding of topology information. He then suggests that MPRs are also the sole
constituent nodes in the route between any source-destination pair in the network.
Fig. 5. Optimized Link State Routing
A Neighbour Table at each node stores the information about the one-hop
neighbours. Upon receiving a HELLO message, a node creates or updates the
neighbour entry corresponding to the node which sent the message. This is an
example of self-configuration.
The routing table is evaluated based on the connectivity information in the neighbour
table and topology table. Shortest path algorithm is employed for route calculation
19
Literature Review
and each resulting route consists of the destination entry, the next node up and
number of hops to the final destination. This seems like a good example of selfadapting.
Finally, according to Koksal, based on the information obtained from the HELLO
message, each node in the network can selects a set of nodes amongst its
symmetrically-linked neighbours, helping to control the flooding of broadcast
messages. This set of nodes is the Multi Point Relay set. The neighbours of the node
which are not in its MPR set, receive and process broadcast messages from the
node, but do not retransmit them. The MPR set is selected such that it covers all the
nodes that are two hops away. This demonstrates sufficient maximisation of
performance metrics, in my opinion.
Also, it's worth pointing out that OLSR's derivative B.A.T.M.A.N. improves on this yet
again by completely replacing the OLSR pro-active routing (requires every node in
the network to calculate the whole routing path). B.A.T.M.A.N. nodes compute the
next hop ONLY.
To wrap it all up and settle on an OLSR-based protocol (and therefore B.A.T.M.A.N
or some implementation of Robin) as the ideal candidate for the WMN, I need to just
check some facts on it's regard for network security.
OLSR is actually highly vulnerable to attacks directed at availability, DoS attacks for
example. An attacker could launch OLSR packets containing false information in
large amounts. This could lead to a situation where processing of this data could
claim all resources on the receiving nodes, leaving them not able to handle any other
tasks. Eventually the OLSR service could crash leaving the node not available.
Andreas Hafslund et al (2004) suggested an extension to OLSR that uses
timestamps. This is great, as it allows us to positively identify delayed messages thus
preventing nodes from repeating old (and correctly authenticated) information. The
work of Andreas Hafslund would be referenced frequently over the next decade by
those studying 'Trusted Routing' in OLSR MANETs, and would be the basis for the
B.A.T.M.A.N. project.
20
Literature Review
Yet another project, the wonderfully named (and very recent) BatCave, extend the
B.A.T.M.A.N. routing protocol so routing advertisements are only accepted from
authorised stations in the network. They propose using either pre-configured or
short-lived certificates to identify and verify clients - useful if say, you wanted to
secure your network for emergency services use only.
I feel it is now safe to say that OLSR or a derivative is a good protocol choice for my
deployment and should be fully investigated in the Technical Review (next chapter).
However, I should point out here that security is really NOT the job of the routing
protocol. Sure, the protocol of choice should be secure, but this is NOT the same
thing. Proper wireless security like described in Section 2.4 is still required.
2.6. Deployment Issues
Finally, I would like to uncover the common deployment issues, the 'caveats' that I
will need to consider when deploying the network. Although a popular and much
discussed idea, in the bigger picture enterprise level deployments of WMNs are fairly
limited, if not non-existent if you look at Ireland.
Raniwala and Chiueh (2003) attribute the initial slow uptake to the fact that the
original implementation of 802.11 failed to fulfil the promise of pervasive connectivity
and mobility. Their studies however concentrate not on the WHY but the on the
WHERE and the HOW – where to place access points and how to configure their
various parameters.
It's hard to balance the WHERE part, and this is where many deployments fail.
Placing too many nodes not only has a major effect on your budgets costs but
technically can lead to unwanted interference. Also, many projects fail to consider
another big part of the urban landscape, the human traffic element. Kim et al (2009)
give an example of how on a congested street nodes cannot travel at their desired
speed. Furthermore, the location of streets, hallways, etc. restricts the position of
nodes, and traffic lights impact the flow of nodes. Finally, people do not wander the
simulated region at random, rather, their mobility depends on whether the person is
at work, at lunch, etc. There's an awful lot of variables there and some very complex
21
Literature Review
study to be done to get it right.
The second big problem is what is known as the 'overlapping channel problem',
something I have had personal experience with. How do we know which channel to
use for which node? And how to avoid overlaps?
To effectively assign node channels, proper planning of nodes location is required.
It's important to have enough access points to provide adequate signal coverage
throughout the area, but we also need to make sure that access points are far
enough apart so that you'll be able to assign non-overlapping channels (eg. channels
1, 6, and 11) to nodes that are within range of each other. As a result, it's considered
crucial to perform an RF (radio frequency) site survey before assigning access point
channels.
Fig. 6. non-overlapping channels (1, 6, 11). In reality, there are actually 5 channels that can
be used with minimal issues due to overlap - 1,4,8,11,13
Altogether I have identified 6 key issues when deploying a wireless mesh network:
1. AP Placement - the primary goal is coverage. The placement of nodes is a governing
factor, with high user density areas requiring more coverage than others.
2. AP Configuration - several parameters need to be set to ensure optimal performance.
The overlapping channel problem form earlier needs to be carefully considered.
3. Physical RF Site Survey - a painstaking but necessary step if you are building a
network from scratch. Raniwala and Chiueh (2003) define a site survey as measuring
22
Literature Review
network performance at various locations and finding coverage and performance
issues.
4. Security Provision - often cited as the main reason for failure on large scale
deployments. These concerns can be overcome if using modern standards like
802.1x rather than older compromised security methods. Also, see the previous
section on choice of routing protocols.
5. Mobility Support - this is concerned with the ability to keep a session live while the
user moves about the network. Mobility needs to be supported at 2 distinct levels, the
link layer and IP layer. 802.11 supports link layer mobility by switching users over to
newer access points, but for mobility across subnets we need to be more careful.
6. Quality of Service (QoS) - the age old problem. We need to ensure that one user
FTPing a large file or streaming media does not hog the bandwidth for everyone else.
I have also identified 6 key steps to a deployment plan. Note that these steps do not
necessarily align with the 6 issues identified earlier (but some do).
•
Designating Coverage Areas
•
Capacity Planning
•
Coverage Planning
•
Preliminary AP Positioning
•
Channel Allocation
•
Physical RF Site Survey
All literature reviews in the area of WMN deployment can very quickly descended
into incredibly mathematical and scientific jargon, language way beyond the
understanding of this researcher. I obviously am not an outstanding mathematics
student, so for the most part I will be steering clear of mathematics and scientific
notation in the main project. It is suffice to say that most of this work will be taken
care of for me either by the chosen routing protocols, the firmware implementing the
protocol and any third party, GUI-based tools I may use for planning and monitoring
out network.
Remember, the deployment as described in 1.1.1 – 1.1.3 is a very different twist on
23
Literature Review
the regular WMN deployment. The underlying infrastructure is already in place in the
form of the various businesses that will participate and their existing broadband
connections. The site survey will involve mostly deciding which of these locations
would make the best gateways. The network engineers are not really going to be in
position to move nodes around to their pleasing, or else the plan falls apart.
However, even though I cannot fully control AP Positioning, I am very much in control
of AP Configuration as I intend to add my own devices into the mix, and leave the
business routers untouched. I can also do my best to cater for mobility, security and
QoS, with careful planning.
2.7. Conclusions
This Literature Review has uncovered some important new information and
confirmed some facts I already suspected. It has helped to make several design
decisions ahead of the next phase, namely:
2.7.1 General Design Decisions
Each of the mesh points must meet the following requirements:
•
It must be low cost and affordable
•
It must be robust
•
It must not require any configuration and be installable business owners or
residents with no training
•
It must be manageable by non-trained business owners and remotely
accessible if necessary
•
It must provide a connectible signal indoors without additional equipment
•
It must be able to let people know when there is a problem (such as being
unplugged)
24
Literature Review
2.7.2. Routing Protocol
The routing protocol of choice will likely be OLSR or an OLSR-based protocol like
B.A.T.M.A.N. In version 3 of B.A.T.M.A.N., a computer or router running that protocol
can be deployed on a central point, like a church or another high building, and have
several wired or wireless network interfaces attached to it. When so deployed,
B.A.T.M.A.N. can relay network data in more than one direction without any
retransmission delay. Announcing devices not running B.A.T.M.A.N. themselves has
also been included in this version, which is useful. For this reason, further
investigation into the advantages and disadvantages of both protocols is required.
It is likely the functionality of whatever the chosen routing protocol is will be hidden
below the choice of firmware and network management console (dashboard).
2.7.3. Hardware
B.A.T.M.A.N. (and OLSR for that matter) can be deployed in many forms on many
devices, including the Open-Mesh project 'open hardware' devices OM1P or OM2P
(802.1n compatible). It can also be used on WRT54 series routers from Cisco (they
have 4mb of RAM and are powered by a Linux kernel which can be replaced).
One of these 2 devices or something similar will be used, depending on the outcome
of the Technology Review later.
3.7.4. Security
No matter which hardware is decided on, wireless security is required, with a tradeoff between ease of use and protection to be considered. Ideally, I might use a
captive portal based solution for casual users (e.g. Dundalk Shoppers) on one SSID,
and perhaps a secure WPA or WPA2 (AES) encrypted SSID, non-broadcasting, for
public workers to access when required.
Something not brought up anywhere in the literature review is how to filter the traffic
on the network. Sure, this is not high priority for functionality, but if you review the
25
Literature Review
proposed scenario, it would be incredibly bad for there to be free, easy to access
pornographic material accessible to thousands of school children in town centre at
lunchtime every day. It would be worse again if the network providing the
questionable content is to be part funded by local business owners, part funded by
local authorities. Imagine the headlines! I should look into a solution later using a
Squid based proxy server with transparent redirects (perhaps using iptables) or else
investigate DNS filtering solutions that I could implement myself.
2.7.5. Dashboards & Device Firmware
Of course, the 2 main pieces of software is the firmware on the nodes themselves
and the software to control/monitor the nodes.
Firmware options include:
•
Freifunk
•
Robin
•
Nightwing (another Batman character!)
Although I have a preference for Robin, and some experience with it and Freifunk,
Nightwing is completely new to me. It promises both Captive Portal and WPA2
security, DNS filtering using OpenDNS servers, and improved security. I will have to
have a closer look at this firmware and make comparisons between it, Robin and
other contenders in detail if at all possible.
Dashboards, the web-based control panel for managing the network, come in even
more variations. The major contenders are:
•
CloudTrax
•
OrangeMesh
•
J.O.K.E.R. (keeping with the Batman theme)
•
Robin-Dash
Some of these projects are unmaintained, others are practically dead but their
26
Literature Review
source is still available via CVS. CloudTrax is the official dashboard of the OpenMesh project, and is based on Robin-Mesh. It obviously will work quite well with the
Robin firmware. Orangemesh is a good alterative to CloudTrax, and is completely
open source, allowing to users make any changes they want as required. J.O.K.E.R.
(JOomla KEeper for Robin) is interesting as I will likely use the Joomla CMS for the
customer web portal. It claims support for 802.1x and use of your own Radius server.
This concludes the Literature Review. I have accomplished the following to date:
1. Defined Wireless Mesh Networks and touched on MANETs and WDS
2. Listed the advantages of WMNs and applied them to my scenario
3. Listed the uses of WMNs and suggested some extra ones
4. Raised some security concerns and made recommendations
5. Discussed Routing Protocols and introduced B.A.T.M.A.N. the Better
Approach To Mobile Adhoc Networking
6. Discussed some possible deployment issues, including overlapping channels
7. Concluded the Literature Review and listed some possible candidates for
Technical Review based on the previous steps
27
Technology Review
3. Technology Review
3.1. Overview
As already discussed, mesh networks are the next big thing for providing wireless
Internet coverage to hard to reach areas such as town centres and country villages.
They can be used for casual Internet access (public users, tourists), local authorities
(emergency use, maintenance) or a combination of both.
Fig. 7. Uses of Mesh Networking (http://www.firetide.com/)
Meshes work by using the hardware nodes themselves to relay data packet on to
other nodes in the mesh. The nodes can be powered by small adapters, over
Ethernet using POE (Power Over Ethernet) or from an external source such as wind
or solar power. Nodes may also be stationary (attached to buildings or streetlights) or
mobile (on a train or bus). These types are represented in the above diagram.
28
Technology Review
Namely, the types are:
1. Node mounted on streetlight in outdoor area with no buildings in vicinity.
Likely powered by solar panel.
2. Node mounted on top of building. AC adapter or POE power recommended,
depending on eight of pole.
3. Node hosted inside moving vehicle. Likely using vehicles internal electrics or
a battery source.
4. Node hosted inside a building. Use AC adapter.
Algorithms (managed by the protocol) keep track of the mesh's configuration as it
changes, and determine how to route packets from node to node. The big advantage
here is that a mesh can form one, single LAN way beyond the normal range of
wireless Ethernet. It also acts as it's own backhaul*, because as long as one node
has access to the Internet, ALL nodes have access.
With a mesh network covering your town centre, there is no need to run fixed
Ethernet around or have a wireless AP attached to a building. Imagine the red dotted
lines, representing wireless traffic in the previous diagram (Fig. 7), were actually
category 5 Ethernet cable. That would not be very practical at all, would it? In fact, if
you factor in the moving vehicles, it would be impossible.
In a mesh, you simply configure one (or more) access points as a gateway, and the
rest can share that connection over the wireless on to the Internet. Configuration and
monitoring of nodes is done via your mesh dashboard.
This solution is ideal for providing broadband to a large, outdoor area.
* The backhaul portion of a network is the intermediate links between the core network and
the small subnetworks at the "edge" of the entire hierarchical network. In a wireless
environment, backhaul can also refer to the transmission of network data over an alternative
wireless route when the normal route is unavailable.
29
Technology Review
My idea involves finding a low cost solution to providing wireless broadband in the
town centre. The network should not belong to any one body, it should be a
community network made up of units bought by different businesses with backhaul
services provided by local authorities and other services donated by larger business
and maybe the local college. I have already investigated the feasibility of the
scenario, and it is very possible. What needs to be solved though is the technological
aspects – the perfect hardware and software solutions with the right trade-off
between cost and reliability/maintainability.
In this chapter I will review open source alternatives to the following required
components of the mesh network:
•
Hardware – available models, unique features, cost?
•
Firmware – what is available, feature comparison, is the project maintained?
What is the protocol used?
•
Dashboard - ease of use, features, compatibility
I will also investigate an all-in vendor based solution (namely Firetide) as in order to
stay objective all alternatives should be investigated.
Should we choose a 3rd party dashboard for monitoring and configuration of the
network, Dundalk IT has offered to host a server for this within their DMZ, with a
publicaly accessible IP address to use in the network configuration.
30
Technology Review
Fig. 8. Monitoring mesh nodes via a dashboard (http://www.gi-link.com)
Finally, with content filtering being considered from the start, I will compare DNS
Based Filtering with a HTTP Proxy solution to determine which is the best solution
and which will integrate easily with the final project. Local broadband provider
Digiweb have kindly donated a business class Linux server for me to host the final
solution on if the project were to be realised, so I will actually implement the chosen
solution and demonstrate it at the end of the project as if this were the case.
31
Technology Review
3.1.1. Networking Principles of a WMN
Building on the discoveries in the previous Literature Review, it is important to note
the following for the Technology Review from Johnson et al (2007):
•
Communication between mesh nodes are based on Wi-Fi radios (IEEE
802.11 a/b/g) attached to directional or omni-directional antennas.
•
Each node in the WMN should have the same ESSID (name) and BSSID
(number) - the BSSID should be fixed to prevent partitioning of the wireless
network.
•
In an ideal WMN, each node should be able to “see” at least two other nodes
in the WMN. This allows full fail-over in case any node goes out of
commission (e.g. due to a hardware failure or power failure).
Fig. 9. Network plot of mesh with backbone
32
•
Technology Review
No non-mesh wireless device connects directly to a wireless mesh node
(mesh nodes provide a wireless back-bone). This infrastructure is considered
critical infrastructure and should be managed for the highest availability as
the rest of the network depends on the availability of each node.
•
All nodes in the WMN will operate on the same channel (frequency).
•
All radios should be set to ad-hoc mode (not client mode or AP mode).
•
Each IP address in the mesh network should be unique to allow any
computer in the network to connect to any other computer in the network.
•
One or more mesh nodes may be connected to a specially prepared node
linking into a distant network. This node may also be a mesh node, but will
not be configured the same as the local mesh nodes.
•
A mesh routing protocol (OLSR maybe?) will route IP traffic between the
wireless interfaces of the mesh nodes. The protocol learns the potential
routes by listening to the routing information exchanged in the network and
maintains routing tables dynamically. This feature provides routing faulttolerance by providing an alternative route when a node fails, if one is
available.
3.1.2. OLSR - Our Protocol Of Choice?
While I still need to decide on specific hardware, firmware and a dashboard for the
mesh network, the choice of Routing Protocol was indicated during the Literature
Review. It is very obvious at this point that OLSR (Optimized Link State Routing
Protocol) is by far the best choice and any hardware or firmware we choose must
support this or one of it's forked projects. I already justified this decision in the
Literature Review, but here's a recap of the technology and a more detailed
breakdown for this chapter's purpose.
OLSR is a routing protocol optimised for mobile ad-hoc networks and mesh networks
33
Technology Review
such as the one proposed by this project. OLSR is essentially a proactive link-state
routing protocol, using HELLO and topology control messages to discover and
extract link state information on the network. Each node can use this topology
information to calculate next hop destinations for all nodes in the network.
Fig. 10. OLSR Multihopping (http://tldp.org)
Host and network association (HNA) messages are used by OLSR to disseminate
network route advertisements in the same way TC (topology control) messages
advertise host routes.
OLSR is highly scalable. It has been known to run on community wireless mesh
networks with 2000+ nodes with no degradation in performance. Table 1 and Table 2
give a summary on performances of the 2 most popular routing protocols (OLSR and
it's derivative B.A.T.M.A.N.) in which "1" denotes the best performance and "3"
denotes the worst performance.
Parameter
Packet Delivery
End to End Delay
Routing Load
Throughput
Ratio (PDR)
Protocol
BATMAN
2
3
3
3
OLSR
1
1
1
2
Table. 1. Nodes = 100, Packet length = 50,000 bytes (http://www.ijetae.com )
34
Parameter
Packet Delivery
Technology Review
End to End Delay
Routi g Load
Thro ughput
Ratio (PDR)
Protocol
BATMAN
2
2
3
2
OLSR
1
1
2
1
Table. 2. Nodes = 100, Mobility = 30(m/s) (http://www.ijetae.com)
According to Sandhu and Sharma (2012), OLSR performs best because OLSR has
shorter delay. B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking) would
seem to have better performance when mobility increases, but still a lot less than
OLSR itself.
Maximum number of nodes with Maximum Packet length.
OLSR > BATMAN
Maximum number of nodes with Maximum Mobility.
OLSR > BATMAN
Table. 3. Overall performances of protocols
Since OLSR is on layer 3, it is also highly portable. However, does this not
contradict what was said at the start of the Literature Review chapter about Layer 2
routing being better for mesh networks?
In reality, most wireless mesh devices offer a Layer 2/Layer 3 hybrid implementation,
which highlights the positives from both technologies and does away with the
shortcomings, such as Layer 2′s lack of scalability and Layer 3′s latency.
Take for example Firetide’s mesh technology. Their hardware (which we will review
shortly) looks like a Layer 2 switch to the outside world. But internally it uses a Layer
3 approach to deliver the packets from an injection point of the mesh to an exit point.
This hybrid approach makes the wireless network more scalable as well as greatly
enhances its performance.
I also hinted in the last chapter that OLSR alone might not be enough for a mesh
network due to it's susceptibility to DoS attacks, and that the more 'trusted' routing
protocol B.A.T.M.A.N. would be a smarter choice. But is one really better than the
35
Technology Review
other? After much research on the subject, I no longer think so. Let me explain.
Until recently, differences between B.A.T.M.A.N. and OLSR were seriously tainted by
significant hardware differences that would cast doubt into any results. The theory on
why OLSR may perform better (see previous tables) and, surprisingly, provide
significantly better range between nodes and from nodes to clients, is that it is not as
"noisy" as the currently implemented version of B.A.T.M.A.N. In other words, the
fundamental design of each of the two protocols is such that B.A.T.M.A.N. sends out
more packets per minute to discover and maintain the mesh then OLSR does. This
saturates the airwaves with junk that leaves little room for actual data. More
saturation leads to greater packet loss, which degrades the system as a whole.
However, and crucially, the memory requirements of OLSR have been shown to
increase at a far sharper rate than B.A.T.M.A.N. due to its need to store complete
routing tables for the whole network (Johnson et al, 2008).
So performance between the 2 is a trade-off really. What about security then?
Ultimately, either protocol is pretty vulnerable to malicious nodes as neither depends
on a central authority. The thing about central authorities is the assigning IP
addresses. This is not an OLSR issue as OLSR says nothing about how to assign IP
addresses to routers (you need some external system to do this). OLSR simply lets
these routers find routes amongst themselves without talking to a central authority.
B.A.T.M.A.N. also doesn't say anything about how to assign IP addresses to routers
as it operates below IP (Layer 3), and routes based on MAC addresses. However,
because it's layer 2, it allows us to slip DHCP in there - even a malicious DHCP
server. If you set the lease times very high on such a server, the problem would not
get resolved very quickly.
As both OLSR and B.A.T.M.A.N. have their good points and their bad points, I would
like to have the best of both worlds. This is where R.O.B.IN comes in (the name is
interchangeable with the previously mentioned Robin-Mesh).
R.O.B.IN is an open source wireless mesh project for the OpenWRT (sometimes
“OpenWrt”) operating system - an embedded Linux operating system for Linksys
36
Technology Review
WRT54G and other devices. OpenWRT/R.O.B.IN is central to the Open-Mesh
project and runs on a number embedded architectures with the Atheros AP51
chipset. R.O.B.IN supports BOTH protocols, OLSR and B.A.T.M.A.N.
R.O.B.IN stands for “routing OLSR and BATMAN inside” and it is hopefully going to
allow the use of either or both popular mesh protocols in our finished project.
3.2. Hardware
There are several contenders for hardware choice when building a mesh network.
Linksys WRT54G
The Linksys WRT54G (and variants WRT54GS, WRT54GL, and WRTSL54GS) is a
home wifi gateway from Linksys (now owned by Cisco) costing about 50 euro. The
devices have two removable antennas* connected through Reverse Polarity TNC
connectors (larger 7db antennas can be attached in their place). It's a powerful
device, with 16 MB of RAM and 8 MB of Flash memory. Since most firmwares only
use up to 4 MB flash, a JFFS2-based read/write filesystem can be created and used
on the remaining 4 MB free flash.
After Linksys was required to release the WRT54G's firmware source code under
terms of the GNU General Public License, there have been many third party projects
enhancing that code as well as some entirely new projects using the hardware in
these devices. Three of the most widely used are DD-WRT, Tomato and OpenWRT.
Linksys released the WRT54GL in 2005 to keep for support third-party firmware
based on Linux, after the original WRT54G line was switched from Linux to VxWorks.
The units also use a 32-bit MIPS architecture processor, manufactured by
Broadcom.
* “Depending on the used technique, multiple antennas can provide power, diversity and
multiplexing gain and therefore increase the transmission range, reduce the transmitting
power, mitigate interference, increase channel reliability and increase data throughout.”
(Raniwala. A. and Leung, 2008)
37
Technology Review
I have extensive experience with the WRT54GL variant of this device, as we used it
in conjunction with OpenWRT firmware here on DkIT campus in our previous
wireless network. I have taken 3 or 4 of the decommissioned units and tested them
in a mesh configuration using the Freifunk firmware. Depending on the used
technique, multiple antennas can provide power, diversity and multiplexing gain and
therefore increase the transmission range, reduce the transmitting power, mitigate
interference, increase channel reliability and increase data throughout.
The hardware has a very high range, especially when used with the 7db antennae.
Having 4 LAN ports on the unit is a unique feature to this hardware over other mesh
hardware on review. The key features are:
•
Security Features: Stateful Packet Inspection (SPI) Firewall, Internet Policy
•
Enhanced Internet Security Management Functions including Internet Access
Policies with Time Schedules.
•
Easily flashed with 3rd Party Firmware
•
Moulded plastic casing is stackable with other similar devices
Fig. 11. Linksys WRT54g Hardware
38
Technology Review
A good solid piece of hardware with nice features and great range, but unfortunately
not weather-proof and no outdoor casing is available. No known POE solution either.
Good for an internal mesh network, but probably not ideal for use in an urban
environment.
Meraki Mini
In early 2007, the US-based firm Meraki (http://www.meraki.com) launched a mini
wireless mesh router, the "Meraki Mini". It claims speed of up to 50 megabits per
second and the 802.11 radio within the unit has been optimised for long-distance
communication, providing coverage over 250 metres. This is a good example of a
single-radio mesh network being used within a community as opposed to multi-radio
long range mesh networks that provide multi-functional infrastructure. The unit could
be flashed with 3rd party software to enable network enthusiasts to experiment with
the meshing capability of the hardware.
The firmware uses the SrcRR routing algorithm to determine the highest throughput
routes between the hardware devices.
Fig. 12. Meraki Mini
Each device periodically broadcasts, and all other devices in range will report their
routes. Then the devices use that information to route packets to the nearest
gateway. Only about one in ten repeaters needs to be physically connected to the
Internet for the mesh design to work well. It then searches for other nearby Meraki
39
Technology Review
nodes and advertises itself.
Recent business decisions at Meraki have thrown their original promise of
community based wireless mesh networks promise off course, leaving the field open
for projects like Open-Mesh. In early 2008 the company introduced a more restrictive
EULA (End User License Agreement) covering sales of new equipment requiring
that, "Meraki Hardware may only be used with Meraki Software", effectively shunning
the open source community and prohibiting reverse engineering, adding, removing
or otherwise altering the software on the device. Shortly after the new EULA was
imposed, Meraki sent an unsolicited firmware update to their units in the field which
disabled future firmware updates by customers and grinded all research into extra
mesh features on these devices to a halt.
To add insult to injury, the price of the units (originally about 50 euro) then shot up to
150 euro, putting them outside most people's price range. This signalled the end of
the Meraki Mini for most people. While still available to buy, I did not actually test this
hardware for the above listed reasons.
Open-Mesh OM1P
The OM1P is an ultra-low cost (50 to 60 euro) professional wireless mesh router
ideally suited for providing robust Internet coverage just about anywhere you need to
share a connection. Examples include hotels, apartments, neighbourhoods, coffee
shops, shopping malls etc etc.
Fig. 13. Open-Mesh OM1P
40
Technology Review
Each router is an access point, mesh gateway and repeater all in one tiny reliable
package (about the size of a cigarette box). From the earlier reading in the previous
chapter, remember the differences between these:
•
Access Point - A device that allows wireless devices to connect to a wired
network using wifi standards. Traditionally, an access point usually connects to a
router (via a wired network), and can relay data between the wireless devices
and the wired devices on the network. However, in a mesh configuration access
points are not necessarily connected to any other device physically.
•
Gateway – Like an access point, but is always connected to a point on the
physical network, thus allowing traffic from the access points out to the Internet.
Gateways also act as access points. In one possible setup, gateway units could
be OM1P devices connected to the LAN port on the business router, just like any
other laptop or PC on the premises. An internal firewall keeps traffic on the mesh
completely separate to traffic on the internal network of the business.
•
Repeater - When two or more hosts ought to be connected with one another over
the IEEE 802.11 protocol and the distance is too long for a direct connection to
be established, a wireless repeater bridges the gap. In this sense mesh access
points also act as repeaters.
The OM1P is also two networks in one with both open (public) and secure (WPA)
encrypted SSIDs so you can share a connection without sharing your data.
The device includes a hardware watchdog chip that will restart the router should it
lock up due to environmental or power spikes or short outages. There is also an
outdoor casing available for the unit so it can be weather-proofed, and each of these
casing comes with a POE Injector so the units can be as far from the nearest
network point as your CAT 5 cable will stretch. This allows for mounting units on the
front of the building, a nearby lamp post etc.
These units come pre-configured with ROBIN Firmware and can be controlled via
the CloudTrax dashboard almost immediately (see http://www.open-mesh.com).
Initial tests with these units were very favourable, and a small test network was up
41
Technology Review
and running in no time as I did not need to “flash” the devices with any 3 rd party
firmware to achieve the desired results. Key features include:
•
Zero Config / Plug & Play
•
Self Forming / Self Healing Mesh
•
Hardware Watchdog Chip
•
Free Online Hosted Management
•
Open Source firmware
•
Open Source Dashboard options
Just plug one router into any available Internet connection (wall panel, eircom router,
network swich etc). Then place additional routers around the area you want to cover.
Each will repeat the wireless signal extending the range by up to 150 feet and give
virtually everyone “5 bar" coverage. There is also a new OM2P which caters for
802.1n with built-in PoE support and dual Ethernet ports.
Fig. 14. OM1P mesh device connected to LAN port of a standard D-Link Router. The yellow
cable is this router's outgoing connection to the Internet via the chosen ISP
42
Technology Review
Firetide Outdoor 7020
The only non-open source solution on review is mesh hardware from US company
Firetide.
According to their website (http:/www.firetide.com) infrastructure mesh technology
from Firetide provides municipal, industrial and enterprise users with the bandwidth
needed to expand the reach of their existing networks, while adding a variety of fixed
and mobile applications eg. city-wide video surveillance, traffic management,
intelligent transportation systems.
The company's 7000 and 7020 mesh models provide superior throughput and
latency for delivery of multiple high speed "fibre-like" services over wireless to end
consumers, including high-resolution real-time video surveillance, high speed
Internet uploads and downloads, high definition TV service, multi-user interactive
gaming, multiple voice and video streams over IP, on-demand video, and high speed
infrastructure backhauls.
Fig. 15. Firetide Outdoor 7020 (http://www.firetide.com)
43
Technology Review
To maximise performance, dual-radio nodes support two radio modes. In the
“bonded” mode, both radios are combined to operate as a single unit that provides
double the bandwidth of a single radio equivalent. In the “linear” mode, both radios
operate independently enabling sustained bandwidth levels over an unlimited
number of hops. This enables long linear topologies, such as when networking a
railway line, and provides a sustained level of service to every node, which is also
critical for large municipal networks.
The hardware can operate in the 2.4 GHz and 5 GHz bands and provides the
flexibility to operate in channel widths of 5, 10, 20 and 40 MHz.
Key Features:
Firetide claim that their mesh delivers best-in-class performance with throughput of
up to 400 Mbps, exceeding that of current wired solutions like T1, Fast Ethernet and
OC-3 fibre, and provides a viable alternative to fibre or leased lines.
• Up to 400 Mbps throughput; fibre equivalent latency at .9 ms per hop; 1,000 VoIP
calls per node
• Built-in interference mitigation; intelligent routing; end-to-end QoS (Quality of
Service*) on a per-flow basis
• Integrated spectrum analysis; network capacity planning and antenna alignment
tools
• Dual configurable radios in 2.4 and 5 GHz frequency bands; indoor and outdoor
models with optional license key.
* Quality of Service is a method to guarantee a bandwidth relationship between individual
applications or protocols. This allows, for example, a full speed download via FTP without
causing jittering on a VOIP chat. The FTP will slow down slightly as bandwidth is needed for
the VOIP, provided VOIP was given greater priority.
44
Technology Review
Fig. 16. Meshing with Firetide Hardware (http://www.firetide.com)
These units are incredibly expensive compared other units, costing around 2000
euro each. This does not make them a good candidate for community meshing
projects. However, for a completely local authorities sponsored project, they would
probably be ideal.
The low cost, flexibility and continues support of the Open-Mesh OM1P make it the
ideal hardware for this project, in my opinion.
45
Technology Review
3.2. Firmware
Because I have already looked at protocols, it is obvious that the firmware needs to
support OLSR, B.A.T.M.A.N or both ie. the chosen firmware needs to be ROBINbased. There are many matching firmwares out there for these devices, each
ROBIN-based and each one having several forked projects with additional features
again. For this purpose, I am limiting the review to 4 of the most popular firmwares,
compatible with the hardware already reviewed.
Any mesh firmware we test needs at least
•
Automatic discovery of neighbour mesh nodes
•
Automatic address assignment among mesh nodes
•
Automatic routing and route distribution
•
Automatic distribution of nameservers
•
Automatic distribution of hostnames
As most router firmwares are based on OpenWRT (which caters for all of the above),
it is also best to explain what OpenWRT is exactly as I keep mentioning it.
OpenWRT is a GNU/Linux distribution for embedded devices compiled for Atheros
SoC (system on chips atheros) processors like the Linksys WRT54GL (now owned
by Cisco).
Instead of trying to create a single, static firmware, OpenWRT provides a fully
writeable filesystem with package management. This frees you from the application
selection and configuration provided by the vendor and allows you to customise the
device through the use of packages to suit any application (for example, install a
local mail server on the device itself). For developers, OpenWRT is the framework to
build an application without having to build a complete firmware around it. For users
46
Technology Review
this means the ability for full customisation, to use the device in ways for which it was
never intended.
Fig. 17. OpenWRT Firmware
Linksys WRT54GS or WRT54GL based routers with 8MB of flash memory are very
desirable for mesh and can load additional software. We are going to test each
firmware on a WRT54GL or similar router. This is just for convenience, it does not
effect the final choice of hardware. I have access to this model, in abundance, as the
previous incarnation of the DkIT Wireless network used this hardware. Several units
were donated to the Computing Department, but I have some units still in my office.
Replacement firmware can be easily uploaded to test units via their web interface
(usually at http://192.168.0.1). Failing this, it is possible to TFTP a firmware file to the
unit during the 2-3 second windows just after the unit powers on. You need to be a
very fast typist to use this method!
Freifunk
OpenWRT-based, German software supporting wireless mesh networks with OLSR
and B.A.T.M.A.N. Freifunk can be installed on a wireless router to set up a typical
OLSR node quickly and easily. The firmware runs on Linksys WRT54G type devices
(depending on hardware revision).
Installation on a WRT54GL was simple, using the built-in "Firmware Upgrade"
feature in the Linksys default firmware to upload the Freifunk package and then
reboot the device (this method of installation is the same for most, if not all 3 rd party
47
Technology Review
firmwares).
Fig. 18. Upgrading Firmware on WRT54G Device
After the installation, telnet is deactivated and the SSH server dropbear is started. A
firewall configuration protects the local network from everything outside of
192.168.x.x. Internet surfing via OLSR is possible using NAT (Network Address
Translation) provided there is a another station on the network announcing Internet
access.
Fig. 19. Freifunk Firmware
48
Technology Review
The Web interface is divided into two parts - a public area and a password protected
administration area. The public area allows visitors to view information about the
current routing table and a scan of WLAN base stations in the vicinity.
Overall a solid meshing firmware, but seemed to take a long time to poll other nodes
in the immediate vicinity. The absence of an overall mesh controller, in the form of a
hosted dashboard or otherwise, was a big issue also.
Robin-Mesh
Robin-Mesh is an easy-to-use open source firmware for small, widely available
routers such as the Linksys WRT54G series, the Fonera ("crowdsourced" hardware)
and the Open-Mesh OM1P. Robin-Mesh allows users to spread a single Internet
connection over a large area using meshing technologies. It is managed through a
web-based dashboard (Robin-Dash or similar) which can configure settings such as
the SSID name (for the Public and Private WLANs), as well as provide advanced
reporting and statistical information such as graphs, and logs. Robin-Mesh is always
based on top of the most recent release of the OpenWRT firmware.
Fig. 20. Robin-Mesh Firmware
49
Technology Review
Features:
•
Fully open source mesh firmware
•
Installs on relatively cheap hardware
•
Dual ESSIDs possible, typically one "open" and one "private", although both
can be WPA encrypted
•
Bandwidth can be limited up and down, per user on the first "public" ESSID
•
Public ESSID has an optional splash page feature. The splash page is fully
editable via an HTML/WYSIWYG editor. You can add user authentication and
billing options via third-party solutions from Coova.org, WiFi-CPA.com,
WorldSpot.net, or use any RADIUS server with a Captive Portal login screen
(dashboard required to manage all this)
•
You can "redirect" users to any web page on login on the public ESSID
•
Firewall prevents public users from accessing the wired LAN or private
ESSID (can be disabled)
•
Nodes automatically update firmware to latest stable version
•
SSH is supported and you can change the network password if desired
Nightwing
Nightwing is yet another firmware based on OpenWRT. It uses B.A.T.M.A.N. and like
all mesh firmwares it allows the deployment of a system that provides free Internet
access to an area or community in a collaborative way.
50
Technology Review
Features:
•
Zero Config: All the interfaces, wireless as wired, are configured automatically
basing it in the MAC address that each router has in its Atheros wifi device.
This way, all the Nightwing devices are located in the same channel and with
the same essid.
•
VAP (Virtual AP): As well as participating in the mesh, each node provides
coverage in the immediate area, behaving like a normal wifi “Hot-Spot” and
allowing mobile or fixed users to access the Internet through an open AP
without encryption. In this case, it's possible to connect rapidly from any
operative system. A captive portal solution controls the session timing and
assigned bandwidth to each open connection.
•
Security: Every node can be connected to a local network (LAN) without
compromising its security, meaning that the external users connected to the
open AP get completely isolated from the local traffic and vice versa. They
are also isolated from each other.
•
Intelligent functioning: When a node is connected to the local network but
does not find access to the Internet locally or though another node, it will not
attempt to interfere with the existing configuration of that local network (this is
useful if a node becomes damaged in some way).
Fig. 21. Nightwing Firmware
51
Technology Review
The core of the zero config functioning of Nightwing is the script /etc/init.d/nightwing.
This script, that auto-executes after the normal boot of OpenWRT, creates and
configures the interfaces eth0 (local network), ath0 (open VAP), ath1 (encrypted
VAP) and ath2 (mesh in ahdemo mode*). At this point the node must choose its roll,
meaning if the interface eth0 automatically acquires an IP address and it is possible
to access the Internet the node will switch to Gateway mode. The batmand demon
will be executed over the interface ath2, announcing itself as gateway to the rest of
the mesh.
The Robin-Mesh firmware, pre-installed on OM1P mesh nodes, is probably the best
solution for this project's firmware needs. It is rich in features, maintained by a large
community and compatible with nearly all available dashboard solutions. Having the
firmware pre-installed will reduce both deployment time and troubleshooting issues
significantly.
* Ahdemo mode is handy for long shot point to point connections as you avoid the RTT
(round-trip time) and inefficiency of the control packets in standard BSS (basic service set)
mode.
52
Technology Review
3.3. Dashboards
The dashboard is the hub of a mesh network. It is a cloud-based solution that gives
you complete control of your network from a browser anywhere in the world. With it
you can control firewall settings, cap bandwidth, monitor nodes, design splash pages
etc.
A good dashboard is an essential component for this project, so here I investigate
the more popular options.
CloudTrax
CloudTrax (sometimes “Cloudtrax”) provides a free administration, alerting and
mapping system for Robin-Mesh networks. It allows you to configure the SSID,
splash page, passwords, and bandwidth allocation for your network.
Some of its features include:
•
Daily summary email alerts of outages - ideal for property managers
•
Network Diagram showing node links and signal strength and users
•
Node List mode with 24-link quality graph and average metrics for each node
•
Detailed Google map with colour-coded nodes showing quality and users
•
Complete "Network Status" page with all of the above
These features are focused on creating networks that are easy to deploy, manage
and understand. You'll be able to see when nodes aren't working well over time and
see, using simple maps and diagrams, where you have poor connectivity between
nodes.
53
Technology Review
Fig. 22. CloudTrax Dashboard
While everything should work properly using Microsoft Internet Explorer, it is
developed and optimised for Mozilla Firefox.
CloudTrax is the default dashboard for ROBIN nodes, and used by Open-Mesh.com.
I have tested it fully with my WRT54GL devices and with some Open-Mesh OM1P
devices I acquired for this project. No issues with either if using Robin-Mesh
firmware.
OrangeMesh
OrangeMesh is a network management dashboard for ROBIN wireless mesh
networks. It provides powerful network status visualisation tools and a centralised
network configuration for your networks. It's specifically designed for community
wireless networks, with tools to help manage community members and to grow the
network organically.
If you ever decide to run your own dashboard server with OrangeMesh rather than
CloudTrax, you can do that later on in your setup: both dashboards can be used
together, separately or you can redirect node traffic usually sent to Open-Mesh.com
to your own dashboard server with a simple configuration setting.
54
Technology Review
Fig. 23. OrangeMesh Dashboard
This project is currently on hold, and has not been updated in 2 years. For this
reason, and this reason only, it will not be used for our mesh network. I have installed
an OrangeMesh server on DkIT campus to monitor both my test OM1P and
WRT54GL nodes. It works quite well, and would have been an ideal solution if I was
not concerned with maintenance and security updates, but I am.
Robin-Dash
While all the other dashboard on offer help control open source firmware on mesh
units, Robin-Dash is the only true open source alternative to the dashboards
currently on offer. It is in the early development phase (however, it can be considered
stable). The developer aims to keep up with the latest features of Robin-Mesh.
Benefits of using Robin-Dash, compared with others include:
•
Speed: The pages are clean, fast and easy to read
•
Size: The configuration is stored in tiny XML files (as well as CSV files for
logging) so that you do not have to have to rely on a resource intensive
MySQL server
55
•
Technology Review
Reliability: Because you can host your own version, on your own server,
internally or on the Internet, you know that your server will be up and working
when you want it to
•
More Reliability: Cloud Hosted version available, hosted on Amazon EC2
which has a 99.95% up-time guarantee
•
Up-to-date feature set: You will always have the latest features avaliable
because it is developed by a member of the Robin-Mesh development team,
and updates are pushed out as they are made live to the Cloud Hosted
version
Features unique to Robin-Dash:
•
Nodes checkin data is forwarded to the CloudTrax dashboard (if you so
choose), so you can view graphs and other information with ease
•
Integration with your own POMADE server. Poor Man Dashboard
Environment (Po.Ma.D.E.) is a popular dashboard extension offering total
control on the provisioning process
•
Custom Firmware Uploader
You can signup for a free account using the Cloud Hosted version at
http://www.robin-dash.net. This is the easiest way as there is no need to install
anything on your nodes, and all new features are added automatically by the
developer.
56
Technology Review
J.O.K.E.R.
J.O.K.E.R. (JOomla KEeper for Robin) is a proposed component for the Joomla
CMS (Content Management System) dedicated to wireless communities.
This dashboard will have this features :
Backend
•
All settings from the Open-Mesh dashboard but you change options allowing
you to see all Robin parameters
•
Support for multi networks
•
Peer Base config of single device (for example you can set a different
password for any devices)
•
support for your own radius server
•
you can hide private SSIDs
•
protection over http request for heartbeart
•
google map editor with geocode and reversegeocode abilities
•
Fonera community like system for deploy networks (the user of your site can
add his own hotspot in networks or only hotspot that you have sold/donated
to it)
•
export maps in kml format for use in any geolocation system (googleearth,
maps.google.com, radiomobile, other)
•
Preview of robin config to user
57
•
Technology Review
autonaming of hotspot (set prefix, length and a counter for generating
automatic labels)
frontend
•
googlemap with 'hotspots' marked
•
login for users with hotspot autodetect for supplying different content based
on location
•
the login page uses standard redirect and the JSON interface of coovachili
I am particularly interested in this project as I intend to use Joomla to build the Mesh
Community Website later on. Having total integration with the dashboard within the
system would be HIGHLY desirable, allowing all web functions to be managed from
the one site. However, no release of this component has ever surfaced, making it a
non-runner for this project (I hope to email the developers and offer to contribute
some of my skills to the project following this dissertation).
Again, because CloudTrax works out of the box with the Open-Mesh OM1P mesh
nodes, it is the obvious choice. However, I really like the look of Robin-Dash, and
time permitting will be bringing up a server to run alongside CloudTrax. However, this
is a “nice” feature rather than a required feature of the project.
The following page has a screenshot of my 3 test nodes (OM1P hardware with
Robin-Mesh firmware) as viewed via Google Maps plugin in the CloudTrax
Dashboard.
58
Technology Review
Fig. 24. CloudTrax with Google Maps plugin
Note the 3 units have detected each other and started to form a mesh network. This
is the basis for the rest of the project. Eventually an alternate path will develop
between the 2 furthest nodes as the internal tables are updated.
3.4. Content Filtering
It would very foolish to launch any free, open Internet service in a town centre
without considering content filtering from the outset. Content filtering is a method
where Internet traffic is blocked or allowed based on its content, rather than its
source network. However, source URL is a factor, as some web domains are
obviously hosting nothing but illegal or questionable material (pornography, for
example).
There are various ways to filter traffic, and usually there is some way around each
method too. I want to use an open source solution for this so that I can manipulate
the solution as much as I want and integrate seamlessly with the mesh network. The
filtering should be “transparent”, as is in configuration is required on the user's end in
order to access the Internet properly. Content needs to filtered at the mesh node or
above the nodes on the network topology.
59
Technology Review
3.4.1. Filtering with a Proxy
The first method I will investigate is filtering with a proxy server, namely with Squid (a
popular proxy server solution) and SquidGuard, a combined filter, redirector and
access controller plugin for Squid. To clarify the difference between the two:
Squid is a proxy server and web cache daemon. It has a wide variety of uses, from
speeding up a web server by caching repeated requests, to caching web, DNS and
other computer network lookups for a group of people sharing network resources, to
aiding security by filtering traffic. Although primarily used for HTTP and FTP, Squid
includes limited support for several other protocols including TLS, SSL, Internet
Gopher and HTTPS.
SquidGuard is a URL redirector used to use blacklists with Squid. There are two big
advantages to squidGuard: it is fast and it is free.
Fig. 25. Filtering traffic transparently with Squid/SquidGuard
60
Technology Review
This solution would be highly desirable, as Squid itself is very powerful. It allows for
ACLs (Access Control Lists) based on MAC address (only our nodes would be
allowed to access the Internet) and Traffic Shaping/QoS straight out of the box. We
could do the following if all traffic was transparently redirected to a Squid server:
•
set max download sizes (reply_body_max_size)
•
plugin a rewrite program eg. SquidGuard (url_rewrite_program)
•
deny file types based on MIME type eg. torrents (deny_mime_torrent)
•
use delay pools to shape traffic eg. after downloaded 1500000 bytes the download
speed will be reduced to 500000 bytes/s
A sample configuration for the above can be seen in Appendix A.
SquidGuard has a it's own separate configuration file, and it specifies the following:
•
The location of the text files containing blocked/allowed domains
•
Any time based rules for the filters
•
Where to redirect traffic if it meets a “blocked” rule
The configuration could resemble this one from my tests:
dbhome /var/lib/squidguard/blacklists logdir /var/log/squid3 time workhours { weekly mtwhf 08:00 16:30 date **01 08:00 16:30 } dest local { } 61
Technology Review
dest adult { domainlist adult/domains redirect http://niceonedundalk.net/Blocked/ } dest warez { domainlist warez/domains redirect http://niceonedundalk.net/Blocked/ } dest redirector { domainlist redirector/domains redirect http://niceonedundalk.net/Blocked/ } dest good { domainlist whitelist/domains } dest bad { domainlist blacklist/domains } acl { default { pass good !bad !adult !warez !redirector all redirect http://niceonedundalk.net/Blocked/ } }
Each
"dest"
entry
in
the
previous
config
refers
to
a
directory
in
/var/lib/squidguard/blacklists. Each directory can have lists of domains, precise URLs
or expressions inside text files that will be blocked or passed.
62
Technology Review
Fig. 26. Filtering traffic transparently with Squid/SquidGuard on a mesh network
While default lists are provided, new sites come online every day that would also be
undesirable on our network, so how to block those?
The Université Toulouse in France provides a free, community maintained list of
blocked domains for your redirector program (not necessarily SquidGuard, others
exist and they all use the same file format).
I have written and tested an update script that can be scheduled to run each night on
the server, and keep our blacklists up to date. I then only need to maintain the
whitelists which will contain URLs I don't want to be blocked (whitelists are
processed AFTER blacklists and are specified in the destination “good” in the
previous script).
63
Technology Review
Here is my updated script:
#!/bin/bash
#
BLACKDIR=/var/lib/squidguard
BLKDIRADLT=${BLACKDIR}/blacklists
#
#
# Download the latest adult.tar.gz, warez.tar.gz and redirector.tar.gz files from the Université Toulouse in France (updated daily)
cd $BLACKDIR
wget ftp://ftp.univ
tlse1.fr/pub/reseau/cache/squidguard_contrib/adult.tar.gz
wget ftp://ftp.univ
tlse1.fr/pub/reseau/cache/squidguard_contrib/warez.tar.gz
wget ftp://ftp.univ
tlse1.fr/pub/reseau/cache/squidguard_contrib/redirector.tar.gz
#
#
# stop squid
/etc/init.d/squid3 stop
#
#
# Install the new adult and redirector blacklist
tar C ${BLKDIRADLT} xvzf ${BLACKDIR}/adult.tar.gz
tar C ${BLKDIRADLT} xvzf ${BLACKDIR}/warez.tar.gz
tar C ${BLKDIRADLT} xvzf ${BLACKDIR}/redirector.tar.gz
#
#
# Change ownership of blacklist files
#
chown R proxy.proxy ${BLACKDIR}/blacklists
#
# Rebuild database?
#
#squidGuard C all
#
#
# Cleanup, start squid
/etc/init.d/squid3 start
sleep 5s
rm ${BLACKDIR}/adult.tar.gz
64
Technology Review
rm ${BLACKDIR}/warez.tar.gz
rm ${BLACKDIR}/redirector.tar.gz
echo "The squidGuard update script on proxy.niceonedundalk.net ran successfully"
exit 0
So far so good. I have a proxy server up and running. It is filtering content based on
blacklists, and the blacklists are updated nightly. I can test this setup by pointing all
traffic on port 80 from my laptop to the proxy server address (port 3128) while on the
mesh, and it works. However, remember that this needs to be transparent, which
means handled on the nodes themselves somehow redirecting port 80 locally to port
3128 on the server with some sort of NATing solution.
My initial reaction is to try this with an iptables rule on the node itself. As my Squid
proxy server is running outside the mesh network the nodes need to redirect all
users browsing on port 80 to the cache on the proxy. The rule for this looks
something like:
iptables t nat A PREROUTING p tcp dport 80 ! d <mymesh.ip> j DNAT todestination <server.ip>:3128 and this works, kind of. The value <mymesh.ip> assumes there is a management
lan, where the proxy is located. But I am hoping to have the proxy server OUTSIDE
the network altogether in the final design, in the college on the outskirts of town for
example. Also, I'm getting worried that my solution, while good, is not very efficient
when dealing with a limited backhaul on the mesh network (the OM1P device will
setup the Ethernet link to 10Mbit/s / half-duplex).
Other mesh developers on Internet forums have indicated the followings settings
might work:
#@#config management enable.proxy 1 #@#config general services.via_proxy <server.ip>:3128 65
Technology Review
but I have tried in vain to get this to work. I suspect it might not be supported on the
firmware version that comes pre-installed on the OM1P (newer firmware can be
installed, namely 'ng' from Open-Mesh – next generation firmware, which is currently
in beta mode).
For this reason, and because of time constraints, I am going to move on and explore
an alternative method of filtering.
3.4.2. Filtering with DNS
DNS filtering is another method worth investigating. The CloudTrax Dashboard has a
configuration setting that allows you to specify the URL to a shell script file hosted
somewhere on the Internet. When the mesh nodes checks in, it will download this
script and execute it if the timestamp is different from last time.
I propose using this method to alter the resolv.conf file in the Linux filesystem of the
firmware. The resolv.conf file tells the node where to direct all DNS lookups, and this
DNS information is passed to the client machine in the DHCP request when they join
the mesh network. This way I can have the user's device route all request for URLs
to my own or another DNS server, and if that DNS server is configured for filtering, I
can prevent certain URLs from being accessed. A sample script to make this happen
and to be referenced from the dashboard is found below.
#!/bin/sh rm /etc/resolv.conf echo "#custom nameserver" >> /etc/resolv.conf echo "nameserver 208.67.222.123" >> /etc/resolv.conf echo "nameserver 208.67.220.123" >> /etc/resolv.conf exit 0
This script fully implements my first suggested solution for DNS filtering. The
nameserver addresses you see there are actually the public OpenDNS servers
(http://www.opendns.com), and more specifically, their “Family Shield” servers.
These servers are pre-configured to block adult material, and are free to use. The
66
Technology Review
company encourage users to set their home routers to these DNS servers in order to
protect your children online. I probably could just leave it at that, but this gives little or
no control of blacklisting or whitelisting domains, we are at the mercy of OpenDNS to
decide for us. In most cases this would be fine, but what if a (fictional) local business
owner, William Butler, who sells clothes for larger gentlemen, discovers his website
bigwillys.ie is blocked? It would be incredibly hard and take a lot of time to get this
whiteisted at OpenDNS. Meanwhile, “Big Willy” himself is losing potential business in
town and getting very agitated. This is no good, so other solutions need to be
investigated.
The open source DNS server BIND 9 provides the ability to ﬁlter out DNS responses
from external DNS servers containing certain types of data in the answer section.
According to the Linux man* pages, it can “reject address (A or AAAA) records if the
corresponding IPv4 or IPv6 addresses match the given address match list of the
deny-answer-addresses option”. It can also reject CNAME or DNAME records in a
similar manner.
Rejecting addresses is all well and good, but if I'm correct this will leave the user with
just unresolved URLs, and no meaningful error message or redirection to a “blocked”
web page.
It would be possible to add entries to BIND 9 for blocked URLs (processed from a
flat file or database) but because of how BIND works a DNS “zone” for every blocked
URL would be required, redirecting it to the web server with the “blocked” page. The
more zones BIND has, the slower it gets, and we are talking about tens of thousands
of blocked URLs here.
For these given reasons, BIND 9 is not really an option either.
Dnsmasq is a lighter, more easy to configure DNS forwarder and DHCP server that
does not use zones as part of it's configuration (well it does, but it does not have a
separate file for each). It is designed to provide DNS and optional DHCP functionality
to networks.
* man pages are built in manuals accessible at the Linux command line
67
Technology Review
Dnsmasq keeps DNS zones as single lines in it's configuration file, so it would be
quite easy to have a line for each blocked domain, pointing requests for that domain
to a local webserver (as in same IP address of server) with the required blocked
page. An example line would be
address=/www.pokerroom.com/10.100.31.158
All requests for http://www.pokerroom.com will now get the blocked page, dished up
by a web server at http://10.100.31.158 (which could be the same box). The trick
would be updating the list regularly. However, I could easily modify the previous
update script for SquidGuard to download the files as usual, then rewrite the lines
from the blacklists into the config with the above format.
Something like the following script would suffice.
# the ipaddress where we want to send the requests to addcatcherip='10.100.31.158' configfile=/etc/dnsmasq.conf # download domain list(s) like previously and extract wget ftp://ftp.univtlse1.fr/pub/reseau/cache/squidguard_contrib/adult.tar.gz tar C /tmp xvzf /tmp/adult.tar.gz rm /tmp/adult.tar.gz cd /tmp/adult # location of a file where hostnames not listed can be added extrasfile='/etc/hosts.manual' # more temp files to use tmpfile="/tmp/adult/domains" tmpconffile="/tmp/.dnsmasq.conf.$$" # add the extras [ f "$extrasfile" ] && cat $extrasfile >> $tmpfile # check the temp file exists OK before overwriting existing list if [ ! s $tmpfile ] then 68
Technology Review
echo "temp file '$tmpfile' either doesn't exist or is empty; quitting" exit fi # get a fresh list of server addresses for dnsmasq to refuse cat $configfile | grep v "address=" > $tmpconffile while read line; do ADDRESS="/${line}/${addcatcherip}" echo "address=\"${ADDRESS}\"" >> $tmpconffile done < $tmpfile mv $tmpconffile $configfile $reloadcmd /etc/init.d/dnsmasq restart rm R /tmp/adult exit
This script would be scheduled to run nightly, keeping the content filtering up to date.
I will likely have separate files for whitelisted and blacklisted addresses in the final
project.
Fig. 27. Using our own DNS server to cache address lookups has the added advantage of
overriding chosen URLs. Note that because the DNS server address is in the mesh units
resolv.conf file, it does not matter what DNS server is specified at any point beyond that
(including attached gateway router devices). The connected wireless device will always use
the 'closest' configuration. For this reason other devices have been omitted from the diagram
69
Technology Review
3.5. Conclusion
This concludes the Technology Review. I have now accomplished the following:
1. Identified the separate components of a mesh infrastructure
2. Investigated OLSR a bit further and concluded that my chosen firmware will
need to be ROBIN-based
3. Decided on Open-mesh OM1P as the best hardware to use. The finished
network will have a combination of these units connected to the LAN port on
already existing routers at business' premises (gateways) and mounted on
the outside of building using the available Outdoor Enclosure Casing (APs)
Fig. 28. Outdoor Enclosure Casing for OM1P (http://ww.open-mesh.com)
4. Decided on Robin-Mesh as the best firmware to use
5. Decided on CloudTrax as the best dashboard to use
6. Investigated different methods of content filtering and decided on DNS-based
filtering using Dnsmasq
70
Case Study
4. Case Study
4.1. Overview
Let's review the 3 Phase scenario from the Introductory Chapter and pin down
exactly what it is I am trying to achieve in the fictional scenario.
4.1.1 Phase 1
Phase 1 is sponsored by either local authorities or the Chamber of Commerce, and
involves providing network connectivity to the town centre via a mesh network. When
complete, anyone at the centre of town will be able to connect to the Internet for free,
piggy-backing on the main Internet gateway, with backup DSL connections provided
locally on site. Several 'sponsored' devices will hopefully also be placed in certain
buildings/structures in the vicinity to spread the load.
Fig. 29. Proposed positioning of Mesh APs and GWs in Phase 1
This will start the spread of the network down the neighbouring streets that lead to
town centre (remember, the wireless broadcast from each unit is 50 – 100 metres,
with the signal being stronger where overlaps occur). Fig. 29 shows the existing town
71
Case Study
centre area with suggested AP placement and routes between them. Note that
Dundalk Town Centre has a number of light structures running through the Market
Square area, so it would be ideal to install mesh points inside those structures –
allowing them to be above street level and connected to a power source.
The main backup gateway (GW) unit could be any of these, whichever is nearest a
public office (remember that gateway nodes are also APs). Sponsored devices, as in
units paid for by the town but located on business premises (eg. Specsavers at the
Square), also act as GWs. It is hoped those units would all be gateways, as they
could be connected to that businesses' in-house ADSL router. The following diagram
shows the mesh created by the units in Phase 1. Imagine connection to the Internet
itself extending from each of the GW nodes (green icons). With this configuration,
and two of the gateways using different ISPs and the other being connected to a
high-speed DSL or fibre router owned by local authorities, it is very unlikely that the
Market Square area would be without connectivity unless there was a power outage
(and we could even cater for that scenario using the Power over Ethernet injectors
and a backup generator if connectivity was considered critical).
Fig. 30. Paths created by default configuration in Phase 1. I won't display the paths in any
further diagrams for clarity, they will simply be implied.
72
Case Study
4.1.2 Phase 2
Local businesses with existing broadband connections will be asked to donate some
of their (unused) Internet bandwidth to the mesh and join up with the connections
created in Phase 1.
Expanding the diagram, this looks like:
Fig. 31. In Phase 2, businesses in or near town centre are asked to host gateway nodes by
connect OM1P units to their existing broadband router. In return, they get free online
advertising.
There are obviously a lot more gateways than required at this stage, but remember
each gateway is ALSO an AP, so what we see here is a mesh network with little or no
distance to go for traffic to get on to the Internet.
73
Case Study
4.1.3 Phase 3
In Phase 3 small shops without existing Internet connection and anyone living in
town centre will be asked to host a standalone point. These points will hop local
users off to the nearest connected points created in Phase 2 (which is how a mesh
really works!). Where the signals overlap, this is where the network will be at it's
strongest. The diagram now looks like:
Fig. 32. In Phase 3, businesses with no existing broadband and residents near town centre
can hook on to the mesh
Let's watch the mesh in action. Imagine a resident near Union Street (marked
“START” in Fig. 33) participating in the network during Phase 3. He powers up his
standalone mesh device which he purchased for 50 euro (the MAC address of this
unit was registered with the Dashboard before posting to the resident, or he was able
to register the device himself through some sort of web page for mesh members –
easily done). The unit immediately needs to work out the shortest path to the nearest
gateway, taken care of by the firmware and underlying protocol.
Graphically, this light look like the diagram on the following page.
74
Case Study
Fig. 33. APs off the main town still have multiple paths to the nearest gateway
I'm suspecting that businesses in town will object at multiple levels to Phase 3,
where their unused broadband is distributed to smaller businesses and homeowners
in town centre. “That's not the point,” they will say when it is pointed out they are not
using it anyway (and have said when casually asked by myself). Trying to encourage
the overall vision of a community wireless amongst real people is probably the
biggest challenge this project would face. However, it can be helped to a certain
degree technically.
Firstly, the speed on the mesh network is not going to be “super fast” by any account
(the Ethernet port on the OM1P is set at 10 Mbit/s, not 100 Mbit/s like most LAN
ports on domestic routers. This is an immediate restriction on super high speed
Internet). The max speed per user would probably be set via the Dashboard at 0.5
Mbit/s, which is quite slow by today's standards. While good for checking email and
doing some light (very light) surfing, it's not ideal and you would not want to use it
continuously or for any bandwidth-heavy tasks.
Fig. 34. Setting max upload /download via CloudTrax
75
Case Study
The other thing is that after business hours, even though the network could be sped
up via the Dashboard, there is likely to be less Gateway nodes as business owners
may decide to power down IT equipment on their premises in the evenings (even
though they pay flat rate broadband, their electricity usage is still monitored). This
other factor will discourage anyone using the mesh as a permanent home Internet
connection (and potentially cause issues with the network backbone, something that
should be investigated further in the next section).
The true purpose of Phase 3, as well as to spread the mesh far and wide and letting
shoppers view offers directions to shops online, is to help smaller, new start-up
businesses off the ground by providing some infrastructure that they don't need to
pay for straight away i.e. An Internet connection. Once they have established an
online presence and business picks up, they can they invest in a broadband
package. They could also be helped out immensely if VoIP (Voice over Internet
Protocol) allowed them to phone wholesalers, other businesses and even customers
in the area without the need for a landline or paying for mobile calls.
I will attempt to gauge the feeling of existing businesses towards this and others
issues raised here in my next section, the survey.
4.2. Survey
For this section I created and hosted my own online survey with a brief explanation
of the project and 11 questions to gather feedback from business users. I asked the
local Chamber of Commerce to promote the survey website on their mailing list.
28 local businesses completed the survey in the first 10 working days. The following
table of results are based on their feedback, the full details of the survey are found in
Appendix A, with full versions of the questions asked and graphed responses.
Question
Yes
No
Not Sure
Do you think the mesh network is a good idea?
28
0
0
Would you participate in the mesh network?
26
0
2
Would you be willing to give over ALL your unused bandwidth? 26
0
2
Could you convince a colleague to join the mesh?
4
0
76
24
Question
Case Study
Yes
No
Not Sure
Would you be AGAINST letting smaller businesses use a 6
portion of your bandwidth?
22
0
Do you think free public wifi could be good for local business?
28
0
0
Would you be interested in a Location Aware smartphone app? 28
0
0
Given you are interested in the app, would you pay a fee?
22
6
0
Would you buy extra units to provide full coverage?
13
14
1
8
0
14
0
Would you be interested in free phone calls to other
businesses within the mesh?
20
Would the above free phone calls help sway your opinion of 14
the mesh?
Table. 4. Results of survey with local business owners
I have also written code to generate graphics from the gather data. The PHP code
used is outside the scope of this project (it is not required for the mesh network), but
the graphs outputted are presented with each question in Appendix B.
Overall the results of the survey are very encouraging, and graphically they look very
well with a few 100% values in there. The split never really goes beyond 50/50, so it
can be said that overall people are in favour of the mesh network and the services it
could potentially offer.
The most encouraging result is that business owners would not only be willing to
give over unused bandwidth, but they would be willing to give over ALL their
bandwidth to the mesh when not in use.
They would also be willing to pay for additional services such as Location Aware
apps.
77
Case Study
4.3. Interviews
For the interview stage of my case study I interviewed Brendan Minish, CTO and one
of the founders of Westnet.ie, a Wireless ISP covering Mayo and parts of
neighbouring counties using a mix of wireless technologies (802.11a, WiMax,
Licensed P2P etc). They are in operation since 2006. I was also hoping to offset my
own, incredibly positive attitude to mesh technology as I am aware it may not be
completely realistic. Brendan did not disappoint.
I also interviewed Robert Henderson, the ICT Operations Manager for The
Convention Centre in Dublin. He has approximately 16 years experience in the
technology sector having worked for companies such as Telecom Eireann, BT
Ireland (Esat Net) and Anacapa Group (free-hotspot.com).
Brendan Minish
Prior to founding Westnet.ie, Brendan Minish was a founder member of the Group
Data Scheme Society, a non-profit society set up to foster community owned data
'Co-Ops' covering rural communities. His experiences with mesh have not been
good at all. He does not believe that this is a 'protocol problem' more an RF
engineering issue. He says he had "relatively high hopes for mesh once".
Brendan's background is in radio and electronics (Atlantic College, DIT Kevin St).
One of the early Co-Op's he worked with used a large mesh network to cover
approximately 30 square km. A lot of work was put into trying to engineer the mesh
to a point where it worked reliably, performed well and was stable. This included
building a separate 802.11a backhaul network on top, using multi-channel nodes etc.
The eventual solution was to re-engineer the entire network at considerable expense
to build a fully routed network. See http://www.boards.ie/vbulletin/showthread.php?
t=141521 for more information. The interview was carried out online on 26 th March,
2012.
78
Case Study
Q: You have read the first 3 chapters of this project, what do you think of the overall
idea for a hybrid community network with elements sponsored by local authorities?
My survey suggest local business like the idea, but what do you think?
A: There aspects on the ISP side of things that do not scale very well at the low end.
These include backhaul, IP address resources, technical support. In my experience,
communities want networks and will support networks but also don't really want to
take on the work involved in managing and running such a network long term.
Q: Am I going about this the right way? Can you see any flaw in my plan?
A: Yes. Mesh protocols are not a good fit for typical internet usage patterns. They
test very well under light use but don't scale to significant numbers of concurrent
users. They do have a role to play in low bandwidth (compared to the access
medium bandwidth), 'bursty' networks like sensor networks and perhaps VoIP (if the
underlying network is very lightly loaded)
Q: What do you think of the choices made for protocol, hardware, dashboard and so
on?
A: They're fine, the primary issue is with mesh technology itself. It's not going to
scale. Build routed networks with dynamic routing protocols (such as OSPF) instead.
Q: Could you elaborate on this Brendan?
A: There are lot of assumptions made about mesh that ignore the underlying
operational realities of the 802.11 protocols in real world environments.
The problem with mesh is that it nearly always seems to work impressively well until
you start filling it up with real-world user traffic. Then you run into the limitations
inherent with mesh networks.
The other problem is that IP networking types tend to view mesh as a 'protocol
problem' of how to best handle routing between a bunch of nodes that have links
between them and fail to properly visualise what is happening at layer 1 (i.e it's not a
79
Case Study
big bunch of point to point links as in a wired network, it's a big pile of links on a
shared medium with a high percentage of hidden nodes and terrible collision
detection/control). It's actually not a 'protocol problem' at all, it's a radio planning
problem and regretfully the laws of physics bite. You simply can't expect a large
bunch of devices with varying radio paths between them to all share a (couple of)
channel(s) and to get anything like reasonable channel throughput.
Q: Do you think the plan for content filtering using DNS is sufficient? Again, can you
see any flaws?
A: No, I think you either need to provide unfettered access or to do DPI (Deep
packet inspection) at the network edge, DNS based systems are easy to circumvent.
There are also logging and data retention responsibilities.
Q: In your opinion, if a node on a business site went offline out of hours, how much
of a problem would this really be? Also, if we were running location aware software,
and customers were paying a small fee to use it, how much would nodes going
offline impact this service? Would this be a show stopper?
A: It's a problem if people want access to their business IT systems out of hours.
Offsite backup is a growing service and increasingly people are accessing things like
security systems (CCTV) out of hours to check on their premises.
Q: This leads really to the question of ownership and support in a semi-community
network. Who's problem is it really if nodes on business premises go offline and
cause gaps in the coverage? Is there really any way to avoid this in your opinion?
A: Yes, each member signs a simple contract where they give an undertaking to
leave equipment on 24/7. Battery backup is also required, here alarm supplies work
well but the batteries will only last about a year if the power is off every day out of
hours. Expect 3 to 5 years in conventional standby service.
Q: If I were to implement this plan in a real world scenario, what advice could you
offer me?
80
Case Study
A: Avoid mesh for Internet access networks! They don't scale for this application.
Instead consider building a redundant routed network, the costs will be broadly
similar since the dominant costs are not the routers themselves but the civil work,
antennas & mounting hardware, power supplies, configuration, administration etc.
Robert Henderson
When he worked for BT Ireland, Robert was responsible for the development of one
of Ireland's first commercial wireless networks, BT Openzone, a network of wireless
hotspots with pay as you go Internet access. The technologies he has worked with in
the wireless space include, wireless local loop, WiMax, Wi-Fi and 3G.
The interview was carried out online on 9 th April, 2012. I asked him the exact same
questions as I has asked Brendan Minnish.
Q: You have read the first 3 chapters of this project, what do you think of the overall
idea for a hybrid community network with elements sponsored by local authorities?
My survey suggest local business like the idea, but what do you think?
A: I think this is a viable solution for rural and large urban areas. In my experience
for such a solution to develop and be successful it needs the backing of local
community, local business and local authorities. We all have our part to play in the
development of local communities and this is one solution where everyone can win.
One of the challenges is who owns the system and maintains it. For me the solution
is a shared ownership model split three ways (local community, local business and
local authorities). The business can help fund it by allowing access to their premises
and in some cases services, the authorities an support it through promotion the
community and allow access to services such as electricity and possible office space
for auxiliary support. The community can support it in number a number of ways,
primarily using the service and the second is to provide auxiliary support, for
example community colleges could make part of their courses that student must do
tech support etc., this provides “free” support to those who use it and provide
valuable work experience to the students. It is important to know the boundaries of
the solution so as not to over extend what can be offered and ensure that the service
doesn’t enter a “commercial” business phase which would see it's downfall,
81
Case Study
remember it is “by the community for the community”.
Q: Am I going about this the right way? Can you see any flaw in my plan?
A: I think it is a good approach, the flaws will be that business and local authority
don’t buy into the solution for the long term. They need to be able to see the long
term benefits.
Q: What do you think of the choices made for protocol, hardware, dashboard and so
on?
A: I am most familiar with the Linksys products, these are good solid devices at a
reasonable prices. There are plenty of open source operating systems which can be
run and are supported by a wide following of the “online community”. As these
devices are based on a Linux platform there may be the possibility in the long term
to develop your own operating system which if was developed correctly could be
sold (donation based) to other community projects and this would develop a small
income for the network.
Q: Do you think the plan for content filtering using DNS is sufficient? Again, can you
see any flaws?
A: You can never 100% capture all content using any solution, OpenDNS is possibly
a good first step and in the long term it would need to be a solution which fits with
the entire network as it grows.
Q: In your opinion, if a node on a business site went offline out of hours, how much
of a problem would this really be?
A: At the start it will be important but as the service grows and users are aware of
the restrictions in specific zones it should become less of an issues. It could be
something used as an upsell to attract businesses, as they wouldn’t be using their
internet bandwidth at night so it makes more sense to allow the service run outside
business hours as a contribution to the community, balancing the benefits they
receive during business hours.
82
Case Study
Q: Also, if we were running location aware software, and customers were paying a
small fee to use it, how much would nodes going offline impact this service? Would
this be a show stopper?
A: Once users are aware of the restrictions in specific locations and this could be
part of the app it shouldn’t be an issue but it is important users are aware of this from
the start. If a node was offline more than it was online this could become an issue.
Q: This leads really to the question of ownership and support in a semi-community
network. Who's problem is it really if nodes on business premises go offline and
cause gaps in the coverage? Is there really any way to avoid this in your opinion?
A: Ownership has to be a group responsibility you are in affect building a “co-op”
solution and support I would reference my points in questions one. You can’t avoid
the issue of coverage gaps it will happen and who’s problem it is will depend on the
overall model developed with the businesses.
Q: If I were to implement this plan in a real world scenario, what advice could you
offer me?
A: There are scenarios of this type of solution in the USA and Europe, the ones
which have failed have done so in my opinion due to lack of support from all parties
or the are trying to deliver a commercial service. A strong balance needs to be
reached for it to be success.
4.4. Site Visit
As part of a drive to regenerate business in Drogheda using new technologies, urban
wifi was recently supplied to the town centre as part of RTE’s 'Local Heroes'
programme by Drogheda-based IT company Image IT Group. The outgoing Internet
connection was supplied by Dundalk based company Digiweb.
Local businesses allowed the installation of the hardware on the outside of their
premises, and it is hoped the project will eventually help promote business and
83
Case Study
tourism in the town.
The estimated total cost of the project is 5,000 euro. Drogheda also now has the
'iguide Drogheda on the Boyne' smartphone app, a virtual guide aimed at promoting
tourism, local businesses and jobs in the area.
It has never been stated publicly weather or not the wireless project uses mesh
technology, and coverage seems to be only really in the main street of the town,
consisting of 4 nodes.
I paid a visit to Drogheda with my laptop just to see the network for myself. The
network is open, and users are presented with a splash screen at each location. This
appears to be a captive portal solution, but without authentication. Once the user
clicks through this screen they are assigned a different IP address and are free to
browse at a maximum speed of 1.5 Mbit/s. After 2 hours of browsing the user is
disconnected and not able to reconnect to the network that day (or for 48 hours I
Iater found out, which sees an extreme restriction, but Digiweb insisted on it). No
content filtering is in place on the network and a user can browse to any webpage
unrestricted. Connectivity is quite good, a ping to www.google.com took on average
6 ms to return a packet.
I contacted Image IT Group and spoke with Chris Murphy, who was very helpful in
explaining how the network worked. As well as the limitations I had already
discovered, he explained that there was a maximum 8 Mbit/s download limit on each
AP no matter how many users where connected (could this mean just one user on
an AP could potentially get the full 8 Mb speed if they lifted the existing 1.5 Mb
restriction? I forgot to ask). This constraint was put in place by Digiweb as they were
providing the pipe. The average use on the network currently is about 1.4 Gb per
week.
He explained that the network is not a mesh, just 4 individual APs positioned along
the centre of the town, on different channels. The biggest issue they have is signal
interference from other networks (the overlapping channel problem from Chapter 2).
The signal is broadcasting on 2.4 GHz with a 5 GHz backhaul wireless network.
84
Case Study
Fig. 35. The Drogheda wifi is far from being a mesh, in fact it is 4 separate networks
Each AP is mounted on the outside of a business premises with no connection to the
business network at all. He explained that each point is essentially 2 transmitters
(one for the network, one for the backhaul) and a router not unlike a WRT54GL for
the splash page, DHCP and other services (it sounds like they use OpenWRT or
something similar). Each AP has it's own splash page and it's own IP address range,
there is no central controller. To me their solution seems to actually just be 4
completely separate wireless networks that happen to share the same gateway to
the Internet.
Finally I asked him about content filtering and the lack of it. Had they considered it?
What solutions had they looked at? He seemed not bothered by content filtering and
said it was not their concern, which I was quite surprised by. I asked what about all
the schoolchildren with mobile devices on the town every lunchtime and he
suggested they would access these site anyway on their own 3G connections. Also,
keeping the blacklist up to date would be “troublesome” and not worth the effort.
85
Case Study
4.5. Conclusion
The combined feedback from both the survey and the interviews is encouraging but
promotes caution. I are working on the assumption that the network will not be used
heavily by large amounts of users at any one time, but steps should be taken where
possible to ensure that if usage is heavy that the network does not “fall over”.
I have to point out that while I respect Brendan's Minnish's views on mesh and
acknowledge his experiences, that quite a while has passed since he tried it out and
that there have been some significant improvements. Also, if DNS filtering was as
easy to get around as he claims, then services like OpenDNS and NortonDNS would
not exist. The Open-Mesh devices have safeguards built in against some of the flaws
he pointed out – remember, these devices are purpose built for mesh networks, not
something that was 'hacked' together from existing hardware.
Both Brendan Minnish and Robert Henderson had concerns about ownership and
support for the network, and this is invaluable feedback which we will factor into the
project later on. Brendan's concerns and experience with network scalability are
noted, and something to be concerned about. Robert has confirmed for me that the 3
way approach of community, business and local authorities is a good model for
supporting the network, and has given me some good ideas about how to ensure
success with such a project. It was well worth carrying out the interview part of this
chapter.
The Drogheda urban wifi project seems incredibly flawed and not much effort was
put into the deployment. Responsibilities are shifted up the chain by each party and
nobody really wants to take ownership of it. I cannot see much of a future for that
project after the first 12 months, and it is a good example of what can happen if a
town does not embrace the network from the start, much like Robert Henderson
warned. There is so much more potential there for promoting business, creating a
community and so on. All they have is 4 individual broadcasts with no encryption, a
half-hearted deployment that ticked a box on a form somewhere at a meeting. The
same scenario can be found in nearly any street of any town, just not on purpose.
Lessons need to be learned from this and the same mistakes should not be repeated
in Dundalk.
86
Investigation
5. Investigation
5.1. Building Your Own Mesh Network
In this chapter I will start investigating the actual process of building a mesh wireless
network from the ground up, using the building blocks mentioned in the previous
chapters and taking into consideration issues raised in our Case Study (Chapter 4).
It's important to remember as you read this chapter that these findings and
suggestions are based on a hybrid mesh network, with managed, central elements
supplied by local authorities (servers, Phase 1 nodes) and other elements being
community based and effectively unmaintained by local business (Phase 2 nodes)
and the general population (Phase 3 nodes).
Both the interviewees in the last
chapter referred to this scenario as a co-op.
It is undecided if the actual roll out and basic maintenance of the network would be
managed by local authorities or a small IT company given the contract, but note that
somebody should be responsible at least for the recording of MAC addresses on
mesh nodes as they are sent out to individual sites. These MAC addresses need to
be added to the dashboard in the following section 5.1.2. Also, it would be the same
person or company that would receive email alerts about offline nodes and decide
how to act on them.
5.1.1 Configuring and Deploying Hardware
The OM1P mesh nodes can be bought online from http://www.openmesh-uk.com.
When purchased in bulk certain discounts can be applied. It is hoped that units can
be given out locally at a cost of 50 euro per business. I emailed this company
regarding discounts and they assured me something could be worked out for large
orders. I then ordered an initial 3 units and had the Dundalk Town Council pay for
them so I could investigate the feasibility of a mesh network in Dundalk Town Centre.
I also ordered the outdoor enclosures for these devices that came with PoE injectors.
The nodes work straight away out of the box, all that is needed is to add them to the
87
Investigation
dashboard for them to start working as a proper mesh. For this you must first record
the MAC address printed on the underside of each device.
An abbreviation for 'Media Access Control' address, a MAC address is a unique
hardware address for each node on a network. The open-mesh nodes also have preassigned public IP addresses in the form 5.x.x.x, so that you can open an SSH
connection directly to a particular node if need be for maintenance purposes. It
would be advisable to record these IP address as well as the corresponding MAC
address on a spreadsheet listing the location and/or business where each node is to
be deployed.
5.1.2 Dashboard Configuration
Dashboard configuration is managed via http://www.cloudtrax.com. The following
information is from their online manual.
The first time you use CloudTrax, you need to create a Master Login. You are
required to fill in the following information:
Master login ID: This is your master login you will use to access ALL
networks you create.
Password: This is your master administrator password.
Email: Youll receive an email at this address asking you to confirm this
master login to continue.
Your First Name: Used to address you in email correspondence.
When finished, click Create/Edit to save your account settings. In a few
moments, youll receive an email asking you to confirm the account you just
created. Just click on the Verify Account link to create your new CloudTrax
Master Login.
Youll automatically be taken to a page to create your network. Fill in the
information found on the following page.
88
Investigation
Network Name: This is the name you want to give this specific network.
You will use this name to make changes to the network, display reports, etc.
Password: This is the password for local administrators and should be
different from your master account login. This limits access and prevents
users from making changes to your network.
Fig. 36. Creating a new network on cloudtrax.com
Email: Enter your email address or the address of a local administrator to
contact.
Network Location: Enter a street address for the first node. To add nodes,
you will be shown a map that you click on to place nodes. By
entering an address here, you will be centred on the correct location for your
network. If you dont have a full address, that is OK - enter at least a city or
town.
Email for Notifications: Enter the email addresses, separated by spaces,
for all people youd like to receive "outage" notifications. These are sent
hourly.
When finished, click "Create" to save your new network settings. Youll be
taken to the General Settings tab of the Edit Network page. On the top of the
Edit Network page is an Add/Edit Nodes button. Click it.
89
Investigation
Fig. 37. Adding a new node on cloudtrax.com
A Google map, centred on the address you entered when you created the network,
will appear in a popup. Click the map where you want to add your first node and
enter all the required data. The latitude and longitude are determined by where you
place the marker, so zoom in closer and switch to satellite view if required.
There are many other settings that can be changed via the dashboard eg. manually
setting the transmission power for APs (this is used to reduce transmission power on
dense indoor networks) , but the remaining critical configurations are SSID based, so
you need to create at least one SSID to complete your setup. CloudTrax also allows
a second SSID to be enabled. The second SSID is usually used as a private or
corporate SSID and is useful for setting up an administrative network. It can be
hidden and/or encrypted as necessary and can have different traffic limits than the
primary SSID.
You MUST setup the first, public SSID at this point, and can decide later if you want
the second one. For this investigation I am creating a public SSID of
'niceonedundalk.net'.
90
Investigation
The following figure shows the fields that are presented when creating the primary
SSID:
Fig. 38. Configuring the Public SSID
As well as configuring the network name, I am going to use CloudTrax as the captive
portal solution, enable the Splash Screen (more later) and set the redirect URL to
http://www.niceonedundalk.net (the project website).
None of the other options are required at this time, except for the all important
maximum upload and download limits. Setting these values will not only help keep
decent amounts of bandwidth for each business to use themselves, but make the
mesh network not worthwhile for anybody as a permanent Internet connection.
91
Investigation
The download limit I am setting at 2048 kbps and the upload limit at 512 kbps.
Fig. 39. Speed test from a mesh AP
This will mean if anybody want to check their email and Facebook page, then the
mesh network is fine. If they want large downloads of data and to stream video
regularly, they should probably look into getting their own provider.
I have also enable the second, private, SSID with a name of 'secure1' and password
'qwerty123' (WPA encryption) and hidden the broadcast. Later on I will discuss
enabling network engineer laptops to connect to this SSID automatically.
In the advanced settings I have enabled a root password for logging into individual
nodes
and
I
have
also
set
the
address
of
the
custom.sh
server
to
http://www.niceonedundalk.net. If you recall from the Technology Review, this
address
allows
up
to
now
have
a
script
file
hosted
at
http://www.niceonedundalk.net/custom.sh which will be automatically downloaded
when a node checks in. The script rewrites the local /etc/resolv.conf file on the node
and points it at our own DNS server for all DNS queries. Configuration of our own
DNS server will now be discussed in detail.
5.1.3 Implementing Content Filtering
As previously stated, I would not be prepared to launch any publicly accessible
network without implementing content filtering (even though others seem to
disagree). I have also decided upon DNS as the best way to do this in Chapter 10.
To have your own DNS server I would recommend a Linux based server at a publicly
accessible IP address. Many of the hosting companies like Digiweb offer pre-
92
Investigation
installed cloud solution that you can access from a control panel and use to run
whatever services you wish. Such a server can cost as little as 10 euro per month. I
have convinced Digiweb to donate a server to me for this project should it ever
become reality. Alternatively, you could install your own Debian or Ubuntu Linux
server on your own chosen hardware using downloaded ISO files, and host on your
own network with a forward facing IP address. Installation of Linux to a server is
outside the scope of this project, but is really quite simple and there is plenty of help
available online.
I have brought up a new Ubuntu Linux based server for the purpose of this chapter
which I will now configure as a DNS server for our filtering solution, in a step-by-step
manner. It is the IP address of this server that should be pointed to in the resolv.conf
file on the nodes, so modify your own custom.sh accordingly.
I want to be able to connect to the server remotely via SSH, so the first this I need to
do is install an openssh server on my Ubuntu box.
# sudo apt-get install openssh-server
Now I can login to the server remotely as a user I configured during installation, as
long as I have given it a permanent static IP address on the network so I can always
get to it. It may also be necessary to open port 22 (SSH) on any local firewalls.
Fig. 40. SSH Session to the DNS Server
93
Investigation
Now we install the dnsmasq package.
Fig. 41. Installing dnsmasq using the APT Repositiories in Ubuntu
This installs dnsmasq and starts the service with the default configuration. At this
point it is safe to alter the custom.sh file and test that DNS is working from a laptop
connected to the mesh.
The proposed alterations to custom.sh are as follows:
#!/bin/sh
#this forces the script to be read
rm -f /etc/update/custom.md5
rm /etc/resolv.conf
echo "#custom nameserver" >> /etc/resolv.conf
echo "nameserver 10.100.31.158 " >> /etc/resolv.conf
exit 0
You may also want to run a basic sanity test and check that the server is indeed
acting as a proper DNS server while you are still logged on to that box.
94
Investigation
root@niceone-dns:~# dig @127.0.0.1 dkit.ie
; <<>> DiG 9.7.0-P1 <<>> @127.0.0.1 dkit.ie
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31686
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dkit.ie.
IN
A
SOA
ns-int01.dkit.ie.
;; AUTHORITY SECTION:
dkit.ie.
7882
IN
root.dkit.ie.
2012031502
28800 14400 604800 302400
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 15 16:04:03 2003
;; MSG SIZE rcvd: 75
As you can see, we can resolve dkit.ie using the locally installed DNS server. I am
now altering the custom.sh file hosted on the niceonedundalk.net web server and
booting up my test mesh nodes so they can acquire the new configuration.
After 15 minutes or so the mesh nodes check-in with the dashboard and are
prompted to check the URL http://www.niceonedundalk.net/custom.sh for any new
version of the custom script. If one is found, which there is, it is downloaded and
executed. This results in resolv.conf on the nodes getting, and using, the new DNS
server address. I can verify this has happened by connecting to one of the nodes via
SSH and inspecting the file.
95
Investigation
Fig. 42. SSH Session to a mesh node
However, I've noticed that propagation of that DNS server address to devices
connected to the nodes is unpredictable at best, and does not always occur.
paul@paul-laptop:~$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 101.145.30.1
Here my laptop is using the DNS server address passed down to it in the DHCP on
the open-mesh public network address space (101.145.x.x) and not the address now
listed on the node. This is highly undesirable, as it means the content filtering could
be bypassed altogether at intervals.
The solution for this is to abandon the custom.sh method for DNS server
specification and go back to the CloudTrax dashboard. Here we can add a
nameserver entry in the Alternate Servers section of our network configuration.
96
Investigation
Fig. 43. Alternate Server configuration on Cloudtrax
(If desired, an Alternate Dashboard eg. OrangeMesh and alternate SMTP server
address could be specified in this section also).
A quick check shows that this actually works with a hardcoded blocked URL in
dnsmasq, even though my laptop's resolv.conf file remains unchanged. A line like so
in the dnsmaq.conf file:
address=/www.pokerroom.com/193.1.40.167
results in the webpage shown on the next page.
97
Investigation
Fig. 44. Blocked Page on the mesh network as result of content filtering
I queried this on the Robin project forums and it seems to be correct, the contents of
the laptop's resolv.conf does NOT represent the DNS server being used for
resolution after you enter a value for Alternate Nameserver IP on the dashboard.
I'm going to leave both methods intact as a form of fallback for custom DNS
configuration. If one method fails for some reason, the other will likely take over.
Now all that remains is to configure and test my filtering script on the DNS server to
keep the black list up to date with inappropriate URLs that should be blocked on a
public network.
At /usr/local/bin/blacklists on the DNS server I have added the script found on the
following page and made it executable. It is basically a tidied up and tested version
of the script suggested in the last chapter.
98
Investigation
# I have a dedicated webserver running on campus with just a "blocked" page,
so lets's send the IPs there. The server is Debian Linux with Light HTTPD.
addcatcherip='193.1.40.167'
configfile=/etc/dnsmasq.conf
cd /tmp
# download publicly accessible domain list(s) and extract
wget ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/adult.tar.gz
tar -C /tmp -xvzf /tmp/adult.tar.gz
rm /tmp/adult.tar.gz
cd /tmp/adult
# location of a file where hostnames not listed can be added
extrasfile='/etc/hosts.manual'
# more temp files to use
tmpfile="/tmp/adult/domains"
tmpconffile="/tmp/.dnsmasq.conf.$$"
# add the extras
[ -f "$extrasfile" ]
&& cat $extrasfile >> $tmpfile
# check the temp file exists OK before overwriting existing list
if
[ ! -s $tmpfile ]
then
echo "temp file '$tmpfile' either doesn't exist or is empty; quitting"
exit
fi
# get a fresh list of server addresses for dnsmasq to refuse
cat $configfile | grep -v "address=" > $tmpconffile
while read line; do
ADDRESS="/${line}/${addcatcherip}"
echo "address=\"${ADDRESS}\"" >> $tmpconffile
done < $tmpfile
mv $tmpconffile $configfile
$reloadcmd
/etc/init.d/dnsmasq restart
rm -R /tmp/adult
exit
99
Investigation
When executed, this script adds about 5000 lines of blocked URL entries to the
dnsmasq configuration file and restarts the service. The whole process take about 2
minutes, so ideally it would run nightly as a scheduled task using the special @daily
cron keyword in Linux:
@daily /usr/local/bin/blacklists
or alternatively add the command to the file /etc/cron.daily and restart the process.
Content filtering is now in place on the mesh network and verified to be working. By
default, we are blocking domains containing adult material, but a quick look at
ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/
will show other lists that could be similarly integrated into our solution.
5.1.4 Desktop Configuration for (hidden) secure SSID
The second, private SSID offered by the CloudTrax dashboard for our network has
multiple advantages for network admins. It can:

Be hidden from normal network users

Can be bridged with the LAN, allowing us to assign our own DHCP
addresses and given clients access to LAN resources

Allow wired clients access to the network

Use WPA, WPA2 or RADIUS server authentication
The second SSID is also free of constraints like upload and download limits. It will
use whatever resources it can get access to.
These are all highly desirable features, so I propose enabling the second SSID and
creating an easy way for admins to get access to this network without knowing the
name of the SSID or any associated credentials.
100
Investigation
The settings for the second (private) ssid are as follows on the dashboard:
Fig. 45. Private SSID configuration on Cloudtrax
What I now want to do is provide an executable program that when executed will
create a wireless profile on the user's Windows laptop and allow them access to
this hidden SSID. The executable could them be hosted on the local council's file
server or in a secure area of the project website somewhere the public have no
access to.
101
Investigation
SU1X is a tool designed to automatically configure Windows XP/Vista/Win7 clients
easily for use on a wired and wireless network. Designed with mass deployment and
easy customisation in mind, originally for academic environments using 802.1x
authentication. The project website is at http://sourceforge.net/projects/su1x/
I have used this open source tool before to create the wireless connection wizard
for DkIT's own wirless network. Here I am going to explain how to customise the tool
to create our own installer for the second SSID. The result will be a setup program
like the one shown here:
Fig. 46. Our own Secure Network Configuration Tool
Simply clicking Install configures the laptop for immediate use. The user need not
know any required username or password for the WPA encrypted network, and does
not even need to be able to see it. He simply must be in range of a node for
successful completion.
102
Investigation
When you down and extract the SU1X setup files from the archive, the directory
structure is as follows:
.
|-- bin
| |-- config.ini
| |-- exported-sp2.xml
| |-- exported.xml
| |-- getprofile.exe
| |-- images
| | |-- big.jpg
| | |-- bubble1.jpg
| | |-- bubble-vista.jpg
| | `-- lis-header.jpg
| |-- Profile.xml
| |-- ReadMe.txt
| `-- su1x-setup.exe
`-- source
|-- config.ini
|-- eduswan.au3
|-- exported-sp2.xml
|-- exported.xml
|-- getprofile.au3
|-- images
| |-- big.jpg
| |-- bubble1.jpg
| |-- bubble-vista.jpg
| `-- lis-header.jpg
|-- Native_Wifi_Func_V3_0b.au3
|-- Profile.xml
`-- ReadMe.txt
We are not interested in changing how the program works at all, so ignore the entire
source directory and it's contents. This leaves the bin directory, and there are only
some essential files in here that are needed. Some of those files I will alter, others I
will rename for the purpose of this project. First though, I need to actually set up a
103
Investigation
wireless profile on my Windows 7 laptop for the hidden network 'secure1'. Once that
is done, I run the program getprofile.exe, which exports all the profile settings to
Profile.xml, including network name, authentication method encrypted version of
password etc. Here is the complete XML file:
<?xml version="1.0"?>
<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">
<name>secure1</name>
<SSIDConfig>
<SSID>
<hex>73656375726531</hex>
<name>secure1</name>
</SSID>
</SSIDConfig>
<connectionType>ESS</connectionType>
<connectionMode>auto</connectionMode>
<MSM>
<security>
<authEncryption>
<authentication>WPAPSK</authentication>
<encryption>TKIP</encryption>
<useOneX>false</useOneX>
</authEncryption>
<sharedKey>
<keyType>passPhrase</keyType>
<protected>true</protected>
<keyMaterial>01000000D08C9DDF0115D1118C7A00C04FC297EB01000000201EDB7690028643B26
241A5AFEFF17B0000000002000000000010660000000100002000000079CDA080A6068D1EE3C8B1
A7B7294BDA4AEC369928D4A65C7362216047306536000000000E80000000020000200000003D364
B41FB26DF0608F3FBAC679A1C7E3913C4F2672A58C0D51505648CFF1654100000004B2D9BCAD
6CC94221217EF097BAE8C1740000000EC1487DCAC58707F81C8D9ACFC41251B89E88F68F1724
F0DD9BF050D9B50FCED610375C2A6B9DFEE09097B33D25690A8CD2973511A2569CEF3A5FA572
9D67ABD</keyMaterial>
</sharedKey>
</security>
</MSM>
</WLANProfile>
104
Investigation
It's job done, I can now remove getprofile.exe from the directory. I've also altered
images/lis-header.jpg to include the project logo, and finally altered config.ini to
change the setup tool name, the welcome message etc.
Now I remove all unwanted files and rename su1x-setup.exe to niceone-securesetup.exe
The new structure is as follows:
.
|-- config.ini
|-- images
| `-- lis-header.jpg
|-- niceone-secure-setup.exe
`-- Profile.xml
This is zipped up into an archive named setup.zip and is ready for distribution to
network engineers and anyone else who wants to use the secure network.
I have included this file on the project CD for demo purposes. Note that the secure
network should also be used for any monitoring devices or other services layered on
top of the mesh later on.
It should be pointed out that the Open-Mesh system is limited to a point with multiple
SSIDs. By default, there are 2, the public and private. But what if more SSIDs were
required? What if there was a requirement to have different VLANs* on different
SSIDs with access to wired resources for various departments in your local council?
Unfortunately, Open-Mesh on the OM1P may not be the solution in this scenario
(unless maybe you change the firmware and build your own dashboard).
* A VLAN is a collection of nodes that are grouped together by switches into a single
broadcast domain, usually based on something other than physical location.
105
Investigation
However, some clever network engineering could be employed if push came to
shove. If using the second SSID with WPA2 Enterprise/Radius Authentication, users
could be assigned different roles or even different IP addresses depending on their
group. Don't forget we can use dnsmasq for our own DHCP server as well as DNS, if
we wanted. It would be possible to put some kind of NAC (Network Access Control)
into the flow just before DHCP and and drop a user into a particular VLAN based on
their credentials, NOT the particular SSID they have connected to.
This would introduce multiple extra layers of troubleshooting to our network, as well
as elements that are neither self-managed (like the DNS filter) or manageable from
our dashboard, so it is not something I would immediately recommend if the need
arose for different VLANs.
5.2. Adding Web Technologies
In order to have a complete experience for users of the network, it is necessary to
also incorporate web elements to the infrastructure, mainly for providing critical
security information and gathering user feedback. However, web technology can also
be used to show local news and embed data from the CloudTrax dashboard so users
can see the nearest nodes, how much traffic on the network etc etc.
Redirecting users to a website after they connect to the network is handled with the
'Redirect
URL'
value
on
the
dashboard.
I
have
set
this
value
to
http://www.niceonedundalk.net. Redirection only works if using a captive portal
solution on the public SSID, as it is your captive portal page (or splash page if not
authentication the user) that does the redirecting.
5.2.1 Captive Portal Setup
I am using the default Captive Portal option in the primary SSID which comes with
several splash page templates and the ability to use vouchers, Paypal etc. to sell
'tokens'. I am opting to keep the network completely open and free, and have
decided to use my own splash page template, which is the very first thing a user
sees when opening the browser after network connection.
106
Investigation
Fig. 47. Splash Page for the Nice One Network
The actual HTML used for the template is probably not necessary to go through, but
suffice to say it can be edited directly form the CloudTrax dashboard. You can also
use one of the pre-configured splash templates, designing your own splash page is
purely optional. The splash can also be disable if desired.
107
Investigation
5.2.2 Mesh Community Website
I have built a complete community website for this project at the redirection site.
Fig. 48. Website at http://www.niceonedundalk.net
This is what the user will see after they read and click Enter on the previous splash
page (unless they are on a mobile device, in which case they are presented a lower
resolution version with less content). The site is built using the Joomla! CMS
(Content Management System) found at http://www.joomla.org. It uses PHP and a
MySQL database backend. Open source CMS systems generally have a wide large
community of developers and testers, so there is a broad selection of templates and
extensions that can be used to achieve the required result.
The purpose if the site is as follows:

Provide an overview of the mesh project

Embed public elements from the dashboard including network map and
bandwidth usage

Show local news (imported using RSS Feed available at dundalk.ie)
108
Investigation

Give advice on wireless network security

Display the Usage Policy for the network

Provide a method of contacting the network administrators

Display logos for sponsors of the project

Display logos and/or advertisements for businesses that host gateway nodes

User Surveys

Generate additional revenue by using Google Custom Search facility,
targeted at local business
Later on this site could be used for other features, eg. Video chat, instant messaging
etc. The redirect URL on the network can be disabled, or just set to
http://www.google.ie or similar, if you want. You do not necessarily need to build your
own.
5.3. Other Considerations
As well as the other web features listed previously, something well worth considering
is location aware apps for mobile devices. The survey in the previous chapter
revealed people would be interested in this feature, and might even pay for it.
Because each mesh node has a latitude/longitude position, and a unique identifier in
the form of a MAC address (which is associated with a particular business), it is not
unreasonable to assume that a mobile device application could be written that would
alert network uses to special offers in certain shops as they passed by on the street,
if they had previously registered for such alerts via our community website.
I've quickly written a small app for the Android operating system that simply shows
the nearest nodes on the network from your location, as a proof of concept. The app
can be downloaded at http://www.niceonedundalk.net/app/NiceOneNetwork.apk and
is also included on the project disk. A link on the main screen takes the user to the
mobile version of the project website.
Illustrated overleaf is how the app might look on both an iPhone (if the codebase was
migrated) and an Android phone (which I have compiled for).
109
Investigation
Fig. 49. Mobile Application (app) to view nearby nodes
Something else worth considering is that because the mesh network is basically one
large, closed network between all the shops and shoppers in the town, that VoIP
phones could be connected to the network and used to make free calls within the
network. This would probably require the newer OM2P units with the LAN ports, and
the bridging features of the secondary private SSID would be used. Phone devices
could authenticate off a RADIUS server using their MAC addresses for security and
monitoring of traffic. Something like Asterisk or FreeSwitch could be used to handle
the VoIP, and it might even be possible to allow the use of a SIP client on smart
phones so users can make free calls from anywhere in the mesh while keeping the
same number.
Another method to consider for the phone network would be the 'Mesh Potato'
approach for handsets. Mesh Potatoes are mesh enabled devices with an RJ11 port
to connect an inexpensive phone and an RJ45 to connect any desired IP device.
110
Investigation
According to http://villagetelco.org, the name comes from combining 'Mesh' with
POTS (Plain Old Telephone Service) and ATA (patata is also Spanish for 'potato').
The project has had several iterations, but has now evolved into a full product,
sponsored by billionaire Mark Shuttleworth of Ubuntu Linux fame, that can be
purchased for about 100 euro per unit.
Fig. 50. Evolution of the Mesh Potato note the attached OM1P device in the centre image!
A business decision would need to be made as to which is cheaper on hosted sites
an Open-Mesh AP with connected VoIP phone, or a Mesh Potato with a regular old
fashioned handset attached.
As regards monitoring, it is inevitable that some level of support and expertise will be
required in the long term for the network. Even if somebody was able to login to the
Linux server managing DNS to do some troubleshooting, they would need to be very
comfortable with Linux commands to get the data they requires. They would then
need to be fairly IT literate to know what to do with that data.
For example, the following command
tail -f /var/log/dnsmasq.log | grep checkin.open-mesh.com
will filter out DNS traffic logs and show just check-in activity from the nodes. Useful, if
you knew how to do this.
Mar 27 10:23:18 dnsmasq[1610]: query[A] checkin.open-mesh.com from 10.106.82.15
Mar 27 10:23:18 dnsmasq[1610]: cached checkin.open-mesh.com is 50.17.245.251
111
Investigation
Mar 27 10:28:36 dnsmasq[1610]: query[A] checkin.open-mesh.com from 10.106.82.15
Mar 27 10:28:36 dnsmasq[1610]: cached checkin.open-mesh.com is 50.17.245.251
Using this command I was able to troubleshoot a mis-configured device in my early
tests, and rectify the issue quite quickly afterwards.
Also, the CloudTrax dashboard will send out mails if a node goes down, but who to
send these too? It would need to be somebody who can actually act on the
information, and know which nodes are relevant and which are not.
From: [email protected]
To: [email protected]
Subject: niceonedundalk.net Node Alerts
The following node(s) are down at niceonedundalk.net:
00:12:CF:D2:91:1E.
Last Check-in:
This is an automated hourly alert.
that is alerting.
1 Hours, 49 Minutes.
You will only receive this once per node
If you receive it more often, then the node came back up
before going down again.
Brendan Minnish raised concerns in his interview about support for the network, and
he was right. Careful consideration needs to be given to how exactly this network will
be monitored and maintained. To help keep support down, filters may be required to
only alert on gateway nodes that are not hosted on business premises for which
there is no access outside of hours, for example. Again, somebody would need to be
brought onboard with enough expertise to create these filters (and to carry out a
multitude of other ongoing micro tasks).
He also brought up the issue of logging and data retention on the network. I have
made modifications to dnsmasq to enable logging of all queries. The log file can now
be parsed to gather some additional data about the network traffic, see
http://www.tannerwilliamson.com/2012/03/03/analyzing-dnsmasq-log-with-awk/
for
an example.
I also sent an email to the Data Commissioner to find out exactly what the law is
112
Investigation
when it comes to community based wireless network, and how projects like this are
effected by the Communications Bill 2009 (and subsequent Communications Act
2011).
Subject: retention of data on a community wireless network
Dear Sir/Madam,
I am seeking clarification on when exactly the data should be retained and
how it should be retained when dealing with urban wireless networks.
In
essence
the
Communications
(Retention
of
Data)
Bill
2009
requires
telecommunications companies, Internet service providers, and the like, to
retain
data
about
communications
(though
not
the
content
of
the
communications); phone and mobile traffic data have to be retained for 2
years; Internet communications have to be retained for one year.
My query is concerning community based wireless mesh networks, like those
that can be built using equipment from Open-Mesh (http://www.open-mesh.com),
for example. Does data need to be retained somehow in this instance? Who
would be responsible if each member of the network is simply sharing out
some of their existing broadband from different providers? Also, would this
be different if local authorities were involved in providing some of the
bandwidth?
DHCP
would
still
be
handled
elsewhere
way
above
the
local
network, but DNS would be local and logs could be kept. Would this be
sufficient?
I look forward to your response,
Paul Scollon
They replied to my mail, but only to forward me to the Department of Justice. I went
back meantime to Chris Murphy at Image IT Group and queried him about logging.
His response was that they didn't officially keep any, other than the last 24 hours or
so of DHCP requests on the router itself. He reckoned Digiweb were likely keeping
traffic logs and as they were officially the ISP, then the onus was likely on them not
themselves, however he had not come across or been presented with any legal
113
Investigation
requirements during the network deployment.
By this logic, no logging would actually be required on the mesh network as each
gateway is connected to a different ISP via a business router, and it is therefore the
responsibility of that router's ISP to keep logs of traffic coming from that particular
gateway node. This was also confirmed by the eventual response from the
Department of Justice.
Subject: re: fw: retention of data on a community wireless network
Dear Mr. Scollon,
I refer to your correspondence concerning the Communications (Retention of
Data) Act 2011. You will appreciate that it is not appropriate for me to
comment on an individual case or to give an interpretation on how the law
might apply in any particular instance.
From
my
understanding
of
your
query,
it
would
appear
that
it
is
the
responsibility of the primary / underlying internet service providers (such
as Eircom, Vodafone, O2 etc.) to retain the information required under the
Act.
I trust that this explains the position and I hope you find it helpful.
Yours sincerely,
Criminal Law Reform
Department of Justice and Equality
However, it is very likely an abuse of the Terms & Conditions of the service provided
to use a router as a gateway in a public mesh network, something for which it was
not originally intended when it was sent out to the customer. Further investigation
would therefore be recommended in a real world scenario, although officially we can
now say that the Department of Justice has confirmed that logging does not need to
occur within the mesh itself.
114
Results
6. Results
All projects should produce results of some kind, and I believe a project like this one
should ask the following before completion:
•
Cost Analysis – how much will it really cost to implement? Is it affordable
and is there significant savings to make using Open Source technologies
worth the “risk”? Business people and investors in the project will want to
know.
•
Technical Feasibility – can this network actually do what what was
proposed in the beginning? Does the hardware, software and expertise exist
to implement this network successfully without any potential major delays? Is
there any risk that the deployment might be canceled due to a technical
problem that cannot be overcome?
•
Deployment Checklist – is it possible to produce an easy, step-by-step
guide for deployment of the mesh network based on everything we have
investigated up to now? Could this guide be followed by someone with only a
moderate interest in technology? Can we give alternatives to steps that might
be deemed too difficult to implement?
•
Recommendations – are there any caveats to using this technology that
should be made clear? Are there any specific recommendation based on the
research carried out? What new information has been discovered that may
not have been available before to anyone wishing to build their own wireless
mesh network?
115
Results
6.1. Cost Analysis
Going back to the title of this project “A blueprint for low cost urban wifi based on
mesh technology”, it is important to revisit the “low cost” element. The technology
has been fully investigated and proven to work, but could such a network be rolled
out on a large scale at low cost? If not, the user may as well just contract an IT
company to install off the shelf products and have warranties, support etc. in place if
there is no difference in the cost. If cost saving is significant, as will now be
investigated, then it is worth the extra effort to use open hardware and open software
solutions and to invest some time in learning to use them.
Municipal wifi networks can cost up to $125,000 per square mile to set up and
maintain, depending on building heights and the city's terrain, according to city
officials in Los Angeles when interview by the Los Angeles Times in 2007. At that
cost, the price tag for covering Los Angeles' 498 square miles could reach more than
$62 million (latimes.com, April 2007). Admittedly we are working with a smaller area
if talking about any urban area in Ireland, but even just one square mile would cost
93,000 euro by these calculations. When asked what the budget for such a project in
Dundalk would be, the local authorities told me they would be willing to pay in the
region of 85,000 euro for just the town centre, so the figures are accurate enough. It
is assumed this is the "all-in" cost, hardware, software, licenses, installation,
maintenance and so on. Let's also add on an estimated annual recurring cost of
15,000 euro for maintenance, support, hardware repair etc.
I now need to try and determine the equivalent all-in cost for an urban mesh network
using the technologies discussed to date in this project. Like all good budget
forecasts, the estimates should be as pessimistic as possible to try and come out
with maximum possible cost for the network deployment.
Even though many businesses in town will pay for and host mesh nodes as either
gateways connected to their routers or as standalone access points, I will still factor
in the cost of these units so that the final figure may represent not just a hybrid
network solution but cost of a full solution to local authorities. Also, even though
many of the servers could be donated in such a project as I determined early on, we
will count the cost of such servers for the same reasons.
116
Results
The following table represents a breakdown of all costs involved.
Description
Qty
Cost
Open-Mesh OM1P
Units
100
50
Open-Mesh OM1P
Outdoor enclosures
with PoE Injectors
50
10
Dell Poweredge R410
Server
1
1540
Debian Operating
system and built-in
Open Source software
3+
FREE
Co-location of servers
at hosting company
1
1800 per
annum
Installation and
maintenance contract
1
10,000
per
annum
Total Cost of
Deployment
Recurring Annual Cost
Total
Notes
This figure is more than enough
to completely cover the greater
5000
urban area. Remember, each unit
has a broadcast radius of 50-100
metres.
Assuming half the units are
500
hosted on the exterior of buildings
or on light posts etc.
Using Xen (http://www.xen.org)
for virtualisation, multiple servers
can be hosted on one piece of
1540
hardware. These include DNS,
Joomla website, possible 3rd party
dashboard solution and so on.
Debian is one of the most trusted
Linux distribtions on the world.
FREE
Scales well and supports Xen
Virtualisation.
This would likely not be required,
as the server could be racked at
1800 per local authorities data centre, or
annum
the servers could be donated by
different parties and therefore
hosted at different locations.
There would not be much work
involved in this, so 10,000 euro is
a generous estimate. It is my
opinion that this is the amount the
contract should be offered for,
10,000 per and no more. The installers would
annum
be responsible for hiring of any
equipment for mounting nodes on
external poles, buildings etc. This
amount should also cover
purchasing and replacing of faulty
units over time.
18840
11800
Table. 5. Total cost of deployment
The absolute maximum cost of deployment for the urban mesh is 18,840 euro with
annual recurring costs of 11,800 euro. However, maximising on the community
element of a mesh network could bring the total cost in at as little as 5000 euro if this
option was explored (the same cost as the wireless rollout in Drogheda last year).
These figures are significantly lower than any local authority seems to be willing to
117
Results
pay, and therefore the idea of a mesh wireless network based on open technologies
is at least worth exploring before deciding on vendor based solutions.
6.2. Technical Feasibility
Weather or not the project is technically feasible should not be an analysis of
weather mesh technology is fit for purpose, as this has already been discussed and
depends greatly on what you hope to actually achieve with the final network. For low
bandwidth use like email and casual browsing the mesh will work fine, but this
project has already decided that if you need heavy video streaming or intend to have
multiple VLANs for local authorities then a mesh network like the one described here
is probably not the correct solution.
Technical feasibility in this instance should determine if it is indeed possible to deploy
the network in a reasonable time-frame with the technology explored.
Building a micro version of the network myself took very little time in the previous
chapter, so once the initial infrastructure is in place, adding additional nodes and
expanding the mesh should be painless in the real world scenario. It would be
important to try and rule as many support issues as possible from the start, so
documentation to show business owners how exactly to attach a mesh node to their
existing router would be critical. It would be also important to get some kind of
agreement to have nodes at critical points along the network (the backbone)
powered up even outside of regular business hours (as highlighted by Brendan
Minnish in Chapter 4).
Further documentation on the maintenance of the network should be produced
during deployment. This would include details on how to replace an existing node,
update the MAC Address in CloudTrax and so on. It might be no harm to build
multiple version of the DNS and web server on our Xen Platform and introduce high
availability to counteract any maintenance issues with the server (particularly DNS,
as failure at this point on the network will bring down the entire service). Xen
Virtualisation fully support high availability clusters, and no extra costs would be
incurred to implement this as all the technology is Open Source. However, for TRUE
high availability, it would be advisable to use secondary hardware, so add another
118
Results
1540 euro to the original deployment budget in this scenario. This makes the TCO
(Total Cost of Ownership) for the network just over 20,000 euro.
6.3. Deployment Checklist
A step by step checklist to follow as a guide for deployment can now be produced.
This is a top level list of things to investigate before proceeding, and many of these
steps obviously have sub-sections. Some steps may not be required, and others
may need to be added depending on the exact scenario.
1. Decide if the network is to be completely community based or if it will
have input from local authorities. Have initial meetings and make sure
everybody involved in the deployment is in agreement with the plan. Agree on
the budget for the project and how funding will be managed. It might be
necessary to appoint a committee to oversee the project. Decide on who will
actually carry out the deployment and support the network – depending on
circumstances this may need to be in the form of a tender. Check the
legalities of whichever solution you choose in your geographical area.
2. Order any equipment needed. This will include the first batch of mesh
nodes and the server hardware that will be used. The deployment team,
consisting of any contractors and the technical contact for the committee,
should be responsible for sourcing and running CAT5 cable and any other
related work. The following steps are inter-changeable with the committee
and the deployment team.
3. Build the server, install virtualisation and add 'guest' operation
systems. Bring up and test DNS (if using your own), and optionally any third
party dashboards and/or community website. Install fail-over systems on both
the initial server and any secondary hardware invested in. Arrange colocation of server if required, otherwise rack the server at the chosen location
and test.
4. When the initial nodes arrive from Open-Mesh, create a CloudTrax
dashboard and test one or two nodes straight away. Arrange a custom script
on the webserver with DNS over-rides to point at your own DNS server(s) or
enable OpenDNS in the dashboard. Test nodes again for DNS filtering.
119
Results
5. If implementing a secondary, secure SSID, put this in place now and test.
6. Start deploying nodes. Work from the centre of town, where you want the
highest concentration of nodes, particular gateways. This is facilitated by a
higher concentration of businesses in the area who already have connections
to the Internet. Be sure the “backbone” is in place, basically a line of nodes
throughout the town which are guaranteed to never be powered off and
though which there will always be at least one route to the Internet. The
backbone could theoretically run in a straight line across the town with a
gateway on one or either end (refer back to Fig. 9. on page 32)
7. Mount any external APs in town centre next.
8. Do extensive testing that traffic can route around the network and out to the
Internet at this time. Use the Google Maps plugin in the dashboard to view
the routes. Experiment with taking down different nodes and make sure the
distances are correct for the traffic to reroute. It may be useful at this time to
have a grid overly on a map of the town centre at this point (CloudTrax allows
overlays on the map), the dimensions of each 'block' on the grid equaling the
radius of a mesh node e.g. 25m. This way it can be seen exactly where no
coverage exists and where to put an AP to correct this. This is best illustrated
with a diagram.
Fig. 51. Using a grid to address where there is no coverage
120
Results
The grid will help you see areas of the town with no wireless coverage at all, but
it will also help identify and address 'risk nodes', nodes that if they go down the
nodes beyond them have no route. An example in the above diagram is the
node mostly occupying block B12. Should it go down, the node in B11 is cut off
from the network. However, the grid helps to see that placing a new AP node at
A10 will help overcome this. If the committee and the deployment team are
using a grid like this, information about the network can be easily communicated
and visualised by all. This will ease deployment.
Fig. 52. Node required at grid reference A10
9. Do extensive testing on DNS filtering and server fail-over. This must be
guaranteed before the network goes live. Publicity for the mesh network
project will be unfavourable if local school children are viewing adult material
for free on a network sponsored by local business! Also, test any logging that
is required is working correctly at this time.
10. Go live with the network. Now that the network is up, growth becomes
organic as different businesses request nodes and join the mesh. Ideally, the
process is as follows:
•
Interested parties will fill out a form like the one found on the
community website at http://www.niceonedundalk.net/contact.html
121
•
Results
The committee will contact them and have them sign the network
agreement and pay the once off fee to cover cost of hardware.
•
A mesh node is assigned to the business. It's MAC address and
geographical location is added to CloudTrax. The node and
installation instructions are dispatched to the business (by post or with
a network engineer). The business logo is added to the sponsors
section of the website (if it's a gateway).
6.4. Recommendations
Building your own wireless mesh network in your town or village is not an impossible
task if using purpose built hardware and free online services like CloudTrax for the
dashboard, OpenDNS for filtering and one of the many popular CMS systems or
even a Facebook page as your community website. Minimum IT knowledge is
required unless you actually try to implement advanced features like some of those
covered in this project (your own DNS, secure SSID software, Location Aware apps
etc.)
Cost of the network deployment depends on how big the network will be and how
many advanced features you want. The biggest cost would be for support and
maintenance if required. Building your own mesh network is far cheaper than paying
for an all-in-one solution.
It is important to make it known that the mesh network is designed for low bandwidth
traffic like email, VoIP and so on. Media streaming and large downloads are not
recommended. The network should not be depended on for mission critical tasks or
anything relating to emergency services. However, monitoring of traffic lights or pay
parking facilities would be entirely possible.
A mesh network like the one described here will aid in the promotion of local
business via the community website. Indications are that the the network would be
fully supported by local business owners. For any that need further convincing, note
that mesh nodes can actually be hard-coded to go directly to the website of that
business, rather than the community website. A non-participating restaurant for
example could be shown that patrons can be taken directly to the a webpage
122
Results
displaying the lunch menu as soon as they open their wireless device. Features like
this and the possibility of location aware mobile phone apps will help sway anyone
who is unsure about the idea.
It is generally accepted and understood that mesh networks do not scale well.
However, it would be possible to have separate mesh networks for, let's say, each
quarter of the town and have them share the same primary backbone by design, as
illustrated below.
Fig. 53. Splitting the mesh network into four to ease scalability
It would not be inconceivable to allow traffic to pass between the individual meshes
at the points where they touch or overlap (there's an option in CloudTrax that
prevents this from happening by default, it can be easily switched off). Traffic would
only flow in this direction if the secondary backbone for this particular mesh went
down and an alternative route to the Internet was suddenly required as no gateways
were active in that quadrant.
123
Results
It is important to highlight that an open mesh network in an urban area like the one
proposed here is by no means secure, in fact, it's terribly insecure. This is the tradeoff for making the network extremely easy to join and having no required login
credentials. In a real world scenario the insecurity of the network should be
highlighted repeatedly to the user. While data on the PCs at each business is
firewalled away behind the mesh nodes, any shared files or folders on each
individual user device are at the mercy of their own security settings, which are
usually insufficient. Also, there is not much to stop wireless traffic being sniffed and
analysed if no encryption whatsoever is in use.
Remember from Chapter 2 that Zhang et al (2007) recommend the following to
ensure security:
1. Confidentiality or Privacy: The communication between users must be secure
2. Integrity: The paths must be protected to ensure the messages are not altered
3. Availability: Applications should provide reliable delivery of messages
4. Authentication: There should be some processes to identify the user to prevent
fabrication
5. Authorisation: There should be mechanism to ensure users have the correct
permissions
6. Accounting: Some process should be able to measure the resources the user
consumes
At least 2 of these are sacrificed by keeping the network open. However, ensuring all
these points are taken care of can make the network near unusable for a visitor to
the town. Where would they get login credentials? If something like library
membership number was to be the primary authentication method then steps would
need to be taken to ensure any library number from any town, or even European city,
worked. However, not many people actually are members of the local library. It would
be nearly better, but still not 100% guaranteed, to allow authentication off Facebook
using Oauth as more people have Facebook accounts and it does not matter really
where in the world they are.
To allow authentication like this, which is at Layer 7 on the Network Model, the user
would need to be given some kind of access were they can access at least one web
page to authenticate off. This is not unlike captive portal solutions that are already
124
Results
supported by CloudTrax. What is being proposed here is Captive Portal that can use
Oauth (an open protocol to allow secure API authorisation) to authenticate off
Facebook, Twitter, Google etc. Alternatively, the Captive Portal could allow “self
registration” where the user fills in all their own details and a confirmation code is
sent by SMS to their mobile phone. This idea of self registration would tick the boxes
for authentication and accounting, but also add value to the earlier idea of location
aware apps for mobile devices. Users could register interest in certain types of
products or services eg. Hamburgers, Guinness etc. and then be notified as they
pass nodes on the network where there are special offers on those items (by text
message, audio alert, email or other method).
The other captive portals offered in Open-Mesh allow for taking Paypal payments in
exchange for access to the network, which would only really work if the cost was
very low. In a larger town or city the charges collected for access to the mesh could
eventually pay for maintenance and support, but realistically people are not going to
pay for access if they can have unlimited Internet traffic from their provider on their
3G phone.
Wireless mesh technology can often be the correct solution for low cost urban wifi.
However, free (or even paid) urban wifi like this is something that has about 5 or 10
years life left in this and other countries before it is replaced with 4G technologies
like WiMAX. According to http://www.wimax.com, WiMAX is an IP based, wireless
technology that provides performance similar to 802.11g/n networks with the
coverage and QoS of a cellular networks. WiMAX is specifically intended for wireless
"metropolitan area networks", providing wireless access up to 50 km for fixed
stations, and 5 - 15 km for mobile stations. In contrast, the WiFi/802.11 wireless local
area network standard is limited in most cases to no more than 100 m. WiMAX itself
is to soon replaced by LTE, which uses the latest digital signal processing techniques
and modulations to greatly increase the capacity and speed of wireless data
networks.
Where mesh technology could have most impact in the future is in undeveloped
countries where cost is an actual concern and the chief barrier to those countries
catching up with the rest of the world. Connecting towns and villages with mesh
networks would lead to better education and aid business in poverty stricken areas
125
Results
of the world. A quick search for mesh deployments globally will show that in Africa
the technology is quite popular, probably because local authorities there have no
choice but to explore it as the cheapest option. However, once deployed, they often
find the technology is just as good as any expensive solution they could have
invested in – assuming their goals are similar to those laid out in this project.
One question that has repeatedly raised itself during this project is who actually
owns the network, and who is responsible for the maintenance of the network? The
recommendation on this would be that the network can belong to the community if
we wish (each business actually owning the hardware on their premises and
therefore a 'piece' of the mesh), but it would be considered critical that separate to
this ownership a maintenance contract (and therefore overall responsibility) sits with
a third party who are paid the annual fee mentioned in the total cost of deployment
earlier. Otherwise, it will be quite hard for the mesh project to survive long beyond
when the first nodes start to fail or some other factor leads to a breakdown in
service. Without a responsible party for maintenance and other issues, the project
will be very quickly abandoned by all concerned. This is of course drives the cost of
having a mesh network in your town up much higher than originally envisioned, but it
is a necessary evil to make sure the project is not just a gimmick but something longterm that can actually have real value.
Having now produced a set up results and made recommendations based on these
results, it is time to conclude the project in the following, final chapter.
126
Conclusion
7. Conclusion
In April 2012 Dublin City Council released a RFT (Request for Tender) for the
“Provision of Public Wireless Access in Dublin City Open Spaces” (Concession to
Provide WiFi Services in Dublin City, 2012). I have read over this document and
decided it is an ideal candidate to test my 'blueprint for low cost urban wifi based on
mesh technology' against. Can the proposed network in this project deliver a viable
solution in a real world scenario?
The document states that “Dublin City Council is seeking to offer a concession for an
experienced network provider to supply Public Wireless Broadband Services in
various locations throughout the City” but, critically, “the City Council will not pay for
this service, which will be a matter for the successful tenderer to establish and fund.”
Given they do not want to actually pay for this network (basically what “concession”
means), low cost is obviously required (or FREE, as far as the city council are
concerned). So, they might not want to spend any money, but they will however give
access to resources like CCTV camera poles, the document states. It can also be
assumed other useful resources would be at the disposal of the deployment team
and there might even be scope to use fibre running throughout the city as part of the
backhaul link (but we can't depend on that right now). Further reading reveals the
motivation behind the need for urban wifi in Dublin.
The City Council acknowledges the important role of telecommunications in the
economic, social and physical life of the city. Measures to improve the quality of
life for citizens are also a core feature of the Development Plan. Furthermore,
improving the attractiveness of the city for people and investors as a key part of
maintaining competitiveness and creating a vibrant place that attracts and retains
creative people within the city is also a key approach. The provision of publicly
accessible WiFi reinforces Dublin City Council’s commitment in this regard.
(Concession to Provide WiFi Services in Dublin City, 2012)
They actually mention improving the quality of life for citizens, something I
speculated on very early in this project. This is incredibly encouraging! They also
want to increase awareness of local business which is something that has featured
127
Conclusion
heavily throughout the project – remember businesses will make the mesh possible
by hosting nodes, in return for driving traffic in their direction. The survey results
earlier showed that nearly all businesses thought this to be a fair exchange and
would participate.
The document acknowledges that many cities around the world now have free urban
wifi and indicates that Dublin wants to be part of this new way of thinking.
The first city to offer free WiFi was Sunnyvale, California in 2005. More recently
cities including New York, Paris, Barcelona, Bilbao, Wellington and London
(launching 2012) have provided the service in large concentrations. (Concession
to Provide WiFi Services in Dublin City, 2012)
I cannot deny that the release of this Request for Tender is great timing just as I am
concluding my project on free urban wifi based on mesh technology. Forget the
previous fictional scenario in Dundalk, here is a real world scenario we can apply the
template to, and therefore make an ideal concluding chapter.
So let's go through the specified (technology) requirements of Dublin City Council as
listed in the RFT document to see if the low cost mesh network I have proposed in
this project would be a suitable candidate and if it would need much tweaking to fit
their needs.
The document asks for an experienced network provider to undertake the project, so
let's assume this mesh is being deployed by a small to medium sized IT company
who have tendered for the contract.
In the following pages I will highlight and identify the major requirements in various
sections of the RFT document, and try to match each requirement up to the various
features of the mesh network outlined in this project so far. Additional suggestions
and proposals will likely be required on my behalf to make the mesh template “fit” the
real world requirements satisfactorily.
1.3.2. Tenderers should be aware that the successful Tenderer will be required to
fully manage, maintain and operate the network.
128
Conclusion
This should not be a problem. By design, the network is mostly self-maintaining and
each device is self-configuring. However, we would need to ensure there is a
satisfactory response to nodes that go down (allowed, as units could be powered off
on business premises) but do not come back up in a reasonable time. This response
could be a simple phone call to the “owner” of the node and maybe a site visit if this
does not solve the issue. Remember that we previously determined nodes should
really be left powered on at all times, and the participants in the mesh network
should sign an agreement to do this.
Adding of the nodes to the dashboard could be handled either by the deployment
team prior to posting/couriering node to the business premises, or by some form of
self registration on a website that the business owner could carry out with the aid of
documentation posted out with the node device (the same documentation contains
instructions on how to connect mesh node to the existing broadband router).
Also, during my research I have determined the following approximate speed
reductions based on number of hops:
•
0 hops (gateway) = full speed
•
1 hop = 1/2 speed
•
2 hops = 1/4 speed
•
3 hops = 1/8 speed
•
4 hops = 1/16 speed and so on
For this reason, gateways should be as centrally located as possible to ensure no
one node has more than 2 hops to make to get to the Internet. This needs to be kept
in mind right from the start.
1.3.3. The City Council will not pay for this service, which will be a matter for the
successful tenderer to establish and fund.
This is where the “low cost” element becomes useful. No IT Company would
undertake a project like this unless it really was low cost. Even if charging per use for
network access, it would not be worthwhile if the deployment cost ran into hundreds
129
Conclusion
of thousands as it would take too long for a return on investment.
There is no escaping that a large number of nodes would be required. To fully deploy
in an urban area like Dublin City Centre, at least 25 or 30 nodes would be required
per square mile, just to ensure proper coverage. Weather or not additional nodes
would be needed would be determined by how much minimum bandwidth we wanted
per user, how much bandwidth was actually available and just how many users with
wireless devices would be present per square mile, on average. Realistically this
figures would not be known until the first nodes were actually deployed and traffic
logs were carefully analysed.
However, even with hundreds or even thousands of nodes across the city, the mesh
network will ultimately pay for itself. Each business that participates will “sponsor” a
node, getting their logo on the mesh network homepage (or even having that node
redirect all traffic to their own website, if that is what it takes to get them on board). A
once off 50 or 60 euro charge for ongoing free advertising (potentially for years and
years) is not something many businesses will turn down. This takes care of the basic
hardware costs. Other costs like DNS filtering, backup DSL connections etc. can be
easily covered by using a Captive Portal solution with payment via vouchers, which
could be purchased in newsagents throughout the city. In fact, the CloudTrax
dashboard actually has an option called “Require Vouchers” and when enabled you
can specify access time durations or increased speed limits as the features that
using a voucher actually gain for the user. You can also allow multiple additional
devices to voucher users. It's highly configurable.
Vouchers can be printed in the newsagents on a 3” printer like the Star Micronics
TSP100, for example (similar to the devices that print mobile phone credit). A feature
called “Lobby Assistant” allows authorised users to login for printing vouchers. I
would propose allowing the sale of vouchers in Tourist Information offices and major
newsagent franchises like Centra, Spar, Londis throughout the city (similar to how
tram tickets are purchased in most European cities). This would of course add other
factors such as logistics and additional support to the mesh network – how would
tourists know where to go for vouchers? Where would the printing paper come from?
Who would the outlet contact if the printer needed ink or maintenance? Other work
may well need to be contracted out if vouchers became part of the big picture.
130
Conclusion
3.4.1. The Dublin City Council WiFi project is focused on making internet access
much more freely available to both the citizens of Dublin City and its visitors. The key
aims of the City Council’s WiFi project are to:
•
Provide free public access to internet services at key destinations in the city
centre.
This is a given. I believe the best way to achieve this initially (first phase)
would be to make an agreement with the same newsagent outlets selling the
vouchers. Nodes placed at these locations will give a good spread over the
city centre nearly straight away. I can think of at least 4 or 5 newsagents in
Dame Street alone.
•
Promote Dublin as a forward-thinking and digitally inclusive city.
The addition of an urban wifi solution and the publicity that could follow would
definitely portray Dublin as forward thinking. Adding apps, VoIP and so on
over time would only enhance this image.
Tourists would immediately notice the network when they use their
smartphones and other devices, and because of the easy access this would
give them to tourist information, restaurant locations etc. any reports about
digital integration in Dublin would be favourable when they return home.
•
Introduce WiFi as an aid to foster economic growth, making Dublin city centre
a more attractive destination for citizens, business and visitors.
As mentioned previously, there would be significant benefits of the mesh
network for tourists. However, as detailed in the previous chapters, the main
focus of the mesh is economic growth. By design the network grows as more
businesses sign up, and in return traffic is directed towards these businesses
via the main website. However, businesses also have the advantage of
instance wifi hotspots on their premises for customer use, free VoIP phone
calls within the mesh, the ability to integrate location aware apps into their
business model (for example, Guinness have an app that informs you of the
131
Conclusion
nearest place to get a pint – something that would generate lots of revenue in
the city for pubs and restaurants). Also, public information apps about traffic
congestion, flooding etc. could be integrated into the mesh network easily.
•
Increase public access to on-line services and information.
Aside from the obvious applications mentioned above, newer technologies
like QR (Quick Response) codes code be employed to allow users access to
public information while walking around the city.
Because a user is technically as well as physically mobile as he walks
around the mesh, there is no reason a QR code cannot contain information
about an event, opening times, menu etc.
Fig. 54. Sample QR Code
The user simply scans the code with his smartphone and the required
information (hosted online but linked to the pattern in the code when
decrypted) is immediately displayed. Greater connectivity within the city
would allow for this technology to be used more than it currently is.
132
Conclusion
Fig. 55. Application of a QR Code
If you travel to New York you can see many instances of QR codes about the
city, on major buildings, works of art, near museums etc. When the user
scans the code they get access to a wide range of options including
directions, history, opening times, ticket sales and so on. A feature like this in
Dublin would very much aid the vision of a forward thinking city.
3.5.1. An essential part of the WiFi concession is that a sufficient amount of free time
with excellent quality of service is provided.
This is easily handled by the CloudTrax dashboard. All that would need agreement is
the actual limits to enforce before users have to actually purchase a voucher.
3.5.3. As a minimum, the offer shall cover:
•
The Priority Locations identified by the City Council (as set out in section
3.7.1)
3.7.1 outlines the following locations (and a few others):
133
•
Smithfield Square
•
Barnardo’s Square
•
Clarendon Street
•
St. Patrick’s Park
•
O’Connell Street
•
Temple Bar Square
•
Merrion Square
•
Henry Street
•
Grafton Street
Conclusion
I cannot think of one of these streets that does not have either a Centra or
Spar newsagent. This adds weight to my suggestion that an agreement could
be entered into with these chains to both provide the network backbone
across the city and also for vouchers to be purchased at these locations. It
would however be critical to get an agreement such as this in place almost
immediately.
Once these locations were up and running, other businesses nearby would
become aware of the mesh, and going by previous survey results most of
them would be willing to join in (especially when they see they can have free
advertising on the mesh network).
•
A daily period of free internet access for users, time and limitations to be
included within the proposal
Again, CloudTrax could easily allow all of these.
•
A Quality of Service with a minimum standard of broadband speed at
peak/busy times
The nature of mesh allows for a greater uptime than most networks, and QoS
was fully investigated during the Technology Review. Admittedly some
services will work better than others on the mesh, and there are some places
where it will fall down. However, these limitations could be clearly defined on
134
Conclusion
the Splash Page.
3.5.4. Other areas of interest to the City Council would include additional hotspot
areas with longer or unlimited usage, extending the coverage wider and the potential
for the City Council information to be broadcast to users.
Additional hotspots is of course the goal of the mesh (it wants to spread), and this
would be facilitated by more businesses and hopefully city residents investing in
node units like I described in the original plan. As individual nodes can be given
commands so their behaviour over-rides the dashboard defaults, there is no reason
why some nodes cannot have longer or even unlimited usage before vouchers are
required. In the same way, certain nodes could redirect to Council pages to give out
public information, or public information could be fed to the main site via RSS Feed
(see how dundalk.ie news is displayed on http://www.niceonedundalk.net)
3.7.3. The preferred option for branding and advertising the Wifi location in the
vicinity is to be included in the proposal.
There is no reason the mesh network cannot be easily branded in any way required.
All technologies used in the design are Open Source, which allow for easy
customisation and rebranding of the network. Ideally a PR Company would be
brought in to deal with the details of this, but anything is possible technically: website
branding, app branding, export to Twitter and Facebook via RSS, etc.
3.7.4. Of significant importance to the vitality of Dublin City is its annual calendar of
events. In assessing the provision of WiFi services in the city it would be appropriate
that due consideration is given to the availability of this service on a temporary basis
for one off/recurring events in the city such as the Innovation Dublin festival, the St.
Patrick’s Festival, Tall Ships Festival and so forth. With this in mind, proposals for the
provision of WiFi services for cultural/ international events on a temporary basis
within the city will also be considered as part of the concession.
Because of the nature of the mesh network, it would simply be a matter of
connecting some APs in the vicinity of the event. These APs would relay traffic off to
the nearest gateway, which should never be too far away if the mesh project proved
135
Conclusion
successful. There could be a group of nodes reserved for use at these events, and
their MAC addresses could be easily reassigned on the CloudTrax Google Maps
overlay as required.
However, the ideal scenario is to position some nodes permanently in external
enclosures at the common outdoor locations for these events (Trinity Campus,
Docklands, RDS and so forth). The document states that the Council are willing to
give access to CCTV poles, which is ideal as it keep nodes out of reach of the public
and these pole also have power which the nodes could utilise.
3.10.1. Tenderers will be responsible for and set out procedures for registration,
identification and verification of new users.
As we intend the network to be open, registration of user details is not really
necessary. However, if required it can be easily added to the Captive Portal in the
form of self-registration. Users would be tied to both the MAC address of their device
and possibly a voucher code they have entered. If vouchers were to be purchased
online, we could capture their details then when they first try to purchase a voucher.
They are several other variations, but suffice to say this could be catered for. We
could even use Freeradius authentication or implement the Oauth/Facebook solution
suggested in the previous chapter.
3.10.2. Tenderers will be responsible for and specify the appropriate filtering and
reporting to be carried out in accordance with required legal standards.
It is refreshing to see that Dublin City Council are actually concerned about filtering. I
have maintained all throughout this project that public wifi without some form of
filtering is not only irresponsible, put potentially illegal. I am happy to see that a real
world scenario actually does require it. This is where the DNS Filtering detailed in
this project would be the perfect solution, and is proven to have been worthwhile
investigating. DNS logs could also be kept for the required period of time, and the
Department of Justice have previously confirmed that in a mesh network such as this
one the responsibility for any other logs would be with the ISPs for each gateway
node.
136
Conclusion
3.10.3. Tenderers will be responsible for and specify the control and maintenance of
transaction records in accordance with data requirements.
It is assumed the above mentioned DNS records would be include with this point, as
well as any logs produced by the Captive Portal solution in relation to voucher use.
3.10.6. The approximate number of users and bandwidth availability per specified
location should be set out clearly. In addition the “spine” network should be set out
including linkages, capacities, and costs involved.
The values requested here are those we would determine during Phase 1 when
traffic logs are analysed (mentioned earlier in response to 1.3.3). It would not be a
big problem to run simulations and clearly specify the results in a document. For
example, for the purpose of the tender we could take 4 or 5 mesh nodes up to
Merrion Square and leave them powered up for the day. An analysis of the logs
would show us the number of users per hour at each AP (wireless devices will
automatically connect to any SSID with no encryption enabled). This basic figure
could be used to estimate the figures required by the RFT document.
The “spine” network referred to is most likely what I have referred to repeatedly as
the backbone network. This I am proposing as a series of nodes, all gateways,
running across the city centre with DSL backups on either end on the backbone (one
should ideally also be put at the halfway point). Each point along the way is hosted at
either a Centra, Londis or Spar outlet (who also sell the vouchers) and firm
agreements are in place that these nodes will always be powered on. The challenge
here would be getting those franchises onboard quickly and getting those nodes in
place first. Once they are up, we could approach the pubs and restaurants and
possibly some of the major hotel groups – nodes at these location would very quickly
fill in the gaps as there is such a high concentration of these types of business in
Dublin City Centre (they are also the type who would benefit most from services
layered on top of the network).
Costs will be made up of the price of the nodes plus any costs relating to the backup
DSL connections. It may also be required to mount several points on external
structures to bridge gaps between the different outlets ie. There may be instances
137
Conclusion
where there is not another newsagent for more that 100 metres (I would propose
using the newer OM2P devices here for longer range than the OM1P – it has 4 times
the speed and 4 times the transmit power of the older device).
3.10.7. Tenderers should indicate how open the architecture proposed is, and how it
accommodates the potential for future expansion. This should be done on a
population basis, and will include “traffic capacity” and any thresholds requiring a
quantum change in infrastructure.
As explained in the previous chapters, the architecture proposed is VERY open, on
purpose. This will certainly accommodate future expansion (meshes can even be
joined to other mesh networks). The graphs and statistics produced by CloudTrax
will indicate when the “organic” growth of the network is to be interrupted and
additional nodes need to be placed at particular location. However, it should be
possible to forecast when these thresholds are approaching and open up new
negotiations with other business franchises about the city to gently push the organic
growth of the network along. There are many franchises in the city, from Noodle Bars
and Coffee Shop outlets to Bookmakers and Chemists.
This answers all the technical requirements of the document, the rest are the usual
business and legal requirements found in most Requests for Tender. As we can see,
the blueprint for a low cost urban wifi mesh fits quite well into a real world request
for city-wide connectivity with little or no budget provided. Very little tweaking was
required to meet the requirements in the document.
I believe this shows that an urban mesh, with elements supported by the local
community (both residential and business) and local authorities (if possible) should
at least be considered in any scenario where wireless is required over a large, public
area.
138
Appendix A
Appendix A
Sample SquidGuard Configuration
#Allow ALL clients acl all src 0.0.0.0/0.0.0.0
#
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
#acl SSL_ports port 443 563
#
#We are going to proxy port 80 only. Port 443 should be dealt with somewhere else.
acl Safe_ports port 80
#
#acl Safe_ports port 80 443
#acl Safe_ports port 80 21 443 563 70 210 102565535
acl CONNECT method CONNECT
#
#
# Default configuration ####
#
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
#http_access deny CONNECT !SSL_ports
http_access deny CONNECT !Safe_ports
http_access allow CONNECT
http_access allow all
http_access deny all
icp_access allow all
miss_access allow all #
# General Config Stuff ####
#
cache_mem 64 MB
cache_dir aufs /cache/ 10000 22 256 cache_store_log none
half_closed_clients off maximum_object_size 1024 KB
reply_body_max_size 50 MB
http_port 10000
hierarchy_stoplist cgibin ?
access_log /var/log/squid3/access.log squid
url_rewrite_program /usr/bin/squidGuard
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
vi
Appendix A
refresh_pattern (cgibin|\?) 0 0% 0
refresh_pattern . 0 20% 4320
visible_hostname proxy.niceonedundalk.net
icp_port 3130
coredump_dir /var/spool/squid3
#
# Torrents by list, mime type, file extension ####
#
acl torrents browser "/etc/squid3/torrents.txt"
acl deny_mime_torrent rep_mime_type application/xbittorrent
acl deny_dot_torrent url_regex i \.torrent$
http_access deny torrents
http_access deny deny_dot_torrent all
http_reply_access deny deny_mime_torrent
#
# Refresh pattern optimisation ####
#
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 overrideexpire ignore
nocache ignorenostore ignoreprivate
refresh_pattern i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|xflv)$ 43200 90% 432000 overrideexpire ignorenocache ignorenostore ignoreprivate
refresh_pattern i \.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200 overrideexpire ignorenocache ignorenostore ignoreprivate
refresh_pattern i \.index.(html|htm)$ 0 40% 10080
refresh_pattern i \.(html|htm|css|js)$ 1440 40% 40320
refresh_pattern . 0 40% 40320
#
# DELAY POOLS CONFIG ####
#
#This is the most important part for shaping incoming traffic with Squid
#For detailed description see squid.conf file or docs at http://www.squid−cache.org
#We don't want to limit downloads on certain networks or from certain IPs...
acl magic_words1 url_regex i 193.1.45
#acl magic_words1 url_regex i 192.1
#We want to limit downloads of these type of files
#Put this all in one line
acl magic_words2 url_regex i ftp .exe .mp3 .vqf .tar.gz .gz .rpm .zip .rar .avi .mpeg .mpe .ram .rm .iso .raw .wav .mov
#We don't block .html, .gif, .jpg and similar files, because they
#generally don't consume much bandwidth besides we're caching them anyway
#We want to limit bandwidth during the day, and allow
#full bandwidth after business hours
#Caution! with the acl below downloads are likely to break at 18:00. acl day time 09:0018:00
vii
Appendix A
#We have two different delay_pools
delay_pools 2
#First delay pool
#We don't want to delay our local traffic.
#There are three pool classes; here we will deal only with the second.
#First delay class (1) of second type (2).
delay_class 1 2
#−1/−1 mean that there are no limits.
delay_parameters 1 1/1 1/1
#magic_words1: we have set before
delay_access 1 allow magic_words1
#Second delay pool.
#we want to delay downloading files mentioned in magic_words2.
#Second delay class (2) of second type (2).
delay_class 2 2
#The numbers here are values in bytes;
#we must remember that Squid doesn't consider start/stop bits
#50000/1500000 are values for the whole network
#5000/1200000 are values for the single IP
#
#after downloaded files exceed about 1500000 bytes (approx 1.5 mb),(or even twice or three times as much)
#they will continue to download at about 500000 bytes/s approx 0.5 mb)
delay_parameters 2 500000/1500000 50000/1200000
delay_access 2 allow day
delay_access 2 deny !day
delay_access 2 allow magic_words2
#openmesh units will have further throttling options on them. Comment out above if necessary while troubleshooting
viii
Appendix B
Appendix B
Results of Survey from Chapter 4
The following survey is designed to gather feedback from potential
business users about this idea. Please take a few minutes to
complete.
First Thoughts
This question is required
Having read a description of the mesh network, do you think it
is a good idea? Do you see value in it?
Yes 100% Incredibly good and unexpected result
No
ix
Appendix B
Participation
Would you be inclined to participate in the mesh network? It
would involve a once off cost of 50 euro, and in return you
would get free online adverting on the mesh website. There
would be no reduction in your speed and your own business
network would be totally secure. You would simply be giving
away a little bit of your Internet access that you weren't using
anyway.
Yes 92.86 %
No
Need more convincing 7.14 %
Again, a great result. Only 2 companies needed more convincing.
x
Appendix B
Given that you are not using it anyway, would you be willing to
give over ALL your unused bandwidth to the network? That is,
would you be happy for customer on your premises to have
higher speed Internet while you are not using it at all?
Yes 92.86 %
No 7.14 %
A very unexpected high result for this one, and very reassuring. It
reaffirms that the community spirit required for projects like this
one does actually exist.
xi
Appendix B
Given that you are onboard with the idea, or will be later on, do
you think you could easily convince a colleague or
neighbouring business to also join the mesh?
Yes 85.71 %
No 14.29 %
xii
Appendix B
Would you be totally AGAINST the idea of letting smaller,
neighbouring businesses use a portion of your flat-rate, unused
bandwidth as well as regular shoppers?
Yes 21.43 %
No 78.57 %
In retrospect, this question may have been slightly confusing.
However, the result is very encouraging. Not as many people are
against the idea as I thought would be. I expected more of a 50/50
split here.
xiii
Appendix B
Business Perspectives
Do you think free public wifi could be good for business in
Dundalk?
Yes 100% A great response from real business owners in the area
No
xiv
Would you be interested in a Location Aware smartphone app
to help promote your business on the network? For example,
alert passers by to a sale inside the shop. This would be
possible with this kind of network.
Yes 100%
No
REALLY unexpected, but again, very encouraging. Something
worth further investigation.
xv
Appendix B
Given you are interested in the app idea, would you pay a
small fee for it?
Yes 78.57 %
No 21.43 %
A surprisingly high percentage would pay for the app, possibly
funding the development phase of such a product
xvi
Appendix B
Appendix B
If you had a large premises, or multiple stories, would you be
interested in buying multiple mesh units to provide full
coverage to your business?
Yes 42.86%
No 50%
Not Sure 7.14 %
Exactly 50% of users would NOT buy and host more than one
mesh unit if their premises was big enough. Of the 7.14% not
sure, I feel they would say YES if actually faced with the scenario
xvii
The Future
Would you be interested in free business-to-business phone
calls to within the mesh?
Yes 71.43 %
No 28.57 %
I thought this might be higher, but it's a promising number
xviii
Appendix B
If you were not previously convinced about the mesh network,
would the above free phone calls help sway your opinion?
Yes 50% An interesting split on this last question
No 50%
xix
Appendix B
References
References
'From Applications to ROI: System Architecture for Wireless Meshes - Farpoint
Group, Whitepaper', SearchTelecom. 2007. Available:
http://media.techtarget.com/searchNetworking/downloads (5 Nov. 2011)
'How Wireless Mesh Networks Work' 20 June 2007. Available:
http://computer.howstuffworks.com/how-wireless-mesh-networks-work.htm (10 Nov.
2011)
'Wireless Mesh Topology' November 2010. Available:
http://www.moskaluk.com/Mesh/wireless_mesh_topology.htm (20 Nov. 2011)
'Smartdust' October 2010. Available: http://en.wikipedia.org/wiki/Smart_dust (8 Dec.
2011)
Raniwala. A. and Chiueh, T. (2003) 'Deployment Issues in Enterprise Wireless LANs'.
Stony Brook University, NY
Hossain, E., and Leung, K. (eds), 2007, 'Wireless Mesh Networks Architectures and
Protocols'. New York, Springer
Gungor, V.C., Natalizio, E., Pace. P and Avallone S. (2007) Hossain, E., and Leung,
K. (eds), 'Wireless Mesh Networks Architectures and Protocols'. New York, Springer.
P24-50
Huang. J.-H., Wang. L.C., and Chang. C.J. (2007) Hossain, E., and Leung, K. (eds),
'Wireless Mesh Networks Architectures and Protocols'. New York, Springer. p51-78
Sayegh A., Todd, T. and Smadi, M (2007) Hossain, E., and Leung, K. (eds), 'Wireless
Mesh Networks Architectures and Protocols'. New York, Springer. P188-210
Zhang. W., Wang. Z., Das. S.K. and. Hassan. M. (2007) Hossain, E., and Leung, K.
(eds), 'Wireless Mesh Networks Architectures and Protocols'. New York, Springer.
P188-210
Koksal. C.E, (2007) Hossain, E., and Leung, K. (eds), 'Wireless Mesh Networks
Architectures and Protocols'. New York, Springer. P247-265
Vasseur, J.-P., and Dunkels, A. (2010) 'Interconnecting smart objects with IP: The
next Internet'. Burlington MA, Morgan Kaufmann Publishers/Elsevier
Akyildiz, I., Wang, X. and Wang, W. (2005) 'Wireless mesh networks: a survey'.
Computer Networks, Vol 47, Issue 4, p. 445-487
Muogilim, O., Loo, K. and Comley, R., (2011) 'Wireless mesh network security: A
traffic engineering management approach'. Journal of Network and Computer
Applications, Vol 34, Issue 2, p. 478-491
Pal, A. and Nasipuri A., (2011) 'A quality based routing protocol for wireless mesh
networks'. Pervasive and Mobile Computing, Vol 7, Issue 5, p. 611-626
References
Kim, J., Sridhara, V. and Bohacek, S. (2009) 'Realistic mobility simulation of urban
mesh networks'. Ad Hoc Networks, Vol 7, Issue 2, p. 411-430
Kandikattu, R. and Jacob, L. (2008) 'A Secure IPv6-based Urban Wireless Mesh
Network (SUMNv6)'. Computer Communications, Vol 31, Issue 15, p. 3707-3718
Jun. J. and Mihail, S. (2008) 'MRP: Wireless mesh networks routing protocol'.
Computer Communications, Vol 31, Issue 7, p. 1413-1435
Hafslund. A., Tønnesen, A.,Rotvik. R.B., Andersson. J. and Øivind. K. (2004) 'Secure
Extension to the OLSR protocol'. OLSR Interop and Workshop
Johnson, D., Ntlatlapa, N. and Aichele, C. (2008) 'Simple pragmatic approach to
mesh routing using BATMAN'. 2nd IFIP International Symposium on Wireless
Communications and Information Technology in Developing Countries, CSIR,
Pretoria, South Africa, 6-7 October, pp 10
Gkelias . A. and Sharma, S. (2012) 'Performance Evaluation of BATMAN, DSR,
OLSR Routing Protocols - A Review'. International Journal of Emerging Technology
and Advanced Engineering, Vol 2, Issue 1, p. 184-188
Raniwala. A. and Leung , K.K. (2008) 'Multiple Antenna Techniques for Wireless
Mesh Networks '. Department of Electrical and Electronic Engineering , Imperial
College , London
Jun. J. and Sichitiu , M.L. (2008) 'MRP: Wireless Mesh Networks Routing Protocol'.
Department of Electrical and Computer Engineering , North Carolina State University
, Raleigh
Johnson. D., Matthee. K., Sokoya. D., Mboweni. L., Makan. A. and Kotze. H. (2007)
'Building a Rural Wireless Mesh Network - A do-it-yourself guide to planning and
building a Freifunk based mesh network'. Wireless Africa, Meraka Institute, South
Africa
'L.A. mayor wants citywide wireless access' 20 June 2007. Available:
http://articles.latimes.com/2007/feb/14/business/fi-wifi14 (2 April. 2012)
'Concession to Provide WiFi Services in Dublin City', Dublin City Council. 2012.
Available: http://www.etenders.gov.ie (18 April 2012)
Glossary
Glossary
Although by no means a complete list, these technical terms were used in the project and
some of them may need further explanation or clarification.
Most of the following definitions were taken from http://www.wikipedia.org, a free online
encyclopedia built collaboratively using wiki software, and http://www.webopedia.com, a
combined online computer dictionary and Internet search engine for technical support
personnel.
802.11a
IEEE 802.11a-1999 or 802.11a is an amendment to the IEEE 802.11 specification that
added a higher data rate of up to 54 Mbit/s using the 5 GHz band. It has seen
widespread worldwide implementation, particularly within the corporate workspace.
The amendment has been incorporated into the published IEEE 802.11-2007 standard.
802.11b
IEEE 802.11b-1999 or 802.11b, is an amendment to the IEEE 802.11 specification that
extended throughput up to 11 Mbit/s using the same 2.4 GHz band. This specification
under the marketing name of Wi-Fi has been implemented all over the world. The
amendment has been incorporated into the published IEEE 802.11-2007 standard.
802.11g
IEEE 802.11g-2003 or 802.11g is an amendment to the IEEE 802.11 specification that
extended throughput to up to 54 Mbit/s using the same 2.4 GHz band as 802.11b. This
specification under the marketing name of Wi-Fi has been implemented all over the
world. The 802.11g protocol is now Clause 19 of the published IEEE 802.11-2007
standard.
802.11n
IEEE 802.11n-2009 is an amendment to the IEEE 802.11-2007 wireless networking
standard to improve network throughput over the two previous standards—802.11a
and 802.11g - with a significant increase in the maximum net data rate from 54 Mbit/s
to 600 Mbit/s (slightly higher gross bit rate including for example error-correction
codes, and slightly lower maximum throughput) with the use of four spatial streams at
a channel width of 40 MHz.
802.1X
IEEE 802.1X is an IEEE Standard for port-based Network Access Control (PNAC). It is
part of the IEEE 802.1 group of networking protocols. It provides an authentication
mechanism to devices wishing to attach to a LAN or WLAN.
Ad-Hoc
The term ad hoc networking typically refers to a system of network elements that
combine to form a network requiring little or no planning.
AES
Advanced Encryption Standard (AES) is a specification for the encryption of electronic
data. It has been adopted by the U.S. government and is now used worldwide.
ARP
Address Resolution Protocol (ARP) is a telecommunications protocol used for
resolution of network layer addresses into link layer addresses
Co-Op
A cooperative (also co-operative or co-op) is an autonomous association of persons
who voluntarily cooperate for their mutual social, economic, and cultural benefit.
Daemon
In Unix and other multitasking computer operating systems, a daemon is a computer
program that runs as a background process, rather than being under the direct control
of an interactive user.
DHCP
The Dynamic Host Configuration Protocol (DHCP) is a network configuration protocol
for hosts on Internet Protocol (IP) networks. Computers that are connected to IP
networks must be configured before they can communicate with other hosts. The most
essential information needed is an IP address, and a default route and routing prefix.
DNS
The Domain Name System (DNS) is a hierarchical distributed naming system for
computers, services, or any resource connected to the Internet or a private network.
Ethernet
Ethernet is a family of computer networking technologies for local area networks
(LANs) commercially introduced in 1980. Standardized in IEEE 802.3, Ethernet has
largely replaced competing wired LAN technologies. Systems communicating over
Ethernet divide a stream of data into individual packets called frames. Each frame
contains source and destination addresses and error-checking data so that damaged
Glossary
data can be detected and re-transmitted.
Firmware
In electronic systems and computing, firmware is a term often used to denote the fixed,
usually rather small, programs and/or data structures that internally control various
electronic devices.
FTP
Short for File Transfer Protocol, the protocol for exchanging files over the Internet. FTP
works in the same way as HTTP for transferring Web pages from a server to a user's
browser and SMTP for transferring electronic mail across the Internet in that, like these
technologies, FTP uses the Internet's TCP/IP protocols to enable data transfer.
GNU
The GNU General Public License (GNU GPL or simply GPL) is the most widely used
free software license, originally written by Richard Stallman for the GNU Project. The
GPL is the first copyleft license for general use, which means that derived works can
only be distributed under the same license terms. Under this philosophy, the GPL
grants the recipients of a computer program the rights of the free software definition
and uses copyleft to ensure the freedoms are preserved, even when the work is
changed or added to.
Hello
OLSR makes use of "Hello" messages to find its one hop neighbors and its two hop
neighbors through their responses. The sender can then select its multipoint relays
(MPR) based on the one hop node that offers the best routes to the two hop nodes.
HTTP
Short for HyperText Transfer Protocol, the underlying protocol used by the World Wide
Web. HTTP defines how messages are formatted and transmitted, and what actions
Web servers and browsers should take in response to various commands.
Internet
The Internet is a global system of interconnected computer networks that use the
standard Internet protocol suite (often called TCP/IP, although not all protocols use
TCP) to serve billions of users worldwide. It is a network of networks that consists of
millions of private, public, academic, business, and government networks, of local to
global scope, that are linked by a broad array of electronic, wireless and optical
networking technologies.
Joomla
Joomla (Joomla!) is a free and open source content management system (CMS) for
publishing content on the World Wide Web and intranets.
LAN
A local area network (LAN) is a computer network that interconnects computers in a
limited area such as a home, school, computer laboratory, or office building. The
defining characteristics of LANs, in contrast to wide area networks (WANs), include
their usually higher data-transfer rates, smaller geographic area, and lack of a need for
leased telecommunication lines.
Linux
A Unix-like computer operating system assembled under the model of free and open
source software development and distribution. The defining component of Linux is the
Linux kernel, an operating system kernel first released October 5, 1991 by Linus
Torvalds.
LTE
3GPP Long Term Evolution, referred to as LTE and marketed as 4G LTE, is a standard
for wireless communication of high-speed data for mobile phones and data terminals.
The LTE wireless interface is incompatible with 2G and 3G networks, so that it must be
operated on a separate wireless spectrum.
MAC
The media access control (MAC) data communication protocol sub-layer, also known
as the medium access control, is a sublayer of the data link layer specified in the
seven-layer OSI model (layer 2). It provides addressing and channel access control
mechanisms that make it possible for several terminals or network nodes to
communicate within a multiple access network that incorporates a shared medium, e.g.
Ethernet.
MANET
A mobile ad-hoc network (MANET) is a self-configuring infrastructureless network of
mobile devices connected by wireless links.
Megabit
When used to described data transfer rates, a megabit refers to one million bits.
Networks are often measured in megabits per second, abbreviated as Mbps.
Mesh
A wireless mesh network (WMN) is a communications network made up of radio nodes
organized in a mesh topology.
MIPS
MIPS (originally an acronym for Microprocessor without Interlocked Pipeline Stages) is
Glossary
a reduced instruction set computer (RISC) instruction set architecture (ISA) developed
by MIPS Technologies (formerly MIPS Computer Systems, Inc.). The early MIPS
architectures were 32-bit, and later versions were 64-bit.
MPR
Multi Point Relays are nodes in wireless Ad-Hoc networks that do the job of relaying
messages between nodes, they also have the main role in routing and selecting the
proper route from any source to any desired destination node.
Ms-Chapv2
MS-CHAP is the Microsoft version of the Challenge-Handshake Authentication
Protocol, CHAP. MS-CHAPv2 was introduced with Windows NT 4.0 SP4 and was
added to Windows 98 in the "Windows 98 Dial-Up Networking Security Upgrade
Release" and Windows 95 in the "Dial Up Networking 1.3 Performance & Security
Update for MS Windows 95" upgrade. Windows Vista dropped support for MSCHAPv1.
MySQL
Relational database management system (RDBMS) that runs as a server providing
multi-user access to a number of databases.
OLSR
The Optimized Link State Routing Protocolis an IP routing protocol optimized for
mobile ad-hoc networks, which can also be used on other wireless ad-hoc networks.
PEAP
The Protected Extensible Authentication Protocol, also known as Protected EAP or
simply PEAP, is a protocol that encapsulates the Extensible Authentication Protocol
(EAP) within an encrypted and authenticated Transport Layer Security (TLS) tunnel.
PHP
PHP is A Server-side HTML embedded scripting language. It provides web developers
with a full suite of tools for building dynamic websites.
Proxy
A proxy server is a server (a computer system or an application) that acts as an
intermediary for requests from clients seeking resources from other servers.
QR Code
QR is short for Quick Response. QR codes are used to take a piece of information
from a transitory media and put it quicly in your smartphone. The reason why they are
more useful than a standard barcode is that they can store (and digitally present) much
more data, including url links, geo coordinates, and text. Generally a QR Reader app is
required on the device in order to scan the QR code.
Radius
Remote Authentication Dial In User Service (RADIUS) is a networking protocol that
provides centralized Authentication, Authorization, and Accounting (AAA) management
for computers to connect and use a network service.
Router
A router is a device that forwards data packets between computer networks, creating
an overlay internetwork .
RSS
RSS (Rich Site Summary) is a format for delivering regularly changing web content.
Many news-related sites, weblogs and other online publishers syndicate their content
as an RSS Feed to whoever wants it.
SMTP
Short for Simple Mail Transfer Protocol, a protocol for sending e-mail messages
between servers. Most e-mail systems that send mail over the Internet use SMTP to
send messages from one server to another; the messages can then be retrieved with
an e-mail client using either POP or IMAP.
SPI
In computing, any firewall that performs stateful packet inspection is a firewall that
keeps track of the state of network connections (such as TCP streams, UDP
communication) traveling across it. The firewall is programmed to distinguish legitimate
packets for different types of connections. Only packets matching a known active
connection will be allowed by the firewall; others will be rejected.
SSH
Secure Shell (SSH) is a network protocol for secure data communication, remote shell
services or command execution and other secure network services between two
networked computers that it connects via a secure channel over an insecure network:
a server and a client (running SSH server and SSH client programs, respectively).
SSID
Service set identifier, a 32-character unique identifier attached to the header of packets
before transmission over a wireless network, ensuring only authorised devices can
connect.
Glossary
SSL
Short for Secure Sockets Layer, a protocol developed by Netscape for transmitting
private documents via the Internet. SSL uses a cryptographic system that uses two
keys to encrypt data − a public key known to everyone and a private or secret key
known only to the recipient of the message.
Switch
A network switch or switching hub is a computer networking device that connects
network segments or network devices.
TCO
Abbreviation of Total Cost of Ownership, a very popular buzzword representing how
much it actually costs to own something (usually IT equipment). Most estimates place
the TCO at about 3 to 4 times the actual purchase cost of the hardware.
Telnet
A terminal emulation program for TCP/IP networks such as the Internet. The Telnet
program runs on your computer and connects your PC to a server on the network. You
can then enter commands through the Telnet program and they will be executed as if
you were entering them directly on the server console.
TKIP
Temporal Key Integrity Protocol or TKIP is a security protocol used in the IEEE 802.11
wireless networking standard. TKIP was designed by the IEEE 802.11i task group and
the Wi-Fi Alliance as a solution to replace WEP without requiring the replacement of
legacy hardware. TKIP uses the same underlying mechanism as WEP, and
consequently is vulnerable to a number of similar attacks.
TLS
Transport Layer Security and its predecessor, Secure Sockets Layer (SSL), are
cryptographic protocols that provide communication security over the Internet.
W-Fi
Wi-Fi (sometimes spelled Wifi or WiFi) is a popular technology that allows an electronic
device to exchange data wirelessly (using radio waves) over a computer network,
including high-speed Internet connections. The Wi-Fi Alliance defines Wi-Fi as any
"wireless local area network (WLAN) products that are based on the Institute of
Electrical and Electronics Engineers' (IEEE) 802.11 standards". However, since most
modern WLANs are based on these standards, the term "Wi-Fi" is used in general
English as a synonym for "WLAN".
WDS
A wireless distribution system (WDS) is a system enabling the wireless interconnection
of access points in an IEEE 802.11 network. It allows a wireless network to be
expanded using multiple access points without the traditional requirement for a wired
backbone to link them.
WEP
Wired Equivalent Privacy (WEP) is a security algorithm for IEEE 802.11 wireless
networks. Introduced as part of the original 802.11 standard ratified in September
1999, its intention was to provide data confidentiality comparable to that of a traditional
wired network. WEP, recognizable by the key of 10 or 26 hexadecimal digits, is widely
in use and is often the first security choice presented to users by router configuration
tools.
WiMAX
WiMAX (Worldwide Interoperability for Microwave Access) is a wireless
communications standard designed to provide 30 to 40 megabit-per-second data rates,
with the 2011 update providing up to 1 Gbit/s for fixed stations. It is a part of a “fourth
generation,” or 4G, of wireless-communication technology.
WMN
A wireless mesh network (WMN) is a communications network made up of radio nodes
organized in a mesh topology.
WPA2
WPA2, which supersedes WPA, is a security protocol and security certification program
developed by the Wi-Fi Alliance to secure wireless computer networks. WPA2
implements the mandatory elements of IEEE 802.11i. In particular, it introduces CCMP,
a new AES-based encryption mode with strong security.

A blueprint for low cost urban wifi based on mesh technology

Transcription

Similar documents

BUSHIDO

Desara® Sling System

87- Tank Leotard w/Mesh Back Boatneck Leotard

-33- Contrast Double Layer Skirt Tank Leotard w/Mesh Back

Portable Mesh Nebulizer

Stillage Mesh Cage

Venus 5 W 232524

Clear Vu Brochure