PROJECT INTERIM REPORT 2 EEL 5718 – COMPUTER COMMUNICATIONS
Implementation of Wireless Mesh Network using
Alpine Linux
Neeraj Poddar, Komal Kasat
Department of Electrical & Computer Engineering, University of Florida, Gainesville
Abstract - A wireless mesh network (WMN) is a
communications network made up of radio nodes
organized in a mesh topology. Mesh topology is a type of
networking wherein each node in the network may act as
an independent router, regardless of whether it is
connected to another network or not. It allows for
continuous connections and reconfiguration around
broken or blocked paths by “hopping” from node to node
until the destination is reached. In this project we intend to
implement a wireless mesh network by configuring Alpine
Linux on a laptop as a mesh node for wireless clients. This
will enable the users in vicinity to connect to the network
wirelessly and gain access to internet.
I. INTRODUCTION
In a wireless mesh network, the network connection is
spread out among dozens or even hundreds of wireless mesh
nodes that "talk" to each other to share the network
connection across a large area. Mesh nodes are small radio
transmitters that function in the same way as a wireless
router. Nodes use the common WiFi standards known as
802.11a, b and g to communicate wirelessly with users, and,
more importantly, with each other. Each node operates not
only as a host but also as a router, forwarding packets on
behalf of other nodes that may not be within direct wireless
transmission of their destination. The biggest advantage of
wireless mesh networks as opposed to wired or fixed
wireless networks is that they are truly wireless. Most
traditional wireless access points still need to be wired to the
Internet to broadcast their signal. In a wireless mesh
network, only one node needs to be physically wired to a
network connection. That one wired node then shares its
Internet connection wirelessly with all other nodes in its
vicinity and hence the network grows.
II. Fig.1 PROTOCOLS
Wireless Mesh Network
STUDIED
There are a large number of protocols that can be
implemented in mesh networking depending on the goals
and design criteria. The most common protocols, standards
and systems in the field of wireless mesh networks are
briefly described below:
AODV - Ad hoc On Demand Distance Vector:
It is routing protocol designed for ad hoc mobile networks.
It builds routes between nodes only as desired by source
nodes and hence it’s an on demand algorithm. It maintains
these routes as long as they are needed by the sources.
AODV builds routes using a route request / route reply
query cycle. When a source node desires a route to a
destination for which it does not already have a route, it
broadcasts a route request (RREQ) packet across the
network. Nodes receiving this packet update their
information for the source node and set up backwards
pointers to the source node in the route tables. In addition to
the source node's IP address, current sequence number, and
broadcast ID, the RREQ also contains the most recent
sequence number for the destination of which the source
node is aware. A node receiving the RREQ may send a route
reply (RREP) if it is either the destination or if it has a route
to the destination with corresponding sequence number
greater than or equal to that contained in the RREQ. If this is
the case, it unicasts a RREP back to the source. Otherwise, it
rebroadcasts the RREQ. Nodes keep track of the RREQ's
source IP address and broadcast ID. If they receive a RREQ
which they have already processed, they discard the RREQ
and do not forward it.
As the RREP propagates back to the source, nodes set up
forward pointers to the destination. Once the source node
receives the RREP, it may begin to forward data packets to
the destination. If the source later receives a RREP
containing a greater sequence number or contains the same
sequence number with a smaller hopcount, it may update its
routing information for that destination and begin using the
better route.
As long as the route remains active, it will continue to be
maintained. A route is considered active as long as there are
data packets periodically travelling from the source to the
destination along that path. Once the source stops sending
data packets, the links will time out and eventually be
deleted from the intermediate node routing tables. If a link
break occurs while the route is active, the node upstream of
the break propagates a route error (RERR) message to the
source node to inform it of the now unreachable
destination(s). After receiving the RERR, if the source node
still desires the route, it can reinitiate route discovery.
OLSR Protocol:
The OLSR Optimized Link State Routing Protocol is a
proactive link state protocol. Being a proactive protocol
implies periodically sending packets to maintain information
about the network topology. Also, link state implies that it
broadcasts the list of the neighbors over the network. So
basically all nodes are aware of the neighbors of all the
nodes and hence the entire topology is known. All the routes
being known the shortest path to the destination can be
determined.
OLSR Protocol uses two packets: “hello” packets and “TC”
packets. “Hello” packets are used to build the neighborhood
of a node and at the same time “hello” packets are used to
compute the “multipoint” relays of a node. Multipoint relay
will permit the broadcast. In this figure, we have shown a
node with its neighbors and its two hop neighbors. A two
hop neighbors of a node is a neighbor of its neighbors. This
is not an existing neighbor. To obtain a complete broadcast,
it is sufficient that the packet be repeated by a convenient
subset of its neighbor. This subset must be computed in such
a way that all the two hop neighbor receive the packet. If
this requirement is achieved, it can be shown by induction
that a complete broadcast is obtained. Actually, this
technique provides a way to locally compute a spanning
tree.
The “TC” packets are sent periodically by a node. This
packet contains the list of its multipoint relay i.e. the subset
of nodes which make it possible to cover all its two hop
nodes. The “TC” packets are sent in broadcast and with the
multipoint relay rule only the multipoint relay nodes will
retransmit the packet. A sequence number is used to avoid
loops due to infinite retransmission of the packet. Another
field is used to allow knowing which of two “TC” packets is
the more up-to-date. Although a node does not send its
entire neighborhood in the “TC” packet, it can be shown that
this information is sufficient to build a topology of the net.
Fig.2 OLSR Protocol
MMRP Mobile Mesh Routing Protocol:
Mobile ad hoc networking allows users to exchange
information in a wireless environment without the need for a
fixed infrastructure. Each user (or node), equipped with one
or more radios, is free to roam about while communicating
with others. The path between any pair of users can traverse
multiple wireless links and the radios themselves can be
heterogeneous, thus enabling an assortment of different
types of links to be part of the same adhoc network.
The mobility of the nodes results in a network whose
topology is dynamic. The job of the network is to discover
the links between the mobile nodes and to build paths so that
any user can communicate with any other user, as long as
each has a link to the ad hoc network. Within the ad hoc
network, each node acts as a router and forwards packets on
behalf of others.
Mobile Mesh protocol contains three separate protocols,
each addressing a specific function:
1. Link Discovery
It is based on the “hello” protocol. Each interface
running the protocol periodically broadcasts a Hello
message containing its interface address and the addresses of
the interfaces that it has heard Hello messages from in the
previous period. This is sufficient for a node's interface to
discover all links incident to it as well as bidirectional links.
The Mobile Mesh Link Discovery Protocol (MMLDP)
provides a media independent mechanism for discovering
neighbors in a mobile adhoc network, and is capable of
determining whether links are unidirectional or
bidirectional. MMLDP is one protocol in a set of related
Mobile Mesh protocols that also includes the Mobile Mesh
Routing Protocol (MMRP) and the Mobile Mesh Border
Discovery Protocol (MMBDP). Together, these protocols
provide a flexible, extensible mobile adhoc networking
capability.
The Mobile Mesh Link Discovery Protocol (MMLDP)
enables wireless nodes to learn of neighbors on a per IP
interface basis. Link discovery in a mobile adhoc network
can be accomplished through several alternative
mechanisms; however, MMLDP provides a simple straight
forward approach and is independent of media type.
MMLDP detects when an interface has a new neighbor and
when a neighbor is no longer present. These events can then
be utilized by other protocols and software running on the
node such as those performing mobile adhoc routing.
Additionally, MMLDP is able to determine whether a link is
bidirectional or uni-directional, thus enabling an adhoc
routing protocol to leverage uni-directional links if desired.
By keeping the functions of link discovery and adhoc
routing separate, we enable flexibility and extensibility. For
example, an alternative mechanism for discovering links
could be implemented without causing changes to the adhoc
routing protocol. Alternatively, the same link discovery
mechanism, such as MMLDP, could be utilized by several
different adhoc routing protocols.
2. Routing
MMRP is based upon the link state approach and allows us
to build least cost paths between any source and
destination. Each "Link State Packet" (LSP) contains
various information including a unique router id and a list of
lists that contains each local interface address and a list of
the neighbor interface addresses which have links to it and
their corresponding costs. Also in the LSP are a list of
"External Route Advertisements" which enable the node to
advertise routes into the mobile cloud. One use of this is to
allow routers that have a wired connection to a fixed
network to advertise a default route for the mobile nodes.
Thus, we provide a mechanism for allowing mobile nodes to
gain external connectivity. Also, this mechanism can be
used by a wireless router to advertise a route for a collection
of hosts which are directly connected to it.
The Mobile Mesh Routing Protocol (MMRP) is a robust,
scalable, efficient mobile adhoc routing protocol based upon
the "link state" approach. MMRP is one protocol in a set of
related Mobile Mesh protocols that also includes the Mobile
Mesh Link Discovery Protocol (MMLDP) and the Mobile
Mesh Border Discovery Protocol (MMBDP). Together,
these protocols provide a flexible, extensible mobile adhoc
networking capability.
The Mobile Mesh Routing Protocol (MMRP) is a robust,
scalable, and efficient mobile adhoc routing protocol based
upon the "link state" approach. A node periodically
broadcasts its own Link State Packet (LSP) on each
interface participating in the protocol. LSP's are relayed by
nodes, thus allowing each node to have full topology
information for the entire adhoc network. From its topology
database, a node is able to compute least cost unicast routes
to all other nodes in the mobile adhoc network.
An LSP indicates for each interface on the router, the
addresses of neighbor interfaces that have links to it, and the
associated cost of these links. Also in the LSP are a list of
"External Route Advertisements" which enable the node to
advertise routes into the mobile adhoc cloud for destinations
that are "outside" of the mobile adhoc cloud. One use of
this mechanism is to allow routers possessing a wired
connection to a fixed network to advertise a default route.
This provides a mechanism for allowing mobile nodes to
gain external connectivity. Also, this mechanism can be
used by a wireless router to advertise a route for a collection
of hosts which are directly connected to it.
To enhance scalability, MMRP performs a technique known
as fish-eye routing in which the resolution of a node's map
of the network decreases as a function of hop distance from
the node. This is achieved by decreasing the rate at which
LSP's propagate across the network as they get farther away
from their source. This effectively decreases the overhead
associated with disseminating topology information. Also,
this allows more recent LSP's to "catch up" and overwrite
older LSP's as they propagate.
3. Border Discovery
Mobile Mesh Border Discovery Protocol (MMBDP) is a
novel mechanism that enables flow existing outside the
mobile cloud to be utilized. Other approaches to mobile ad
hoc networking ignore this possibility.
If two or more nodes in a mobile adhoc network each have a
connection into a fixed network (let's call these nodes
"border" routers), then the opportunity exists for mobile
nodes to communicate with other mobile nodes across the
fixed network. This can be accomplished by setting up
tunnels between the border routers across the fixed
network. The Mobile Mesh Border Discovery Protocol
(MMBDP) is intended to run on a wired (or fixed network)
interface and enables a border router to discover other
border routers. This information can then be used to setup
tunnels amongst the border routers. These tunnels can then
be leveraged by a mobile adhoc routing protocol to
disseminate topology information as well as to forward
packets.
MMBDP is one protocol in a set of related Mobile Mesh
protocols that also includes the Mobile Mesh Link
Discovery Protocol (MMLDP) and the Mobile Mesh
Routing Protocol (MMRP). Each of these are described in
separate Internet Drafts. An aesthetically pleasing aspect of
these protocols is that they each contain only a single
message type. This form of simplicity, we believe, will
enable others to easily understand and implement the
protocols. The process of setting up a tunnel with a peer
creates a new IP interface on a border router; this interface is
a point-to-point tunnel interface that tunnels all packets sent
on it to the peer.
After discovering a peer and setting up a tunnel to it, an
implementation of MMBDP starts the Mobile Mesh Link
Discover Protocol on the tunnel interface. MMBDP then
adds the tunnel interface to the Mobile Mesh Routing
Protocol. The tunnel interface appears to MMLDP and
MMRP to be just another IP interface; the fact that it is a
tunnel interface is not exposed. MMLDP discovers "virtual
links" from the tunnel interfaces of other border routers and
reports them and their associated costs to MMRP. MMRP
includes in its LSP the IP address of the tunnel interface and
its associated links and link costs. Thus, MMRP computes
least cost paths that can include both wireless links and
"virtual links".
By configuring MMLDP to report the cost of the "virtual
links" to be much less than the cost of a wireless link, routes
between wireless nodes that traverse the wired/fixed
network will be preferred over those that don't. Thus, the
goal of offloading traffic from the bandwidth constrained
wireless links to the higher capacity wired links is achieved.
SOFTWARE TOOLS:
1. mmdiscover − Mobile Mesh Link Discovery
mmdiscover speaks the Mobile Mesh Link Discovery
Protocol on an individual IP interface and reports neighbor
interface addresses and associated costs for any discovered
links. Links that go down are also detected and reported.
Client programs may receive link reports by connecting to a
well-known Unix socket created by mmdiscover whose
name is based upon the name of the IP interface prepended
with "ln-". For example, if mmdiscover is bound to interface
"eth0", the well-known Unix socket name will be "ln-eth0".
mmdiscover does not have prior knowledge of potential
clients. Clients simply send a message asking for the current
list of links. This allows mmdiscover to dynamically learn
who its clients are. Then, when a link goes up or down, it
sends the event to all clients who have previously requested
a list of links. A failure when sending an event to a client
implies that the client has stopped listening and thus
mmdiscover removes the client from its dynamically
managed set of clients.
mmdiscover is responsible for determining when links go up
and down. Periodically, it broadcasts a Hello message on a
Udp socket bound to the IP interface. mmdiscover can be
configured to report either unidirectional or only bi-
directional links. The Hello message includes a list of the
interface addresses of the senders of Hello messages that
have been heard by the interface in the last DeadInterval .
If mmdiscover reports uni-directional links, then whenever it
receives a Hello from another node’s interface that it does
not have a link from, it reports the new link. If mmdiscover
only reports bi-directional links, then it checks a neighbor
list within the received Hello message for the address of the
interface that heard the Hello. Note, if mmdiscover is
configured to report bi-directional links, then it must report
that a link went down if it changes from bi-directional to
uni-directional; similarly, it reports that a link came up if it
changes from uni-directional to bi-directional. If a Hello
message for a link which is declared to be up is not received
within a DeadInterval , mmdiscover reports that the link is
down.
2. mmrp − Mobile Mesh Router
mmrp speaks the Mobile Mesh Routing Protocol on one or
more IP interfaces. It computes least cost unicast paths to all
other nodes within the Mobile Mesh cloud and modifies the
IP routing table accordingly. Interfaces and external route
advertisements may be specified in a config file or
dynamically.
mmrp learns of link events by connecting to the well known
Unix socket associated with each interface. A link discovery
program like mmdiscover must be running on an interface
prior to informing mmrp to use the interface.
To enhance scalability mmrp performs a technique called
fish-eye routing where the resolution of a node’s map of the
network is a function of distance. This reduces the overhead
associated with the flooding of LSP’s.
3. mmborder − Mobile Mesh Border Discovery
mmborder speaks the Mobile Mesh Border Discovery
Protocol. The goal of a border router is to take advantage of
"collateral flow" that occurs "external" to a Mobile Mesh
Routing Protocol cloud. This is accomplished by border
routers tunneling packets between peer border routers. A
tunnel is needed between each pair of members. The IP
addresses on the ends of the tunnels do not need to be
globally unique across the Internet, they only need to be
unique within the Mobile Mesh Routing Protocol cloud.
This enables us to use the private IP addresses of 10.X.X.X
and 192.168.X.X for the tunnels. Tunnels are set up
automatically by mmborder when it discovers a peer border
router. The discovery process requires each border router to
periodically send a BorderAdvertisement message to a
multicast group address. When a border hears from a new
peer, it sets up a point to point tunnel with it. When a border
has not heard from a peer within a deadInterval , it assumes
the peer has departed and tears down the tunnel. Under
Linux, each tunnel results in a unique IP interface. When a
tunnel is created, mmborder dynamically adds the
corresponding IP interface to the mobile mesh router mmrp.
Similary, when the tunnel is destroyed, mmborder
dynamically removes the IP interface from the mobile mesh
router.
III. Configuring Alpine to connect to Wireless
networks
We have been able to configure wireless on alpine to
connect to available networks via network authentication
and WPA encryption.
Alpine Linux comes with minimum packages installed so to
enable the wireless interface some drivers and packages
needs to be installed. The steps for configuring Alpine to act
as a wireless client are:-
1. Install the drivers if alpine 1.10 is not able to recognize
the wireless NIC. Once the NIC is identified as wlan0
or eth1 check with ifconfig command to see if any of
the devices have a wireless interface.
2. Then the wireless_tools package needs to be installed.
This package contains all the wireless utility
commands like iwconfig, iwlist. The command for
adding wireless_tools is :-
apk add wireless_tools
3. The interfaces file needs to be updated to connect to a
wireless network and setup the wlan0
Edit /etc/network/interfaces to:-
auto wlan0
iface wlan0 inet dhcp
pre-up iwconfigwlan0 essid NetworkName
pre-up iwconfig wlan0 key password
pre-up iwconfig wlan0 channel 11
pre-up iwconfig wlan0 mode managed
4. Set the wlan0 up by typing the command
ip link set wlan0 up
5. Restart the networking /etc/init.d/networking restart
6. The iwlist command is used to list the available
wireless networks.
iwlist wlan0 scanning
You can choose any network listed and set the essid to the
specific network’s essid and connect to it if it has WEP
encryption or if it is a public network with no encryption.
To connect to a network with WPA encryption the following
setup needs to be done:-
a. The wpa_supplicant needs to be installed in order to
enable WPA encryption
apk add wpa_supplicant
b. Bring the link up by typing the command
ip link set wlan0 up
c. After setting the essid we need to create a shared key
for wpa_supplicant
wpa_passphrase essid> wpa.conf
 It will wait for the password from stdin. Enter the
password and enter. Now you will have a wpa.conf file
with the preshared key.
d. Start wpa_supplicant with the generated configuration:
Wpa_supplicant – Dwext –iwlan0-c ./wpa.conf
e. From another console, start dhcpd
dhcpd wlan0
You will get an IP address after this.
Creating Ad-hoc Connection in Alpine
Once all the packages and tools are installed to connect
alpine to a wireless network it can be configured to work in
adhoc mode. The following lines of code are to be put in the
interfaces to make it work in adhoc mode:-
auto wlan0
iface wlan0 inet static
address 192.168.1.10
netmask 255.255.255.0
pre-up iwconfig mode ad-hoc
pre-up iwconfig essid AdhocConnectionName
pre-up iwconfig key off
This has to be put in the interfaces of all the laptops that
have to be in adhoc with different ip addresses. Then once
the wlan0 was up in all they were able to ping each other.
For implementing the mesh protocol we have used
mobile mesh protocol as described above. The steps to
implement the same are:
a. Download the Mobile mesh protocol from mitre.org and
untar it. The compilation required g++ so apk add build-
base was added which has all the packages for g++.
While trying to compile it was giving errors because
some of the headers were out-of-date. The headers were
edited in the files and then the files compiled according
to the instructions in the INSTALL file. Then the
mmrp.conf file needs to be configured with the correct
interface (in our case wlan0) that would be used to build
the ad-hoc network.
b. The /etc/network/interfaces file needs to be changed as
follows:
auto wlan0
iface wlan0 inet static
address 10.X.X.X
netmask 255.255.255.0
broadcast 10.255.255.255
pre-up iwconfig mode ad-hoc
pre-up iwconfig essid mobilemesh
pre-up iwconfig channel 11
c. The same needs to be done on the other laptops. Make
sure that no two machines have the same IP address.
d. For starting the mesh the following command need to be
executed at the terminal
mmdiscover -i waln0 -z &
mmrp
The two laptops are now successfully in a mesh network.
To check the routing tables use the command:
netstat –nr
Testing the Mesh Network
We checked the working of mesh by taking 3 laptops and
running mobile mesh on all the three. In the beginning all
the three laptops were connected in adhoc mode so all were
able to ping each other. Then we moved one laptop far away
so that it is not in direct link with the first laptop but is
connected to the second laptop in adhoc mode. This laptop
was able to ping the first laptop via the second laptop and
when we see the routing tables it gets updated showing the
second laptop as gateway to the first laptop which proves
that mesh is working properly. As the mesh was working
properly now we tried to give internet connection to the
other laptops connected in mesh.
Internet
Wired
connection to
the internet
A
Wireless connection from
B to A and C to A via B
B
C
Fig 3. Laptops A, B and C are in adhoc mode.
Laptop A is connected to the internet using
LAN wire. Laptop B is connected to A in
wireless manner. C is in B’s range and so is
connected to A via B.
Configuring Internet Connections for all nodes
Once the mesh is working now we tried sharing the internet
connection from one of the laptops to all other nodes in
network.
For this we configured one laptop to have both eth0 and
wlan0 and edited the mmrp.conf file to add the following
lines:-

external <ip address> <netmask> <metric>
external 0.0.0.0 255.255.255.0 7
This will create a gateway and advertise it for all other
nodes on the network. We tried this method but were not
able to connect to internet from any of the other laptops.
Then we tried changing the netmask to 0.0.0.0. The ping
command was able to route through our mesh but was not
able to receive any packets back. We are presently working
on it to configure the mesh so that all the nodes in the
network can access internet via the first laptop.
For getting the internet to work in other nodes we also tried
to bridge the wired and wireless interfaces so that the
internet can be given to all other nodes via this bridged
network. For setting up the bridge connection we tried the
following setup:-
a. The package bridge-utils needs to be installed which
contains related utilities:
apk add bridge-utils
V. REFERENCES
[1] Simulation Results of the OLSR Routing Protocol for
Wireless Network - Anis Laouti, Paul Muhlethaler,
Abdellah Najid, Epiphane Plakoo
[2] Ian F. Akyildiz, Xudong Wang, Weilin Wang -
Wireless mesh networks: a survey
[3] Jangeun Jun and Mihail L. Sichitiu - The Nominal
Capacity of Wireless Mesh Networks
[4] S.M. Chen, P, Lin, D-W Huang, S-R Yang - A study
on distributed/centralized scheduling for wireless
mesh network
[5] http://redmine.alpinelinux.org/issues/341
[6] http://redmine.alpinelinux.org/issues/331
[7] http://www.wikipedia.org
[8] http://www.oreillynet.com/pub/a/wireless/2004/01/22/
wirelessmesh.html
[9] http://wiki.alpinelinux.org
[10] http://hipercom.inria.fr/olsr/#intro
[11] http://wiki.alpinelinux.org/w/index.php?title=
Connecting_to_a_wireless_accesspoint
[12] http://redmine.alpinelinux.org/issues/show/274

b. Modify the /etc/network/ interfaces file to:

auto br0
iface br0 inet dhcp
pre-up ip link set dev eth0 up
pre-up ip link set dev wlan0 up
pre-up iwconfig wlan0 mode ad-hoc
pre-up iwconfig wlan0 essid mesh
pre-up iwconfig wlan0 key off
bridge-ports eth0 wlan0
pre-down ip link set dev br0 down
down brctl delbr br0

But we were not successful in bridging the network.

IV. FUTURE WORK

We will try to get internet connection to all the nodes in the

mesh network. We will do this by either bridging the wired
internet with the wireless connection or by using the extern
command in mmrp in mobile mesh as described above. We
are also testing the mesh by using NETGEAR routers and
configuring them to build a mesh network in which multiple
nodes can join in and get internet access form one single
router connected to the internet. After these implementations
are complete, we would have configured Alpine Linux to
work as a mesh node or a client; and also tested and
configured the standard mesh products like NETGEAR to
develop the entire wireless mesh network.