49-node Indoor Mesh: Difference between revisions

Latest revision as of 15:50, 5 January 2011

Manuals now available

Introduction

Their are a plethora of mesh routing protocols being used worldwide today (See: Wireless Mesh Networking). Some of these have become popular due to organizations taking the trouble to convert the specification into usable code that can be run on a wireless router while other protocols remain purely academic and have only been run on computer simulations. There is also a new 802.11s working group which is seeking to create Mesh Standards. Protocols for which code is available will be run on the massive mesh, indoor testbed, which consists of a grid of 49 nodes (See 1st thumbnail image). Some code will also be ported to run on the massive mesh - for example HSLS is being ported to FreeBSD and Linux. Performance metrics will be gathered such as average throughput and latency together with their variance.

Mobility on wireless mesh networks is also a feature that we aim to test. One method of doing this is by using roaming nodes built onto robots like the Mesh Wanderer Lego robot shown in the 2nd picture. Each protocol is generally suited to different scenarios, some scale better to very large meshes due to less broadcast traffic others are better at handling mobility. Once all these metrics are gathered, better protocol choices can be made when a mesh network is built.

The 3rd and 4th thumbnail images on the right show two scenarios represented by the OLSR Dot Draw visualization tool. The 3rd image shows mesh configuration with no omni antennas attached, while the 4th image shows mesh configuration with an omni attached to node 44.

Other visualization tools are also being worked on.

Operating Systems

The lab has been designed so that it is possible to network boot every node off a single server. This allows us to easily change the software running on the clients right down to the operating system level. The server runs on Linux but there is also an old legacy FreeBSD server that is still running and can be used.

Workshop notes from workshop held in August 2009

Click tutorials

Tutorial 1

Build a packet reflector which reflects all IP packets on a specific interface. So for example if I get a "ping echo" on the interface - send a "ping echo" back to the originating host on this interface. This will cause the other side to send a "ping echo reply" - which our reflector will also send back. You will notice this will cause ping to show (DUP) messages because it's getting duplicate echo reply's. This is also a fun trick if a hacker is trying to port scan you - he will get port scanned back - and get really upset and then leave the world of hacking and do something useful with his life like compose melodies for the limited repertoire of ocarina music.

Solution for Original Tutorial 1

Tutorial 2

Create a "hello world" program which sends the string "Goodbye world" from one host to another host using UDP/IP. You will need to create a sender on one host and a receiver on the other host

Steps to the Ultimate lab platform

Completed

In April 2009 the server was migrated to an Ubuntu hardy LTS based system and a large range of 2009 ubuntu filesystem images are available to run on the nodes
A 1 TB raid system was installed in the server to safeguard against data loss
In August 2009 we completed a scheduler which is only available on the internal LAN at the moment but will soon be available externally for researchers to schedule time in the lab
We have installed a touch screen in the building which will allow you to access information about the mesh lab

We need to make some of these possible from a GUI - all of this is currently possible from the command line

Boot flash image on all nodes
Boot NFS filesystem image off server
Reboot row 1,2,3 ...
Command to send to all nodes
Console output of node xx
Console to set up traffic over network
Choose routing protocol to launch
Setup a set of measurements

- Throughput
- Delay
- Packetloss

Graph of results – auto generate from gnuplot
Visualization panel – Graphviz – UCSB type visualization

Demo experiments to make available from a web page

Start a video streaming experiment over the mesh and observe video degradation as mesh parameters are changed
Change the routing protocol, power levels, routing protocol parameters, start traffic sources, show graph results

Notes of things to fix

The /export/ubuntu/ubuntu_hardy_click os has a problem with the wireless driver - it fails with large packets sizes ... eg ping -s 1500

@@ Line 1: / Line 1: @@
+== Manuals now available ==
+* [[Media:Meshlab_manual_freebsd.pdf|'''The old FreeBSD server manual in PDF format''']]
+* [[Media:Meshlab_manual_linux.pdf|'''The new Linux server manual in PDF format''']]
 ==Introduction==
 Their are a plethora of mesh routing protocols being used worldwide today (See: [[Wireless Mesh Networking]]). Some of these have become popular due to organizations taking the trouble to convert the specification into usable code that can be run on a wireless router while other protocols remain purely academic and have only been run on computer simulations. There is also a new 802.11s working group which is seeking to create [[Mesh Standards]]. Protocols for which code is available will be run on the massive mesh, indoor testbed, which consists of a grid of 49 nodes (See 1st thumbnail image). Some code will also be ported to run on the massive mesh - for example HSLS is being ported to FreeBSD and Linux. Performance metrics will be gathered such as average throughput and latency together with their variance.
@@ Line 16: / Line 21: @@
 ==Operating Systems==
-The lab has been designed so that it is possible to network boot every node off a single server. This allows us to easily change the software running on the clients right down to the operating system level. The server runs on FreeBSD  and the first operating system that was used on the clients was also FreeBSD. The OLSR mesh routing protocol was also implemented on the FreeBSD enabled clients to test the concept. Since many of the routing protocols have been implemented in Linux rather than other OS's, the next step was to attempt [[Linux netbooting]].
+The lab has been designed so that it is possible to network boot every node off a single server. This allows us to easily change the software running on the clients right down to the operating system level. The server runs on Linux but there is also an old legacy FreeBSD server that is still running and can be used.
-==Getting protocols compiled for the massive mesh==
-'''HSLS'''
-HSLS was compiled for NetBSD but a partial port to Linux was done by Proveen Gurung at Telecordia. We recived the code and after some tweaks manged to get it running under linux. The key changes are to edit the /etc/services file before running the deamon.
-The file should have the following entries added:
-:etx             9090/udp
-:hsls            9191/udp
-:hslsapi         9292/tcp
-:nodeinfo        500/tcp
-Once this is done you can run the run_hsls script provided - just change the name of the wireless interface in the script.
+== Workshop notes from workshop held in August 2009  ==
-==How to flash a node in the massive mesh==
+* [[Media:Lab_day1.pdf‎|'''Day 1 of workshop: Learning the lab tools''']]
+* [[Media:Lab_workshop_day2.pdf|'''Day 2 of workshop: The click modular router''']]
-'''Create a tar image of the linux file system'''
-Change to the root folder of the linux filesystem
- tar cvf .../hardcore-linux.tar .
-'''Make an image of the linux file system on the flash card'''
+=== Click tutorials ===
- dd if=/dev/sdb of=hardcore-linux.img
-'''Create a partition on the compact flash card'''
+==== Tutorial 1 ====
- cfdisk /dev/sdb
-'''Make the file system'''
+Build a packet reflector which reflects all IP packets on a specific interface. So for example if I get a "ping echo" on the interface - send a "ping echo" back to the originating host on this interface. This will cause the other side to send a "ping echo reply" - which our reflector will also send back. You will notice this will cause ping to show (DUP) messages because it's getting duplicate echo reply's. This is also a fun trick if a hacker is trying to port scan you - he will get port scanned back - and get really upset and then leave the world of hacking and do something useful with his life like compose melodies for the limited repertoire of ocarina music.
- mkfs.ext3 /dev/sdb1
- tune2fs -c o /dec/sdb1
-'''Untar file system to flash drive'''
+*[[Solution for Original Tutorial 1]]
- tar xvf hardcore-linux.tar -C /media/disk
-'''Start qemu with info to boot'''
+==== Tutorial 2 ====
- qemu -append root=/dev/hda1 -kernel/tmp/bzImage /dev/sdb
-'''Run lilo on flash system once qemu is launched'''
+Create a "hello world" program which sends the string "Goodbye world" from one host to another host using UDP/IP. You will need to create a sender on one host and a receiver on the other host
- lilo
+* [[Solution for tutorial 2 - sender]]
+* [[Solution for tutorial 2 - receiver]]
-'''Now test the flash card'''
- qemu /dev/sdb
 ==Steps to the Ultimate lab platform==
-'''Needed Urgently'''
+''' Completed '''
-''Web site with these features''
+* In April 2009 the server was migrated to an Ubuntu hardy LTS based system and a large range of 2009 ubuntu filesystem images are available to run on the nodes
-* Scheduler
+* A 1 TB raid system was installed in the server to safeguard against data loss
-* Current running experiment
+* In August 2009 we completed a scheduler which is only available on the internal LAN at the moment but will soon be available externally for researchers to schedule time in the lab
-* Timetable of bookings
+* We have installed a touch screen in the building which will allow you to access information about the mesh lab
-''Node control console''
+''' We need to make some of these possible from a GUI - all of this is currently possible from the command line'''
 * Boot flash image on all nodes
 * Boot NFS filesystem image off server
@@ Line 76: / Line 59: @@
 * Command to send to all nodes
 * Console output of node xx
+* Console to set up traffic over network
-'''Later nice to have'''
-* Design console to set up traffic over network
 * Choose routing protocol to launch
 * Setup a set of measurements
@@ Line 88: / Line 68: @@
 * Visualization panel – Graphviz – UCSB type visualization
-'''Practical issues'''
+''' Demo experiments to make available from a web page '''
+* Start a video streaming experiment over the mesh and observe video degradation as mesh parameters are changed
+* Change the routing protocol, power levels, routing protocol parameters, start traffic sources, show graph results
+==Notes of things to fix==
-* Branding - appropriate banners, flyers for the room
+* The /export/ubuntu/ubuntu_hardy_click os has a problem with the wireless driver - it fails with large packets sizes ... eg ping -s 1500
-* Posters of our projects on the walls.
-* Large screen with projector Driven by PC with a web page (?) that has various links to presentations, videos, our mesh stats graphs, etc.
-* Numbering of the boxes (small tags we can put on the boxes for reference
-* Upgrade our VoIP demo with Cans - nice boxes, easy for transport, built in batteries, etc.