DYMOUM is an implementation of the DyMO (Dynamic Manet On-demand) routing protocol for both linux kernels and the ns-2 Network Simulator. The code is released under the terms of the GNU General Public License (GPL). Due to lack of time this project is not maintained by myself any more, feel free to take over the task of maintenance if you are interested.

Linux and ns-2 implementations share most of the code, which has been written in the C and C++ programming languages. Linux implementation runs as a user space daemon which communicates with kernel space via netlink sockets. Just a little module is needed to be run in kernel space. In order to run DYMOUM, the target kernel must have Netfilter support. This implementation is inspired on the software architecture of AODVUU, a well-known AODV implementation for Linux and ns-2.

DYMOUM is referenced in several research papers and it has been thoroughly tested on the ns-2 network simulator. In addition, it has been successfully employed in different ad-hoc testbeds.


  • IPv4 only.
  • Highly compliant with DyMO drafts -04 and -05.
  • Linux implementation:
    • Support for kernels 2.4 and 2.6.
    • Multiple network interfaces support.
    • Configurable from command line parameters.
    • Debug information through syslog and /proc systems.
    • Neighborhood monitoring via HELLO messages.
  • ns-2 implementation:
    • Support for several ns-2 releases.
    • Neighborhood monitoring via HELLO messages and MAC layer feedback.
    • Configurable from TCL scripts.
    • Debug information.


The source code of DYMOUM is hosted on SourceForge.net: download.

Contributed patches

Here you can find some patches that were contributed by different users. Thanks a lot to each of them.



In order to compile DYMOUM, you need the source code of your kernel. It must have Netfilter support, which is enabled by default in most linux distributions. In case this feature is disabled, it must be turned on and the kernel must be recompiled.

Download the latest DYMOUM version from SourceForge.net. Then execute the followings steps (substitute “0.1″ for the version number of the software you have downloaded):

$ tar zxvf dymoum-0.1.tgz
$ cd dymoum-0.1
$ make
$ make install   # as root


I assume that you have downloaded and unpackaged the allinone distribution of ns-2 (any of the versions supported by DYMOUM). Copy dymoum-0.1.tgz to ns-allinone-2.28/ns-2.28/ (change “2.28″ to your ns-2 version number), and then write:

$ cd ns-allinone-2.28/ns-2.28/
$ tar zxvf dymoum-0.1.tgz
$ ln -s ./dymoum-0.1 ./dymoum
$ patch -p1 < dymoum/dymoum_ns-2.28_v0.1.patch

If you had not installed ns-2 yet, then do the following:

$ cd ..
$ ./install

On the other hand, if you are installing DYMOUM on a running installation of ns-2:

$ ./configure
$ make distclean
$ ./configure
$ make

Note that the code should work on most ns-2 releases, but only patches for some versions are provided. If you need DYMOUM on a different ns-2 version, just create the appropriate patch and share it if you want.


Before you learn how to use and configure DYMOUM, let us take a look to its default configuration.

Path accumulation is enabled by default. This means that a node appends its own routing information to every RE it forwards. Hopefully this may avoid future route discoveries. However, some DyMO drafts advise not to activate this option unless there is an administrative decision behind. So, you could be interested in disabling this behavior following the instructions which appear in subsequent subsections.

When a route discovery fails (a RREQ is sent but no RREP is received), DYMOUM inmediately considers that there is no such route. This default behavior may be changed in order to retry a fixed number of route discoveries following a binary exponential backoff algorithm (see DyMO drafts for further information).


By compiling and installing the software you get two different objects: an executable file called dymod which runs in user space, and a loadable kernel module called kdymo{.o|.ko} which deals with kernel space operations. You only need to launch dymod to get DYMOUM running.

To get a full list of the options supported by DYMOUM, execute (always as root):

$ dymod -h   # or, alternatively...
$ dymod --help

Let us see some common invocations of DYMOUM. To execute the protocol on interface wlan0 just type:

$ dymod -i wlan0

If we are interested in several network interfaces, we just have to indicate them with a comma-separated list. See next example, where we also want to reissue RREQs following an exponential backoff algorithm when the first route discovery fails:

$ dymod -r -i wlan0,eth1

To put the software in daemon mode use the following command:

$ dymod -d -i wlan0,wlan1

Next invocation disables the path accumulation feature and enables the verbose mode, where lot of debugging information is generated:

$ dymod -v -n -i eth1

You can also avoid unidirectional links if nodes blacklist the neighbors which did not send a unicast packet (ICMP ECHOREPLY messages are used within this implementation) when the S-bit of the DyMO header is set. To set the S-bit:

$ dymod -s -i wlan0

In order to monitor the link status with the neighbors, you must specify the interval at which HELLO messages are sent out:

$ dymod -m 1 -i eth0

Debug information is generated via the syslog subsystem. Depending on your syslog configuration, dymod messages may be directed to /var/log/daemon.log, /var/log/syslog or something like that. If DYMOUM is not executed in daemon mode and verbose output is enabled, then debugging messages are also printed out to stderr.

From /proc subsystem you can also obtain a little bit of information regarding the loadable kernel module execution. On file /proc/net/kdymo (or something similar, depending on your configuration) you will find the number of packet drops and the current number of data packets inside the queue.


DYMOUM can be used like any other routing agent in ns-2, so you can use the node-config command to attach a DyMO agent to the mobile nodes which are to be created.

$ns_ node-config -adhocRouting DYMOUM

After creating your mobile nodes, you can configure each DYMOUM routing agent individually or all at once. But first we will see the available configuration options and their default value.

  • debug_ : Print debugging messages on stdout.
  • no_path_acc_ : Disable path accumulation.
  • reissue_rreq_ : Try more route discoveries when it fails the first time.
  • s_bit_ : Set S-bit of DYMO header.
  • hello_ival_ : Specify the interval between HELLO messages. If set to 0 or not indicated, neighborhood monitoring is performed via link layer feedback.

In order to configure all agents, write sentences like these:

Agent/DYMOUM set debug_ true
Agent/DYMOUM set reissue_rreq_ false
Agent/DYMOUM set hello_ival_ 1

In order to configure a single agent:

set ra [$mobilenode agent 255]
$ra set reissue_rreq_ true
$ra set no_path_acc_ true

Once you have performed a simulation, you get a trace file where you can see what happened during the execution. Let us see with some examples the format of the traces generated by DYMOUM. Following examples use the classic notation of ns-2 trace files. However, “tagged” and “new trace” formats are also supported.

s 6.053808264 _15_ RTR  --- 1 DYMOUM 48 [0 0 0 0] -------
 [15:255 -1:255 1 0] [ RE 0 0 28 10 0 1 21 0 0 [0 0 0 15 2] ]

The line above indicates that node 15 is sending a DYMOUM packet (size = 48 bytes) with a RE message. Specific information about the DyMO message is found by the end of the line (starting from “RE”): m bit, h bits, lengthttli bit, a bit, target addresstarget sequence number and thopcnt. Inside the final brackets there is a routing block with the following fields: g bit, prefixhop count, node address and node sequence number. When path accumulation is enabled, more than one of these blocks are appended to the RE.

r 10.712966365 _2_ RTR  --- 249 DYMOUM 32 [0 ffffffff 11 800] -------
 [17:255 -1:255 1 0] [ RERR 0 0 12 10 0 [32 3] ]

In this case, node 2 is receiving a RERR with the following the fields: m bit, h bits, length, ttl and i bit. The latest block inside the brackets contains: unode address and unode sequence number.

s 10.007533000 _1_ RTR  --- 4 DYMOUM 28 [0 0 0 0] -------
 [1:255 2:255 1 2] [ ECHOREPLY 8 ]

When the S-bit is set in a reply (RE with A-bit disabled), the receiving node must send a unicast packet to the sender. This implementation uses ICMP ECHO REPLY messages, but for convenience we include these messages as if they were part of the DyMO protocol. The line above shows how node 1 is sending a ECHO REPLY with 8 bytes of length.

During a simulation, UERR messages should not be generated because all message types are supported. Anyway, they would look like:

UERR m h len target_address uelem_target_address uerr_node_address uelem_type


This implementation was developed by Francisco J. Ros as part of his work as a research engineer in the University of Murcia.