                         Mobile Mesh FAQ
                            Version 1
                  Kevin H. Grace kgrace@mitre.org
                    Last Update: August 15, 2000
               Copyright (C) 2000, The MITRE Corporation






1 General

1.1 What is Mobile Mesh?
1.2 Where do I get Mobile Mesh?
1.3 Why do I need Mobile Mesh?  
1.4 Who wrote Mobile Mesh and why?

2 The Tools

2.1 How do the Mobile Mesh tools fit together?
2.2 Can you give me a quick primer on how to run the mmdiscover and
    mmrp tools?
2.3 How do I turn on debugging?
2.4 Can you give me a quick primer on how to run the mmborder tool?
2.5 How do I use the visualization tool?
2.6 How do I install visualization support tools?


3 Error Messages

3.1 Why do I get "UdpSocket::BindDevice() -
    setsockopt(SO_BINDTODEVICE) on '...' failed." when running one of the
    tools?

3.2 Why do I get "Link discovery program on interface '...' is not
    responding. Please restart it before running mmrp." when running mmrp?

3.3 Why do I get "mmrp on port <...> is not responding. Verify mmrp is
    running on this port and restart it before running border." when
    running mmborder?


1 General

1.1 What is Mobile Mesh?

Mobile Mesh is a suite of non-proprietary protocols and Linux based
software tools that provide a mobile adhoc networking capability. The
software tools are Open Source and covered by the GNU General Public
License. They implement the set of Mobile Mesh protocols namely: 1)
Mobile Mesh Link Discovery Protocol 2) Mobile Mesh Routing Protocol
and 3) Mobile Mesh Border Discovery Protocol. These protocols are
documented in Internet Drafts that have been submitted to the IETF's
Mobile Adhoc NETworking (MANET) Working Group. Each protocol is
implemented as a separate software tool, namely: 1) mmdiscover, 2)
mmrp, and 3) mmborder. Additionally, there is a network visualization
tool called mmrpviz.


1.2 Where do I get Mobile Mesh?

The official website for Mobile Mesh is
www.mitre.org/tech_transfer/mobilemesh . You can get the latest source
code and documentation from the website.  Also, the website gives
directions for subscribing to the Mobile Mesh mail list where we
discuss Mobile Mesh related issues such as using the software and
reporting bugs.


1.3 Why do I need Mobile Mesh?  

If you wish to communicate with others without the need for network
infrastructure such as cellular base stations or wireless access points,
then Mobile Mesh provides a Linux based solution. Mobile Mesh treats
everyone's computer as a wireless router and learns about the links in
the network, computes paths between all users, and updates the IP
routing tables so that you can send packets to anyone else who is part
of the adhoc network. All you need is a Linux based machine with at
least one wireless interface (actually you could use a wired interface
but you won't be very mobile then!) and Mobile Mesh will take care of
the rest.


1.4 Who wrote Mobile Mesh and why?

I, Kevin H. Grace, wrote Mobile Mesh to fill a need. As part of a
research project at The MITRE Corporation, I looked at what the rest
of the research community had designed and implemented for mobile
adhoc routing protocols. I was rather dissatisfied with what I saw and
decided that I needed to build some protocols and tools.


2 The Tools

2.1 How do the Mobile Mesh tools fit together?

Ah, finally the meat. First, each tool has a corresponding manpage
that you should read carefully. Let me describe here how these tools
fit together.

The main tool is "mmrp". It executes the Mobile Mesh Routing Protocol
on one or more IP interfaces. You can specify which interface should
participate either statically through a config file (default config
file name is "mmrp.conf") or dynamically. As a user you won't need the
dynamic mechanism, but if you were developing a software tool, the
dynamic mechanism could be useful. In fact, this dynamic mechanism is
used by "mmborder" (more later).

"mmrp" needs to be told about the neighbors which an IP interface can
hear. This is the job of "mmdiscover". "mmdiscover" speaks the Mobile
Mesh Link Discovery Protocol on an individual IP interface. It reports
events when links come up and go down by writing them to a well known
Unix socket named "ln-<port>" which "mmrp" can then read. "mmrp" uses
these events to create its Link State Packet. If you look in the
directory where "mmdiscover" runs you should see one or more of these
"ln-<port>" entries when performing a directory listing.

Since "mmrp" needs to be told by "mmdiscover" about neighbors, you
must start "mmdiscover" on each desired IP interface before starting
"mmrp", otherwise "mmrp" will complain and exit.

If two or more of your machines have a wired IP interface in addition
to a wireless interface (let's call these border routers), it can be
useful to leverage the flow that exists across the wired
infrastructure. This reduces the amount of data which is communicated
across the bandwidth constrained wireless links and can prevent
partitions from occuring in the adhoc network. "mmborder" speaks the
Mobile Mesh Border Discovery Protocol on the fixed network
interface. "mmborder" will automatically setup tunnels with other
border routers and dynamically add these new tunnel interfaces to
"mmrp". When "mmborder" discovers that a border peer is no longer
present, it tears down the corresponding tunnel interface and
dynamically deletes it from "mmrp". 


2.2 Can you give me a quick primer on how to run the mmdiscover and
    mmrp tools?

Sure. But before you try to run the tools, you really should
understand the fundamentals of IP and be familiar with tools like
"ifconfig", "route", "netstat", and "tcpdump". For simplicity, let's
assume you have three laptops: A, B, and C. Let's also assume each
laptop has a single IP interface that happens to be a wireless LAN
card. ( Please don't assume that you must have a wireless LAN card in
order to use Mobile Mesh...you can run Mobile Mesh on any IP interface
regardless of media! ) Now let's assume that the name of the interface
on each laptop is "eth0". We are doing alot of assuming here. Finally,
let's assume that we want to run Mobile Mesh because we have no fixed
infrastructure to leverage, like 802.11 access points.

If all we want to do is allow the three laptops to communicate,
possibly across a multihop path, and the laptops are not connected to
any media other than the wireless LAN, then we should begin by
removing any static routes that each laptop may have. In a shell
window, type "netstat -rn" to see the current list of IP routes. Make
sure there are none listed. If there are some listed, delete them
using the "route" command. You're on your own to delete the routes...I
warned you before that you should be familiar with these tools!

You should now start the link discovery tool on each laptop. In a
shell window, as root, type "mmdiscover -i eth0 -z". The "-z" option
prevents the tool from becoming a daemon and running in the
background. I suggest using this mode at first, since any error
messages will be sent to the shell window rather than
/var/log/syslog. 

Now, you should make sure that the interfaces you want to run "mmrp"
on are listed in the mmrp config file.  You can change the parameters
that each protocol uses by editing their respective default config
files: /etc/mobilemesh/mmdiscover.conf and /etc/mobilemesh/mmrp.conf.
Make sure a line "interface eth0" is in the mmrp config file. You can
supply your own config file rather than using the default config
file...read the mmrp man page and look for the "-f" option.  You can
now start the router by typing, as root, in a shell window "mmrp -z".

After a little time, you should see routes get added to the IP table;
use "netstat" to verify this. If you want more details about what the
tools are doing you can turn on debugging (see the next FAQ question.)


2.3 How do I turn on debugging?

Most Mobile Mesh tools accept a "-d <file>" command line switch. In the
distribution, a debug file for each tool is provided. For example, the
debug file for "mmrp" is "mmrp.debug". When starting "mmrp", add "-d
mmrp.debug" to the command line. 

You may then enable and disable individual debug flags at runtime by
editing the debug file. As the comments in the debug file indicate,
precede a debug flag with a '+' to enable it or with a '-' to disable
it.


2.4 Can you give me a quick primer on how to run the mmborder tool?

Let's assume you have the same three laptops as in answer 2.2 but this
time A and B have a second IP interface which is a wired Ethernet
interface. A and B are no longer mobile, but C is still mobile. Let's
assume the wired interfaces are named "eth1". Since A and B straddle
the boundary between the wired world and the mobile adhoc network, we
call them border routers.

Start mmdiscover and mmrp just like you did in the previous example,
on interface "eth0" on each machine. Then, on laptops A and B, start
the border discovery tool on the wired interface by typing, as root,
in a shell window "mmborder -a 192.168.1.1 -i eth1 -z" on A, and
"mmborder -a 192.168.1.2 -i eth1 -z" on B. The "-a" is required and
specifies the address that will be assigned to tunnel interfaces when
they are created. If all goes well, the border routers A and B will
discover each other and set up a tunnel between themselves. They will
also automatically start mmdiscover and mmrp on the tunnel
interfaces. You can verify the existence of the tunnel interface by
typing, in a shell window, "ifconfig -a" and looking for an interface
named "b0".

To make things interesting, you can move A and B out of wireless range
of each other. Then, as you move laptop C around, it will
automatically create routes based upon whether A and B are directly
reachable or indirectly reachable (eg. C has a link to A but C does
not have a link to B; the route from C to B then goes through A across
the tunnel).


2.5 How do I use the visualization tool?

First, you must install a separate package called GraphViz from AT&T
Research. You can get the latest from www.graphviz.org.

Second, you should read the manpages for "mmrpviz" and "mmtodot". 

The visualization tool is really two programs. "mmrpviz" is simply a
GUI; it displays a GIF file and whenever the GIF changes, it
redisplays the new GIF. Before launching "mmrpviz" you should start
"mmtodot", a program that receives from "mmrp" the router's link state
database. "mmtodot" creates a description of the network using the
"dot" language. (See GraphViz for details about the "dot" language.)
After creating the "dot" file, "mmtodot" launches the GraphViz tool
"dotneato" to convert it to a GIF file. Then, "mmrpviz" notices that the
GIF file has changed and redisplays it. By design, whenever "mmrp"
builds its new Link State Packet, any clients connected to its well
known topology socket will receive the link state database.


2.6 How do I install the visualization support tools?

mmtodot uses GraphViz 1.6 which can be obtained at:

http://www.graphviz.org/.  

When you read the GraphViz documentation,
you'll see that it requires a slew of additional libraries. As an aid,
I have included URL's where you can get the source to build the
required libraries, in case they are not already installed on your system:

libttf - http://www.freetype.org/
libz   - http://www.info-zip.org/pub/infozip/zlib/
libpng - http://www.libpng.org/pub/png/libpng.html
tcl8.3  and tk8.3 - http://dev.scriptics.com/software/tcltk/downloadnow83.tml
libjpeg - http://www.ijg.org/

Follow the directions supplied with each library to build and
install. Just as a heads up, you must build libz BEFORE libpng.

You may encounter a problem when building graphviz. If you see a
compiler error about "undefined symbol compress" or "undefined symbol
uncompress" it may be that you have an old version of libz residing
somewhere. Do a 'find / -name "libz*" -print' to verify. If you have
an old libz hanging around, I would move it or rename it.

Also, you may encounter a problem when running "mmtodot". If you see
an error message about not being able to find Times font or
Times-Roman font, you'll need to make some True-Type fonts
available. You can snag True-Type fonts from many places; one such
place is:

ftp://ftp.microsoft.com/developr/drg/truetype/corfonts.exe. 

This file is a self-extracting Windows/DOS executable. You can use
InfoZip from ftp://ftp.freesoftware.com/pub/infozip/ to expand it from
Linux. After extracting the various font files, I simply copied
"TIMES.TTF" to /usr/local/share/ttf/Times.ttf and also to
/usr/local/share/ttf/Times-Roman.ttf. Apparently graphviz hardcodes
the path to search for font files. I just chose one of these hardcoded
directories and then made the "TIMES.TTF" file be used for both Times
and Times-Roman fonts.


3 Error Messages

3.1 Why do I get "UdpSocket::BindDevice() -
    setsockopt(SO_BINDTODEVICE) on '...' failed." when running one of
    the tools?

You must run the tools as the root user in order to have permission to
execute priviliged system commands.


3.2 Why do I get "Link discovery program on interface '...' is not
    responding. Please restart it before running mmrp." when running mmrp?

Because "mmrp" requires each participating IP interface to have an
active copy of "mmdiscover" executing on it.


3.3 Why do I get "mmrp on port <...> is not responding. Verify mmrp is
    running on this port and restart it before running border." when
    running mmborder?

Because "mmborder" requires an active copy of "mmrp" to be executing
on a specified UDP port number. The UDP port utilized by "mmrp" is
is contained in the name of the well known Unix socket that
"mmborder" uses to dynamically add and remove tunnel interfaces.



