TMipd HowTo
How-to go TMip mobile!




The SOWN Network

At SOWN we plan to deploy this software out across our network.



Click the image above to see what we have been doing.























Network Visualisation

The image to the right was created live off the SOWN mobility network.

I play to release this tool soon. It also allows remote management of the MLR.
























Slyware Logo

 Introduction

On this page I hope to provide a one stop shop to enable anybody to get tmip running in their network. As times goes on, the FAQ section at the end of this page should grow, and hopefully a little more detail will be added. This page, however, makes a few assumption, such as at least a basic understanding of how TMip works, and how to navigate around a Linux/Unix box. An introduction to TMip can be found here.

If you are looking for a good guide on how to set up a complete mobility ready, all-in-one node ready to be deployed in your wireless network, take a look at the SOWN project. This project is deploying a wireless mesh across Southampton, UK, mainly round Southampton University. It's the native home of TMip too :-). Check out the HostAP node set up guide for a good starting place!

 What Will This How To Explain?

Essentially, this how to will explain how to establish transparent IP mobility across multiple nodes, where each node runs on a separate subnet (as explained in the overview). It will cover:

  1. Explanation of Terms
  2. How the network topology should be laid out
  3. Unpacking and compiling
  4. Configuring the Mobile Location Register
  5. Configuring the Correspondent Nodes
  6. Going Mobile!
  7. Registered Host Deployment
  8. Network management and control
  9. Frequently Asked Questions

 Explanation of Terms

To save a bit of writing, the following diagram, and list of terms will be referenced throughout this document.

  • TMip: Transparent Mobile IP
  • CN: Correspondent Node (runs on the cell nodes)
  • Cell: Area of mobility connected to a single CN
  • MLR: Mobile Location Register. Central storage of mobile host location.
  • tmipd: The main application that runs on each CN
  • mlrd: The MLR application
  • MLRP: Mobile Location Register Protocol. Used to talk CN-CN and MLR-CN and MLR-MLR etc.
  • Parent CN: Where a mobile host is registered, i.e. has address space assigned under their mobile cell
  • Current CN: The CN currently controlling a mobile host
  • Static host record: You can think of this like having a fixed entry in DHCP. It means that wherever you appear in the mobile network, you will always get assigned the same IP. So, you could have this registered in DNS for example, so your host is always reachable by the same name, no matter where it is! See here for details on setting this option
  • Dynamic host record: A dynamic record is only live in the network whilst a host is active (and for a short period after they leave). Unregistered hosts (ones without static entries) will have these for the length of their session.

 What Do You Need

The basic requirement is at least two PCs (one for each Correspondent Node). These may have two network interfaces each (such as one for wireless, and one to link the nodes together), or a single wireless interface between the two. But note that there is no requirement that anything is wireless! The application functions just as well on a standard wired, switched/hub based network. Also makes it a lot easier to test when they are wired!

This section gives more details on actual topology, but the more nodes the better! The Mobile Location Register (MLR) needs to run somewhere, but this can quite easily run on an existing CN. Finally, there is no reason why the CNs need to be close to each other (other side of the world if you like ;).

Operating system wise, we have tested on various versions of Linux. Note that there may be a few header conflicts as people try it on different systems. You will also need IPIP and libpcap installed. More will be discussed in the unpacking and compiling section.

Goto Top







Quick Hint

To check that a CN can see all other CNs and the MLR use:

./tmipd -E


 Network Topology

TMip networks can be deployed in various ways. The CN application can run on nodes of different configurations, using either two interfaces or one for connecting both mobile hosts and connecting to the MLR/tunneling.

There are five main ways a CN can be set up:

  1. Have a CN with one mobile interface, cross-overed to an access point, or a PCI WLan card. The other interface is wired and connected to the main network.
  2. Have a CN with a single network interface, either wired or wireless, both serving mobile hosts and being used as the CN interface.
  3. Have a node with two wired interfaces, one being used to serve wired mobile hosts, and the other for the connection to the rest of the network.
  4. Use any of the above, but additionally register some other address allocation for use by the network. This could be a wired interface, implying that the route of all tunnels (i.e. parent) is on wired rather than wireless (quicker).
  5. Have a node with a combination of all the others above. This is a new feature in v0.13, where multiple CN's are allowed per physical node. Note that an instance of TMipd is required to serve each mobile interface (idea is to make tmipd able to handle multiple mobile interfaces in the future).

More details on supported deployments are included in the TMip Introduction.

The only restriction is that all the CN's must be able to talk to each other. If two can't, they will not be able to tunnel data between themselves. Therefore, you cannot have one CN running under a private address allocation, and another under a public IP, for example.

Goto Top



Tested Systems

We have tested this software on the following:

RedHat 8
RedHat 7.3
GenToo
Debian
Pebble

If you find any fixes that make it work on your system, please tell me!


 Unpacking and Compiling

It should be straight forward to get everything compiled and ready to run. The main requirement is having libpcap installed, and IPIP tunnel support compiled into the kernel You may have to install libpcap from your ports tree/package manager.

You can now either grab the latest release of TMip, or checkout the cvs version. The release should be more stable, but obviously the CVS version will normally have more functionality. The choice is yours...

To get the release, simply download the archive for version 0.14a from the main project page, and extract it. The latest release file is tmip_0.14a_release.tar.gz.

You can also get the very latest version of TMip (tmipcore) from the SourceForge CVS repository. Enter the following (use a blank password):

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/tmip login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/tmip co tmipcore

Now change into the tmip/tmipd directory and type make. This should compile the main application, and the components within the common directory. Now just change into the tmip/mlrd directory and do make, and you may as well do the same in tmip/mlrp_query.

Assuming everything compiled up fine, you are pretty much ready to go! You may want to take a look at the README and TODO files at some point too.

 Compilation Errors

Problems finding pcap.h? If you get errors during make about the lack of pcap.h, and you are sure it is there, it may just be in a different place. ProxyAdapter (proxyadapter.h) looks for it in /usr/include/pcap.h, whereas yours may be in /usr/include/pcap/pcap.h. If so, either symlink it, or change the #include line in proxyadapter.h.

If you have any problems whilst compiling, the most common cause is lack of pcap. If this is all there, and you still can't get it to compile, shout for help on the forums or IRC (see the FAQ).

Goto Top













Bored Yet?

Check out some of my other projects and little applications!


 Configuring the Mobile Location Register (MLR)

 The Purpose of the MLR

The mobile location register is the brains behind the system. What the MLR knows goes, in terms of the behaviour of the correspondent nodes. Basically, the MLR holds mappings from Ethernet MAC addresses to sets of details about hosts, such as their IP address assignments and current location. These details can be in two states, called dynamic and static. Dynamic essentially just means that they are present somewhere in the network now, whereas static entries can be used so that the network remembers that host when offline (for address assignment reasons).

The MLR is also responsible for all address allocation to migrating clients, implying that the entire TMip network becomes one big distributed DHCP server.

Each network has a single primary MLR. When new hosts appear inside mobile cells, the MLR is queried to establish its identity. Once the corresponding parties have been contacted and tunnels created, the MLR is updated with the new location. In addition to location information, the MLR also handles all address assignment for the CNs. It is really the central management utility within the network, and what everybody should query to generate pretty graphs etc :-)

 Launching the MLR

Generally (and as this project is still early in development ;) I recommend running two MLRs. The MLR supports a carbon copy mode, which is a bit like zone transfers with DNS. Basically, a primary MLR will transfer all dynamic and static host data to a secondary MLR periodically. This means that you can take down the primary MLR, patch it or install a new version, then launch it, and it will automatically pull all the host entries back down. This is of obvious importance in case of bugs in the MLR :-)

Your MLR is going to get lots of traffic from the other CNs, so it makes sense to have it somewhere near the top of your network (such as where your wireless mesh meets on some significant node for example). But, first lets do the secondary MLR. So, on the box that it is going to run on, whilst in the tmip/mlrd directory do the following:

First task is to create a basic configuration file syntax. The default is mlrd.rc, but you will want to change some of the options within it. Following is an example.

network_name my-tmip-mobility
port 5555
foreground false
log_file /var/log/mlrd.log
status_file /var/log/mlrd.status
log true
grant primary.mlr.foo.com

I've chosen to use port 5555 for the secondary MLR (you could just use the default, if your secondary MLR was on a different machine to the primary one). The other additional option you will need to do is to grant update rights to your primary MLR (as it will be sending its configuration over via the carbon copy update process. This is done using the 'grant' option, so simply put the IP or DNS name of your primary MLR after this.

Once you have specified this file, do the following. Note that by default, the MLR will vanish into the background. You can prevent this by specifying 'foreground true' or using the -F parameter. Don't forget to change the -f parameter if you are using a different configuration file.

[root@tnode1 mlrd]$ ./mlrd -f mlrd.rc
+ Starting MLR Server [v0.14a]

+ Loading settings from configuration file...
   + Using mlrd.rc

+ Switching into daemon mode (Logging to /var/log/mlrd.log)

If you now look in the log file, you can check that everything is still ok. If anything didn't go right during start up, it should have indicated on the stderr what the problem was.

[root@tnode1 mlrd]$ cat /var/log/mlrd.log

+ Logging started for Mobile Location Register [v0.14a]

+ Serving network [my-tmip-mobility].

+ Bringing up MLR services...

   [Session Dispatcher (port 5555)]: Done.
   [MLRCache]: Done.
   [CNList]: Done.

+ MLR up and listening...

The MLR should be sitting listening waiting to serve requests. You can choose whatever network name you want (the network_name option), but remember that your CNs must use the same one! Note that you can now change the settings of the MLR config file, and send the HUP signal to it to get it to re-read its configuration. See here for more details.

Right, so now on the box that will be the primary MLR, so the configuration file for this may look like follows:

network_name my-tmip-mobility
port 6554
foreground false
log_file /var/log/mlrd.log
status_file /var/log/mlrd.status
log true
cc_mlr ccmlr.whatever.org:5555

Make sure you specify the address of your carbon copy MLR, the one you just set up. Again, start it and it will vanish to the background...

[tmipuser@tnode1 mlrd]$ ./mlrd -f mlrd.rc
+ Starting MLR Server [v0.14a]

+ Loading settings from configuration file...
   + Using mlrd.rc

+ Switching into daemon mode (Logging to /var/log/mlrd.log)

The first time you start the primary MLR you may want to start it in foreground (using -F), then when it is running type ccpush. If it says Carbon copy push successful then everything is OK. If it doesn't then check that you have granted the correct IP/name in your secondary MLR configuration. Note that you must grant the IP of the interface nearest the secondary MLR (if your secondary MLR has multiple interfaces). Once happy, use Ctrl+d to kill the MLR, then start without the -F parameter.

If you look in the log file for this MLR, it should contain details about the carbon copy transfer...

[root@tnode1 mlrd]$ cat /var/log/mlrd.log

+ Logging started for Mobile Location Register [v0.14a]

+ Using carbon copy MLR server (10.13.0.250 on port 5555): Seems Ok.

+ Serving network [my-tmip-mobility].

+ Bringing up MLR services...

   [Session Dispatcher (port 6554)]: Done.
   [MLRCache]: Done.
   [CNList]: Done.

+ MLR up and listening...

NOTE:  To terminated the applications, just kill the process. However, if you start them in foreground/interactive mode, using -F, you can exit them using Ctrl+d. See here for more details on the signals you can send to the MLR.

 MLR Interactive Commands

When you start the MLR in foreground mode (-F or 'foreground true') you can use some interactive commands. They are all still debuggy type commands, so nothing looks that nice yet!

  • show: Lists currently active hosts in the network
  • showstatics: List static host entries
  • showall: Combination of the above two
  • clear: Clears the dynamic host list
  • clearall: Clears all host entries
  • grant: Grant update rights to some IP
  • ccpush: Pushes content to secondary MLR
  • ccpull: Pulls content from given MLR
  • bindings: Shows all currently bound CNs
Goto Top



MLR/CN Security

This is alpha software, robustness may be a high priority, but security isn't (yet)!

Saying that, any good ideas on authentication of MLR/CNs welcomed :-)


 Configuring the Correspondent Nodes

To set up all the correspondent nodes (CNs), you should follow this section repeatedly :-)

 Getting the Interface Names Right

This is where it can get fun. The CN application (tmipd) is the meat of the project. It should run on the gateway between each mobility equipped cell and the outside world. There are lots of different situations that could occur, depending on the configuration of your network. However, I assume that the most common examples are as follows:

  • The CN is a host with two wired network interface cards in it, one going to the main network, the other being a crossover cable into the back of an access point. In this case, you can assume that the one attached to the access point is mobile facing, and the other is the CN interface.
  • The CN is a host with two wired network interface cards, one going to the main network, and the other to some network that we want to allow mobile hosts to physically plug into. In this case, the naming is as above.
  • The CN is a host that has one wired network interface, going to the main network, and one wireless PCI card. Again, the interface names should be as with the first situation.
  • The CN is a host with a single wireless network interface. In this situation, both interfaces (in terms of the software) are the same.

 Configuration File

Since version 0.11a, a configuration file is supported. By default the tmipd.rc file is used within the tmipd directory. However, you can specify any location by using the -f command line parameter.

A detailed description of all the options is included at the top of the provided tmipd.rc file, but below is a basic configuration file to get you started.

mlr 10.13.0.250
cn_name My Test CN
tunnel_prefix tmip0
cn_if rl0
mobile_if rl1
addr_pool rl1 * *
network_name my-tmip-mobility
dns_server 10.13.0.254
log_file /var/log/tmipd.log
status_file /var/log/tmipd.status
debug_level 2

Right, after the mlr put your primary MLR address (IP or DNS name), after the cn_if put the interface name of your CN interface, after the mobile_if put the name of your mobile facing interface, and after the network_name put the name of your network. Note that depending on your situation as discussed above, the two interface names may be the same. Next you define what address space you want this node to allocate. You can define none at all, or lots, see the tmipd.rc file for details! Basically, to get started, and to dish out all of your mobile interface, use addr_pool rl1 * *, where rl1 is your mobile_if. Give your CN a name using cn_name. Finally, you may want to specify your primary DNS server (this will be returned to clients via DHCP).

The tunnel_prefix option is new. If you plan to run more than one CN per physical node, you will need to specify a unique value for this on for each instance of tmipd on that individual machine. This is simply used to separate the tunnels out between the different instances. You can use what name you want. If you only have on CN on the machine, then simply use the default.

Due to the various other default configurations that will be loaded, a CN using the above will have DHCP enabled, and will vanish to the background. This can be overridden using the -F parameter or 'foreground false' option. Have a look at the comments at the top of tmipd.rc file for details on all the supported options.

 Checking Connectivity

The next thing to do is check that your CN can actually see the MLR and all the other CNs. As it might have to establish tunnels between itself and other CNs, it must be able to contact them. Luckily, the application has a useful feature within it to help you :-). From the tmip/tmipd directory run:

[root@tnode1 tmipd]$ ./tmipd -Ef tmipd.rc
+ Starting TMip Correspondent Node [v0.14a]

+ Loading settings from configuration file...
   + Using mlrd.rc

Network Connectivity Evaluation
===============================

   + MLR @ 10.13.0.250: Passed.
   + CN @ 10.13.0.1 [Oakhurst directional]: Passed.
   + CN @ 10.13.2.1 [Si's room]: Passed.
   + CN @ 10.13.4.1: Passed.
   + CN @ 10.13.7.1 [ECS Roof]: Passed.

If this is your first CN, it will just get the name of the MLR, and MLRP_PING it. If all is ok, it should say so, and if not, check IP's etc. If you have already set up at least one CN (hurrah for you!), it will MLRP_PING them too.

Note: Each CN must be able to establish a TCP connection to port 6554 of the MLR, and a TCP connection to every other CN on port 5554. Also, tunnels (IPIP) must be allowed through between CNs. Check your firewall configurations before you spend an age trying to debug it!

 Starting the CN

You should now be ready to run the main CN application (as root). It defaults to turn into a daemon and log output to a logfile /var/log/tmipd.log. To start it, just run the following (or give the -f option if the configuration file isn't within the local directory.

./tmipd

If the app starts, but then bails out, check that you are running as root.. Also, if it comments that it can't write to the logfile, check that you are root. However, if everything went well, it should be sitting in the background, and you can view the logfile to see its status. You may want to read what it says when it starts, as it gives you a good idea what the CN will do. It should look something as follows...

Since v0.14a, both tmipd and mlrd are slightly more friendly when it comes to debug output, so when vanishing off to the background in daemon mode, they will tell you if any errors actually occurred.

[root@tnode1 tmipd]$ ./tmipd
+ Starting TMip Correspondent Node [v0.14a]

+ Loading settings from configuration file...
   + Using tmipd.rc

+ Switching into daemon mode (Logging to /var/log/tmipd.log)

However, if you got something like the following printed out on the screen after tmipd started, you will want to check the log file to see what went wrong.

[ERROR from tmipd @ 2242]: ** Check connectivity to MLR **

Note that changing the foreground option to true, or passing -F as a parameter will force TMipd to stay in the foreground. If you now look at the logfile...

[root@tnode1 tmipd]$ cat /var/log/tmipd.log

+ Logging started for TMip Correspondent Node [v0.14a]

+ Bringing up TMipd services...

   [MLRP Session Dispatcher]: Done.
   [MLRCache]: Done.
   [Tunnel Controller]: Done.

+ Supported tunnels (in order of preference):
   + Local loopback tunnels (1000 devices)
   + Standard IPv4 in IPv4 (50 devices)

+ Purging system of stale tunnel devices:

+ Checking connectivity to MLR @ 10.13.0.250: Seems ok.

+ Establishing local address allocation pool:
   + Available [10.13.102.4 --> 10.13.102.248 mask: 255.255.255.252

+ Binding CN to the mobile network [my-tmip-mobility]: Bind accepted.

+ Using the following CN interface...
   + Interface: rl0
   + IP: 10.13.0.250
   + Mac: 00:03:ce:88:62:c3
   + Subnet: 255.255.255.248
   + Broadcast: 10.13.0.255

+ Using the following mobile facing interface...
   + Interface: rl1
   + IP: 10.13.100.1
   + Mac: 00:d0:70:01:04:48
   + Subnet: 255.255.255.0
   + Broadcast: 10.13.100.255

+ Checking for address pool conflicts:

+ Using IP/ARP activity for migration detection

+ Launching final migration detection services...

   [ProxyAdapter]: Done.
   [DHCP Server]: Done.

+ Attempting network re-establish - Querying MLR: None listed

+ Correspondent node [10.13.0.250] (My Test CN) is now up and running...

Review the logfile for errors, it should give hints on what might be wrong. The most common problems are invalid MLR address (check it resolves), incorrect network name, and network interfaces that are not correct. I recommend starting tmipd with the -F parameter until you have everything working, and also with a higher debug level. The default is 2 (see the debug_level option). The higher (max 7) the more output. When in interactive mode, typing 'debug' then entering a number between [0..7] will set it at run time. Can also use the -D parameter option.

See this section for more details on the various signals you can send to the MLR and TMipd.

Oh yeah, it will now be live ;-). If you go to your MLR and type bindings you should see this new CN listed! You can exit the application by calling kill on its process ID. This will cause it to exit nicely (using Ctrl+D when the application is in the foreground does the same).

Repeat the above process for every CN in your network.

 Correspondent Node Interactive Commands

There are lots of commands for tmipd, again, not very pretty but functional all the same. Eventually, I guess most of this could be done remotely, access to all host data etc can already be obtained using MLRP. Note that these can only be used when the application is in the foreground (option foreground true).

  • show: Lists currently active hosts in the network
  • showstatics: List static host entries
  • showall: Combination of the above two
  • clear: Clears the dynamic host list
  • clearall: Clears all host entries
  • purge: Does as above, but removes ignore entries too
  • tunnels: Shows the status of the current tunnel allocation
  • detach: Exactly the same as all mobile hosts suddenly leaving this cell
  • debug: Adjusts debug output. Enter a number in the range [0..4]. 0 is no output, 4 is just silly :)
  • resync: A useful command. Will attempt to resync with the MLR. Useful if things have got a little dodgy
  • showignores: Shows the list of all hosts currently being ignored
  • revokeignores: Stops ignoring every host we were ignoring a second ago

Remember: To exit this application you should use Ctrl+d. That will clear up everything, and detach all clients. If you don't use this, your routing table and tunnel list will contain extra entries!

These should hopefully all be cleared up in the near future!

Goto Top



Effortless Migration

If you want an easy way to migrate around your test network, take a look at the perl script linked to off the main page.


 Going Mobile!

 Finding Your Parent

So, by now I assume you have your MLR, secondary MLR (if you want) and all the CNs set up and running. Basically, that's it! Yep, you can now go mobile!

All you have to do now is simply turn on your DHCP client on your host. You should be allocated an IP address and a chunk of network. In addition, if you now did another DHCP request in another CN, you would get back the old address you had. You can also request IPs from CNs other than the one you are currently bound to.

You can also manually set IP addresses if you want. Simply pick an allocation out of one of your CNs address space and type it in. So, lets assume you have a CN with its mobile facing interface serving the 10.13.100.0/24 subnet (be it an access point or wired). Unless you have specified otherwise, addresses in the range of 10.13.100.4/30 to 10.13.100.248/30 will be available. Pick the first, say, and put into your device the following (replacing the prefix, of course):

  • IP: 10.13.100.5
  • Gateway: 10.13.100.6
  • Netmask: 255.255.255.252
  • Broadcast: 10.13.100.7 (this is normally not required, but I've been told some Linux hosts require some help working out the broadcast)

TMip rule of thumb: Given some network address N, IP = N + 1, Gateway = N + 2, Broadcast = N + 3.

However, using DHCP is a much easier option! Now, try pinging something on your network, or the CN IP say.

If all is correctly configured and working, turning on DHCP on a client should output something like the following in the logfile:

-> Mobile station detected in my cell [00:01:f4:ee:90:44] (via DHCP activity - Discover)
  + Establishing host's address allocation
    + Success -> From local address pool
    + Notifying MLR of host's new status
    + Using 10.13.100.9 on 10.13.100.8/255.255.255.252 gw:10.13.100.10
    + Committing changes to MLR: Done.

-> Mobile host [00:01:f4:ee:90:44] has arrived in this cell

Note that you can set the level of debug output by using the debug_level X option, or the -D parameter to tmipd or mlrd. If in interactive (foreground) mode, type debug and enter a value between 0 and 7. 7 is all debug on (rather silly!). If you have specified an IP manually, and you get something like the following...

-> Mobile station detected in my cell [00:01:f4:ee:90:44] (via IP or ARP activity)
  + Establishing host's address allocation
  + [WARNING]: Failure to bind host locally!

-> Ignoring host [00:01:f4:ee:90:44] for 15 second(s)

This occurs when the IP address of the client is incorrect, i.e. it doesn't match anything within this CNs address space. A CN will make its best effort to give you the address you have (even if it is within the address space of another CN, and there is a static MLR entry). If you get this, check your IP address (it should be network number + 1 remember). This shouldn't happen when using DHCP.

If all is ok, you should now be able to ping stuff as normal! Well done, you are now connected to the mobile network, ready to go wandering? If your migrations don't seem to happen, try using debug level 3, as it will tell you exactly what broke in the migration process.

If you always want a host to be allocated a specific IP and address allocation via DHCP no matter where they appear in the network, see the section on registering hosts with the MLR.

 Migrating Somewhere

Assuming you have more than one CN set up, wander over to it (be that by binding to the new access point, physically plugging yourself in, or holding your laptop in various positions/hiding behind cupboards to block out the old CN ;-)

Most problems during migration are due to traffic not getting between the two CNs. Remember that each CN needs to be able to contact the MLR on TCP port 6554, and every other CN on TCP port 5554. In addition, some versions of Linux install spoof protection and firewall rules by default. These can break everything! Turn off spoof protection, and check your firewall rules.

Assuming your mobile device is pinging some host, when your attach to the new CN... the following should happen... In the logfile of the new CN...

-> Mobile station detected in my cell [00:01:f4:ee:90:44] (via IP or ARP activity)
  + Establishing host's address allocation
    + Success -> Restored from MLR
    + Notifying MLR of host's new status
  + Attempting mobile host handover [migrated from 10.13.100.1] parent 10.13.100.1
    + Contacting transaction participants
    + Requesting tunnel between parent CN and local CN
      + Agreed to use tunnel type [MLRP_TUN_4IN4]
    + All OK, going for commit
    + Using 10.13.100.9 on 10.13.100.8/255.255.255.252 gw:10.13.100.10
    + Committing changes to MLR: Done.

-> Mobile host [00:01:f4:ee:90:44] has arrived in this cell

On the old (parent CN)

-> Mobile host [00:01:f4:ee:90:44] has left this cell

Obviously all the IPs will be different, but still.. Right, well if you didn't notice, if everything was happy, you should have just transparently migrated to a foreign cell! Your pings should all still be going! So, in the example above, my host with an IP 10.13.100.9 is working quite happily in the foreign network 10.13.101.0/24!

To convince yourself, open up a few SSH sessions, maybe some streaming video, anything else you can think of, and start wandering between your CNs! Everything should stay live and happy, and you can admire the debug output on route. You may want to start introducing some new clients, just pick appropriate address allocations and let them talk!

You can even get a DHCP lease under one CN, then release it, migrate to another CN, start up your DHCP client again and you will get back the same IP address and allocation (assuming the entry has not timed out in the MLR in the process).

The following output should be shown on the new CN when you migrate from some CN which isn't your parent. You will notice the extra lines where it details the removal of the old tunnel to the previous CN before attaching the host locally.

-> Mobile station detected in my cell [00:01:f4:ee:90:44] (via IP or ARP activity)
  + Establishing host's address allocation
    + Success -> Restored from MLR
    + Notifying MLR of host's new status
  + Attempting mobile host handover [migrated from 10.13.101.1] parent 10.13.100.1
    + Contacting transaction participants
    + Tearing down tunnel between old CN and parent CN
      + Prepared to destroy
    + Requesting tunnel between parent CN and local CN
      + Agreed to use tunnel type [MLRP_TUN_4IN4]
    + All OK, going for commit
    + Using 10.13.100.9 on 10.13.100.8/255.255.255.252 gw:10.13.100.10
    + Committing changes to MLR: Done.

Goto Top

 Signals

You can send various signals to mlrd and tmipd to control their behaviour. Sending either HUP will cause them to re-read their configuration files. Note that not all settings are read in (such as interface names). Sending either a USR1 signal will cause them to output a status file (specified by status_file, or the default of tmipd.status or mlrd.status). This contains details of local and remote hosts, and details of tunnels when issued to tmipd. Finally, with tmipd, sending it a USR2 signal causes it to re-synchronise with the MLR (same as terminating it then restarting it). With the MLR, it causes it to clear its dynamic host cache.

See tmipd.rc and mlrd.rc files for more details on signals and the whole configuration process.

Goto Top



Web Interface

We are currently working on a web based interface to allow clients to register their MAC to join the mobile network.

See the TMip project page for more details.


 Registered Host Deployment

By default, this application runs in a fully open mode, hence any host doing a DHCP request will be allocated address space. You may want to run the application in registered only mode, which can also be useful for test deployments.

As an addition, I recommend using the screen application so you can login/logout of CN's and MLR's without loosing access to the command interface.

 Running in Registered Mode

The CN applications can run in what's called registered mode. All this means is that a CN will not bind a new mobile host locally if either a static or dynamic entry is not present in the MLR. This means that you can register in the MLR the MAC addresses of the clients that you want to treat as mobile, and ignore the rest.

To put the CN applications into this mode, simply put registered_only true into the configuration file. Now, if you attempt to bind to that CN, you will be ignored (for a default of 600 seconds), as the following shows:

-> Mobile station detected in my cell [00:01:f4:ee:90:44] (via DHCP activity - Discover)
   + Establishing host's address allocation
   + [WARNING]: MLRP communications failure! (Mobile host not registered in MLR)
   + [WARNING]: Failure to bind host locally!

-> Ignoring host [00:01:f4:ee:90:44] for 600 second(s)

 Registering Users

For a registered user to be present in the system, there needs to be a static entry present in the MLR. Now, if such an entry is present, this basically means that the host will always receive that IP allocation no matter where in the network they pop up. If they suddenly appear in a foreign CN cell, all the tunnels will be created auto-magically. This also applies to the DHCP server. This means that your mobile clients can have fixed addresses, which can be inserted into DNS for example, and you will know that foo.my-tmip-mobility.bar.com will always point at your laptop, no matter if it is in your house, or wandering down the street to work!

Currently, the way to get registered host entries into the MLR is to use the mlrp_query tool. This can be used to grab information out of the MLR, and send it updates. Eventually this will go into the GUI management application.

To be able to update the MLR (and until I've fixed the whole authentication thingy), you will need to grant update rights to the IP of the client issuing the mlrp_query commands. So, on the MLR type grant, and then enter the IP of the host.

The easiest way is to let the MLR handle allocation of addresses, so issuing the following command would give the host 00:01:f4:ee:90:44 a static MLR entry under the CN 10.13.100.1. From the tmip/mlrp_query directory...

./mlrp_query -M10.13.0.250 -A -m00:01:f4:ee:90:44 -p10.13.100.1

Obviously change your MLR address (the -M parameter), and parent CN (-p). This will return the next available allocation such as...

0:1:f4:ee:90:44 10.13.100.9 10.13.100.8 255.255.255.252 10.13.100.10 10.13.100.1 10.13.100.1

This is in the order (MAC, IP, Network, Subnet, Gateway, Parent CN, Current CN). If you wish to allocate a specific IP to a host, use the -i parameter followed by the IP you want.

This tool is pretty useful, such as getting a listing of every host currently in the network...

[root@tnode3 tmipuser]# ./mlrp_query -M10.13.0.250 -Q
0:2:f4:ee:90:88 10.13.100.5 10.13.100.4 255.255.255.252 10.13.100.6 10.13.100.1 10.13.100.1
0:3:f4:ee:90:88 10.13.100.13 10.13.100.12 255.255.255.252 10.13.100.14 10.13.100.1 10.13.100.1
0:4:f4:ee:90:88 10.13.100.17 10.13.100.16 255.255.255.252 10.13.100.18 10.13.7.1 10.13.100.1
0:5:f4:ee:90:88 10.13.100.21 10.13.100.20 255.255.255.252 10.13.100.22 10.13.100.1 10.13.100.1
0:6:f4:ee:90:88 10.13.100.25 10.13.100.24 255.255.255.252 10.13.100.26 10.13.0.1 10.13.100.1
0:7:f4:ee:90:88 10.13.100.29 10.13.100.28 255.255.255.252 10.13.100.30 10.13.101.1 10.13.100.1
0:8:f4:ee:90:88 10.13.100.33 10.13.100.32 255.255.255.252 10.13.100.34 10.13.100.1 10.13.100.1
0:9:f4:ee:90:88 10.13.100.37 10.13.100.36 255.255.255.252 10.13.100.38 10.13.7.1 10.13.100.1

A list of this applications parameters are...

  • -M: MLR location
  • -A: Allocate address space
  • -q: Query static entries
  • -Q: Query dynamic entries
  • -m: MAC of host
  • -i: IP of host
  • -g: Gateway address for host
  • -s: Subnet of host
  • -n: Network address of host
  • -p: Parent CN of host
  • -c: Current CN of host

 Using the Registered Network

Once you have your MAC registered, you will be able to use the network as normal. Simply switch on DHCP, and you will be allocated the address mapped to your MAC in the MLR. If you are having problems (like it ignoring you), note that if you attempted to connect to the network whilst unregistered, it will be ignoring you for 600 seconds! Easy way to solve this is to issue the revokeignores command into the CN interface. Also see the showignores command to see which hosts are currently being ignored by the CN.

 The SOWN Test Network

The current SOWN test network consists of various access points around the house. It is currently running on eight meshed nodes across the University, providing coverage across most of the University campus. Of course, every node is running TMip! See here for an example of one of the most recent nodes.

An example of the network running, with three CN's, primary and secondary MLRs and 17 hosts can be seen below. The tool I'm using to visualise the network works in real time, pulling configuration data out of the MLR and CNs (including details of tunnels etc). The idea is to make this application the central management interface (but of course, anything that speaks MLRP can do this... so the stack is there to be implemented over!). I plan to release this application and source soon (Delphi 5).

Goto Top




 Network Management and Control

The main method of network management is the mlrp_query tool, and MLR/CN interfaces. Like I've said before, this is an early release of this software, so most work has gone into getting the application working correctly, and nice stuff like interfaces will come along later!

However, we wanted it so that there was little network management needed. Unless you are using the registered test deployment discusses above, it should just work. As it is still an early release, things can go wrong, tunnels in a twist etc. Refer to the FAQ section below for details on the common situations that may arise, and how you can get out of them. A useful command is resync in the CN interface, which does the same as closing the application and restarting it.

The CN application is designed to be robust, in the fact that you can close the application, do something (like patch and recompile), then start it back up, and it will attempt to restore its state from the MLR. So, apart from the obvious down time to local clients, the network should stay together.

It is envisioned that the application pictured above will become the central management facility for tmip, or maybe a web based version (any offers, anyone? :-). A Perl MLRP protocol implementation is pretty much complete, and will act as the basis for this web interface. I hope to include details of this soon.

One of the SOWN developers have created a perl interface to MLRP (the protocol used by the CNs and MLR to communicate). He has also created some scripts to display the current TMip network. All of this is included on the TMip project page, under the name swig.

There is an example output generated using this script here.

Goto Top



More Questions?

If you have more questions, feel free to ask! Then I can begin to fill in this section!


 Frequently Asked Questions

 General

Where can I find help?

Visit #tmip or #sown on irc.sown.org.uk. You can also email me at sly@slyware.com, or use the forums on the main SourceForge site.

 During the Running of the Correspondent Node

I want to know exactly what is going on in my CN!

No problem, type debug then enter 4.

Goto Top