How to use CDMCMesh - A Tutorial

Asitha Bandaranayake

email: <asithab [AT] gmail [dot] com>

v1.0.2, April 23, 2009

This is a guide to Study, Configure &/or Use the Wireless Mesh Network Test-bed installed at Department of Computer Science, University of Cincinnati & operated by Center for Distributed & Mobile Computing (CDMC).

Table of Contents

  1. Introduction
    1. Who this is for
    2. What is in & What is not
    3. How this is organized
  2. CDMCMesh Testbed - An Introduction
    1. Layout
    2. Mesh Router (MR)
    3. Configuration of MRs
    4. Mesh Server
    5. Connectivity Diagrams
  3. Using the Testbed
    1. Fooling Around {Peeking inside an MR}
    2. Messing Around {Configuring an MR}
    3. Local Calls {Talking to your next-hop neighbor}
    4. Long Distance Calls {Multi-hop communication}
  4. Tools & Files
    1. Wireless Tools
    2. Miscellaneous
      1. Remote Logging
  5. Troubleshooting Tips

  1. Introduction

    1. Who this is for

      2. The main focus of this tutorial is on Configuring & Using the Wireless Mesh Network Test-bed at CDMC (CDMCMesh), or more specifically, the Networking & OS (Linux) aspects of it. You can test these, as is, if you have access to the CDMCMesh. Mind you; this document is written as a tutorial, not as a complete reference on every technological aspect of working with the testbed.

      Having said that, the methods & troubleshooting tips described here could also be used on wireless networks using similar devices & technologies.

    2. What is in and What is not

      3. While preparing this, I have tried my best to include information, directions & examples that are deemed essential & useful in working with the CDMCMesh Testbed. However, I do not intend to replicate/reproduce information you could find elsewhere online; not only that would be a waste of time, but also a deterrent to whomever that wants to learn/know only just how to work with CDMCMesh. Nor have I included ALL the material under each topic; for the simple reason as not to overwhelm readers with too much information.

      For the benefit of those who would like to read further, I have provided the links & pointers that I consider important & useful, wherever those are necessary. 

    3. How this is organized

      4. Before moving on, here's a summary of what you can expect in this tutorial.

      The Section 2 will be an introduction to the CDMCMesh Testbed,  where we'll look at the basic information essential to proceed with our objective of learning how to use it. In Section 3, we'll learn how to look around in a Mesh Router, configure a Mesh Router, perform One-Hop communication, and perform multi-hop communication, respectively. As each of these sub-sections will developed from the material covered in previous sub-sections, it would be rather difficult to pick up at a specific topic, without reading through the rest. In the next section [Section 4], I expect to explain in detail some of the tools & files that needs a better understanding, in my opinion, to work with the testbed. As explained above [Section 1.2], rather than making it a replication of material found elsewhere, I will try to additional information, which I think is of use. Finally, I will cover a list of troubleshooting tips, which are drawn from my experience. This will not be a complete list by any means. I'll be adding to it, if & when I figure out or remember new stuff.

  2. CDMCMesh Testbed - An Introduction

    3. OK, before moving on to look at what we can do with CDMCMesh testbed & how it can be done, let's educate ourselves with what CDMCMesh is. Shall we?

    1. Layout

      2. The CDMCMesh currently consists of 26 Wireless Mesh Routers (MRs) spread across the 8th floors of Rhodes Hall & Baldwin Hall, as well as, the 8th floor of ERC Building. 17 of them are in Rhodes & Baldwin Halls (Figure 01), while the rest (9) is in ERC (Figure 02). Note: The MRs are numbered 1 - 28, with MR 09 & MR 10 being decommissioned after initial testing phase.

      [show/hide image]
      CDMC Mesh Network in 8th Floor of Rhodes & Baldwin Halls
      Figure 01: Mesh Network in 8th Floors of Rhodes & Baldwin Halls.

      [show/hide image]
      CDMC Mesh Network in 8th Floor of ERC
      Figure 02: Mesh Network in 8th Floor of ERC.

    2. Mesh Router (MR)

      3. In our Test-bed, we have used Metrix Mark II Wireless Kit from Metrix Communications as our Mesh Routers [Figure 03]. The main features of these MRs are: Each of our MRs were initially fitted with Rubber Duck antennae [Figure 04(a)]. However, to improve the connectivity & the reception, all these were later replaced by Directional Patch Antennae [Figure 04(b)]. As such, currently, each of our MRs are fitted with TWO patch antennae, which are aligned in such a way that connectivity of each network (Rhodes/Baldwin & ERC) is maximized.

      Figure 04(a): Rubber Duck Antennae       		  
      Figure 04(b): Directional Patch Antennae
      [images courtesy of: www.hyperlinktech.com]

    3. Configuration of MRs

      4. This section contains information about how the MRs are configured as of NOW.  Even though I say "information about MRs", we are ONLY looking at the networking related configuration information. Before moving on, please not that there's a possibility that some of these information may change depending upon whatever tests being carried out at a given instance.

      The networking details of MRs could be divided into two sections, viz. Ethernet and Wireless.

    4. Mesh Server

      5. As the Mesh Server, we have a workstation with an Intel Core 2 duo processor & 2 GB of RAM. This is located in the CDMC Lab at 817 ERC. The server runs on Kubuntu 8.04 (Hardy Heron), and has two Ethernet NICs. One of these NICs is connected to the mesh subnet [10.148.1.0/24] and the other to the UC network. {NOTE: This server IS NOT configured to act as a gateway for the MRs to be accessed from the UC network, or vice versa}. Of the two interfaces, eth0 is connected to the UC network, and usually (as it is assigned via DHCP) given the IP address 10.63.10.105 (note that this could ONLY be accessed within the UC Network). The interface connected to the mesh subnet, eth1, has the static IP address 10.148.1.1.

      For CDMC members: Please contact me if you need access to the Mesh Server.

    5. Connectivity Diagrams

      6. Given the layout of the Mesh testbed, it is obvious that each MR falls within the communication range of only a few other MRs. Therefore, in order to use the testbed and allow communication between various MRs, we have to know the connectivity between each MR pair. The two figures given below [Figure 5] gives a crude idea about the connectivity within each mesh network (i.e.: ERC & Rhodes/Baldwin). There are two important things to consider here.
        
      Figure 05: Mesh Network Connectivity Diagrams [As of November 2008]

  3. Using the Testbed

    4. OK! Now, that you know a bit about the Testbed, let's move on to the main objective of this tutorial: Using the Testbed. I'll try to do it progressively, so that you will have the necessary tools & knowledge when it comes to the advanced stuff. Having said that, if you feel adventurous, go ahead & delve into the more advanced stuff straight-away; you can backtrack if you find anything that you need more details on later. If, however, you find it difficult, it may be a better idea to follow it from the beginning.

    NOTE: as the Mesh Server & the MRs are all running some flavor of Linux, I'll proceed by assuming that you can find your way around Linux. If you are a complete newbie in Linux, you'll do better by reading this Beginner's Tutorial (or any other Introductory material in Linux/UNIX). If you are familiar with Linux, but, not well-versed in Networking aspects, you can read this Networking Introduction, to get yourself up to speed.

    OK! So, let's start at the very beginning:

    1. Fooling Around {Peek inside an MR}:

      2. OK! This section is about getting yourselves familiarized with an MR, knowing your way around it & tools you can use to "look around".

      But, first things first: to do all that, we have to have access to MRs. If you have read through the Introduction, you'll know by now that there are several things you need to know if you are to access an MR. Not that I don't trust that you've read through the Introduction; but, to make it easier for everybody, I'll list them again:
      Once you are logged-in to the Mesh Server, there are two ways in which you can access an MR.
      1. Web Interface: This is the web interface provided by Pyramid Linux, for the purpose of configuring an MR. However, I am not going to discuss nor explain this interface, for the following reasons:
        1. It's meant as a configuration tool for Mesh Router users {as said somewhere in their documentation: "Stick to the web interface, unless you know what you are doing"}. As Grad-Students/Researchers we'd better know what we are doing.
        2. It doesn't show us what's really going on with the configuration; using CLI, we can see the entire picture.
        3. Setting network parameters using the web interface tends to "hang" the MR time-to-time (it could also happen with CLI, but, there's a work-a-round for that). We have to make a cold reboot of the MR (have to request UCit) each time that happens.
      2. Command-Line Interface: As you would've guessed by now, I prefer the CLI in dealing with MRs. So, all the examples, here on, will be based on command-line interface. You can use ssh to log-in to an MR.
        • There's a superuser account & a normal-user account. {once again, contact me to get the account details}
        • You can look-around as a normal-user; and you should always do so!
        • The super-user account should only be used for configuring an MR. Please use Extreme Caution while using the superuser (Root) account!!!

      Just one more thing, before we move on. As MRs are used to go off-line (hang, stuck, whatever) for various reasons, you ought to check which MRs are up, before you try to access them. From within the Mesh Server, you can use ping, fping (for a range of IP addresses) or the script (checkMRstatus) I've written to test ALL the MRs at once {I've used fping in the script -- check for yourself at /usr/local/bin/checkMRstatus}. By the way, let me know if any MR is down (or inform UCit about the corresponding Switch IP & Port - and ask them to "recycle the power" -- Just disabling & re-enabling the switch port reboots the corresponding MR, as these are "powered-over-Ethernet").

      OK! Now you are logged-in to an MR {through the Mesh Server}, Let's get down to business!

      Wireless Tools (Commands, How to use them & What you can see):
      That should give you a fair idea about getting around an MR & find the relevant information you need (at least, w.r.t. wireless configuration).

    2. Messing Around {Configuring an MR}:

      3. Now, we are on to more exciting stuff: Configuring an MR in as you want it. First of all, if you want to configure/make changes to an MR, you got be logged in as a SuperUser (root).

      You got to know that there are many ways in which you can configure networking (wireless or otherwise) parameters of a system. Here's some of those, to give you an idea about what available:

      My Recommendations:
      In theory      , it shouldn't matter which method you use for the configuration. However, while working with the MRs, I figured out that, IT DOES MATTER {Not the least because the theories are wrong; but, as always, there are bugs/insufficiencies in code segments/drivers/etc.}. The problem I faced was that, the MRs would get stuck (not accessible over Ethernet) "some of the times" certain changes are made. As this problem seems to occur only "some of the times" under "same" conditions, figuring it out has not being easy. Anyway, after a long series of trial & error (errors are very costly, as we have to wait until UCit reboot an MR -- may be couple of days after the request), I've identified the methods that wouldn't get the MRs stuck! So, my recommendations are based on that!

      Before Moving on: the file system in Pyramid Linux is mounted read only by default. Which means that, if you want to make any changes to a file, you have to remount the file system as read-write. This could be done by using the command /sbin/rw (as root). Note: Remember to remount the file system as read-only once you are done, by running the /sbin/ro command.

      Configuration Files {For Configuring Wireless Interface parameters}:
      There are many files w.r.t. network configurations, and even wireless configuration. However, I'm leaving out the details such as adding/configuring drivers, etc., which are not necessary to learn how to configure the Network Parameters. Therefore, we'll be just looking at the following file:

      Important NOTE: normally, once you have edited the /etc/network/interfaces file, you can either use ifdown command, followed by ifup command to reconfigure the network with new parameters {either with -a option to indicate ALL interfaces, or by specifying the relevant interface} OR run the command /etc/init.d/networking restart to do it automatically for all interfaces (with correct options). However, you should use NEITHER! In my experience, both these methods ended up getting the MR stuck. There may be other ways, but, from what I've tested, the ONLY way to make sure that the MR does not hang is to reboot the MR after making changes to the configuration file.

      CLI Tools:
      I'm hoping to include examples of basic commands you'll need to configure the wireless interfaces & other networking parameters. This might not be complete. I'll keep adding to it, if & when the need arises (I figure out something is amiss or you bring it up).
      iwconfig ath1 txpower 19

    3. Local Calls {Talking to your next-hop neighbor}:

      4. Finally, we are on to more interesting stuff: communication between two MRs. This is FUN!

      As I've explained most of the stuff in detail in previous sections, I will try to keep this section as to-the-point as possible (so that you won't have to read through a lot to figure out what to do). If the need for a longer explanation is there, I'll try to put it somewhere else & link to it.

      OK! So, the question is, "How are we going to get two MRs talking to each other?". First of all we have to look at the prerequisites.

      Prerequisites: These are things you have to figure out or know, before you attempt communication between two MRs.
       By now, you should have the eligible interface pair(s) picked-up. If so, proceed to the next section.

      Note: as I have mentioned before, I have done these experiments for ALL interface pairs. But, those are not yet in a digital format. I'll try to put those up as soon as possible, so that, you'll have a reference point to start with.

      Configuration:

    4. Long-Distance Calls {multi-hop communication}:

      5. The Scenario we are looking at here is communication between two MRs (say MR20 & MR25) via another MR (say MR24). So, naturally, the first step would be to test communication between MR20 & MR24 and between MR24 & MR25. As such, the whole configuration process will be based on what's covered in the previous section. The ONLY additional thing to introduce is how to configure routing through the middle MR. Therefore, I'll use a specific example & explain all these things.

      EXAMPLE: In my example, I'll use the scenario mentioned above (with MR20 & MR 25 communicating through MR24). I'll be assuming that MR24 would be using two different interfaces to communicate with MR20 & MR25.

  4. Tools & Files

    1. Wireless Tools
    2. Miscellaneous

      1. Remote Logging

        2. Coming Soon. Hopefully ;)

  5. Troubleshooting Tips

    6. Nothing yet ! :) {most of the "major" troubshooting tips are already included in the main text}


Asitha Bandaranayake
Center for Distributed and Mobile Computing [CDMC]
Department of Computer Science
University of Cincinnati
Cincinnati, OH, USA.