PROJECT FINAL REPORT 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 STUDIED
Wireless Mesh Network
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 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 backward 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. In this 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 tunnel is created, mmborder dynamically adds the
implies that the client has stopped listening and thus corresponding IP interface to the mobile mesh router mmrp.
mmdiscover removes the client from its dynamically Similary, when the tunnel is destroyed, mmborder
managed set of clients. dynamically removes the IP interface from the mobile mesh
router.
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- III. Configuring Alpine to connect to Wireless
directional links. The Hello message includes a list of the networks
interface addresses of the senders of Hello messages that
have been heard by the interface in the last DeadInterval. If
We have been able to configure wireless on alpine to
mmdiscover reports uni-directional links, then whenever it
connect to available networks via network authentication
receives a Hello from another node’s interface that it does and WPA encryption.
not have a link from, it reports the new link. If mmdiscover
only reports bi-directional links, then it checks a neighbor
Alpine Linux comes with minimum packages installed so to
list within the received Hello message for the address of the
enable the wireless interface some drivers and packages
interface that heard the Hello. Note, if mmdiscover is
needs to be installed. The steps for configuring Alpine to act
configured to report bi-directional links, then it must report
as a wireless client are:-
that a link went down if it changes from bi-directional to
uni-directional; similarly, it reports that a link came up if it 1. Install the drivers if alpine 1.10 is not able to recognize
changes from uni-directional to bi-directional. If a Hello
the wireless NIC. Once the NIC is identified as wlan0
message for a link which is declared to be up is not received
or eth1 check with ifconfig command to see if any of
within a DeadInterval , mmdiscover reports that the link is
the devices have a wireless interface.
down.
2. Then the wireless_tools package needs to be installed.
This package contains all the wireless utility
2. mmrp − Mobile Mesh Router commands like iwconfig, iwlist. The command for
adding wireless_tools is :-
mmrp speaks the Mobile Mesh Routing Protocol on one or
more IP interfaces. It computes least cost unicast paths to all
apk add wireless_tools
other nodes within the Mobile Mesh cloud and modifies the
IP routing table accordingly. Interfaces and external route
3. The interfaces file needs to be updated to connect to a
advertisements may be specified in a config file or
wireless network and setup the wlan0
dynamically.
Edit /etc/network/interfaces to:-
mmrp learns of link events by connecting to the well known
Unix socket associated with each interface. A link discovery
auto wlan0
program like mmdiscover must be running on an interface
iface wlan0 inet dhcp
prior to informing mmrp to use the interface.
pre-up iwconfigwlan0 essid NetworkName
To enhance scalability mmrp performs a technique called
pre-up iwconfig wlan0 key password
fish-eye routing where the resolution of a node’s map of the
pre-up iwconfig wlan0 channel 11
network is a function of distance. This reduces the overhead
pre-up iwconfig wlan0 mode managed
associated with the flooding of LSP’s.
4. Set the wlan0 up by typing the command

ip link set wlan0 up

3. mmborder − Mobile Mesh Border Discovery
5. Restart the networking /etc/init.d/networking restart
mmborder speaks the Mobile Mesh Border Discovery
Protocol. The goal of a border router is to take advantage of
6. The iwlist command is used to list the available
"collateral flow" that occurs "external" to a Mobile Mesh
wireless networks.
Routing Protocol cloud. This is accomplished by border
routers tunneling packets between peer border routers. A
iwlist wlan0 scanning
tunnel is needed between each pair of members. The IP
addresses on the ends of the tunnels do not need to be
You can choose any network listed and set the essid to the
globally unique across the Internet, they only need to be
specific network’s essid and connect to it if it has WEP
unique within the Mobile Mesh Routing Protocol cloud.
encryption or if it is a public network with no encryption.
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
To connect to a network with WPA encryption the following
automatically by mmborder when it discovers a peer border
setup needs to be done:-
router. The discovery process requires each border router to
periodically send a BorderAdvertisement message to a
a. The wpa_supplicant needs to be installed in order to
multicast group address. When a border hears from a new
enable WPA encryption
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
apk add wpa_supplicant
the peer has departed and tears down the tunnel. Under
Linux, each tunnel results in a unique IP interface. When a
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 connected to internet 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:-
 We required our router connected to internet to
give out IP addresses as 192.168.254.X. The
default IP address given out is 192.168.1.X. For
changing this router’s setup has to be changed.
 The router’s default setup page is either
http://192.168.1.0 or http://routerlogin.com.

external <ip address> <netmask> <metric>  The page asks for an username & password which
external 0.0.0.0 255.255.255.0 7 is by default in all routers set to:-
This will create a gateway and advertise it for all other Login: admin
nodes on the network. We tried this method but were not Password: password
able to connect to internet from any of the other laptops.
Then we tried changing the netmask to 0.0.0.0. The ping
 The next step is to change the ip address send out
command was able to route through our mesh but was not
by router to 192.168.254.X from default
able to receive any packets back.
192.168.1.X. This is done by changing the LAN IP
default to 192.168.254.X in the menu options.
For getting the internet to work in other nodes we also tried
to bridge the wired and wireless interfaces so that the
 Then we can check by connecting to the router to
internet can be given to all other nodes via this bridged
see the ip addresses it is sending out whether they
network. For setting up the bridge connection we tried the
are in range.
following setup:-

a. The package bridge-utils needs to be installed which

contains related utilities:  Then one of the mesh routers is connected via
LAN cable to the router connected to ISP and the
other mesh network gear is just plugged in.
apk add bridge-utils

b. Modify the /etc/network/ interfaces file to:  Now we were able to connect to the mesh router
which is just powered and while trying to connect
auto br0 to internet it redirects to the default QCS Mesh
iface br0 inet dhcp login.
pre-up ip link set dev eth0 up
pre-up ip link set dev wlan0 up  Using the login and password provided we were
pre-up iwconfig wlan0 mode ad-hoc able to login in the QCS portal. Then the internet
pre-up iwconfig wlan0 essid mesh was working and we were able to connect many
pre-up iwconfig wlan0 key off laptops to this node and get the internet working in
bridge-ports eth0 wlan0 all of the laptops.
pre-down ip link set dev br0 down
down brctl delbr br0

But we were not successful in bridging the network.

We tried to get internet connection to all the nodes in the

mesh network. We tried bridging the wired internet with the
wireless connection like the method mentioned above. We
also tried using the extern command in mmrp in mobile
mesh as described before that. We found that the major
problem was using proper netmask and subnets so we tried a
number of combinations and netmasks. In one of these
combination the packet was able to route through and was
going out but was not able to come back to mesh terminal.
The router was not able to decide the path to be followed to
reach the mesh node as all the laptops were sitting behind Fig 4. Mesh Netgear network setup as
the router and Network Address Translation was used to implemented.
gain internet access.
 We then tried to see the network coverage of the
mesh router by moving the two nodes apart and
IV. NETGEAR MESH ROUTER SETUP see the internet connectivity. The nodes were
pretty far apart but still maintained the network
We tried to configure the Netgear routers given to establish connectivity.
the mesh network and connect to internet and provide
internet to clients not connected directly to internet router.
  We also checked the setup in Linux to look in the
routing tables to see the status of the gateways and
routes followed. We could see the intermediate
mesh router as the gateway for our mesh node.
V. PRACTICAL APPLICATION
Alpine Linux being fully configurable can be used to
develop a robust networking system. We can develop this to
build a wireless mesh network such that it could provide
internet connectivity to entire buildings, areas or even an
entire city may be connected in this way.
VII. 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=Connectin
g _to_a_wireless_accesspoint
[12] http://redmine.alpinelinux.org/issues/show/274

Fig 5. A Practical Wireless Mesh Network

Alpine Linux provides us with a platform which can be used

to set up and manage such a wireless mesh network in an
efficient and robust manner.

VI. CONCLUSION

In this project we were created a mesh network with Alpine

Linux and laptops with using any extra hardware. This was
accomplished by first enabling the wireless network
interface card in Alpine Linux and configuring it to connect
to wireless access points. Then we set up an adhoc
connection and tried connecting few laptops in adhoc mode
and ping each other wirelessly. Then we studied the Mobile
Mesh protocol and changed few of its headers to compile it
and run on our Alpine Linux box. The mesh network was
then established by running this protocol on all the laptops
and we verified the routing of traffic in mesh by seeing the
routing tables getting updated as the nodes moved their
positions. Then we tried to give internet connection to all
the nodes on network from one node connected to internet.
We have not been able to establish internet connectivity in
all the nodes by mesh but mesh itself works properly and
routes traffic according to availability of nodes. We also
tested the Netgear mesh network routers and were
successful in configuring them to establish internet
connection via mesh routers.