Tuesday, August 21, 2007

DTN Additional Notes

An extra step required to make DTN configure after building is to add the following to the configure command in the berkeleydb.mk file in the buildroot packages directory:
--with-mutex=ARM/gcc-assembly \
CFLAGS=-fPIC \
After making this change, the db-* directory should be purged from the build_arm_nofpu directory to ensure proper rebuilding.

Without this change, DTN will will encounter the following error while initializing the db:
DB internal error: "unable to initialize mutex: Function not implemented"
Also when DTN is being built, it expects to find TCL header files in /usr/local/tcl-arm/include and TCL libraries in /usr/local/tcl-arm/lib. On the host system these should be linked to {buildroot_dir}/build_arm_nofpu/root/include and {buildroot_dir}/build_arm_nofpu/root/usr/lib respectviely.

After DTN is built, /lib/tcl8.4 should be linked to /usr/lib/tcl8.4, or during db initialization DTN will be very verbose about a misconfigured TCL installation.

Wednesday, August 15, 2007

DTN overview and instructions

DTN is a disaster tolerant network implementation. Some samples of how to use it and a short description may be found here. Over the past few weeks I've been trying to configure it to perform link state routing. I wanted to document all the things I had to set up to get discovery and routing to work, as well as any issues I've encountered with putting DTN on an arm platform.

To set it up, first add dtn2 package to buildroot. I took what Dave from prisms put together and adapted it to the new version of dtn. The package files can be grabbed here. Download the tarball, extract into ${gumstix-buildroot}/package and add dtn2 to the list of packages in Config.in. DTN depends on having a storage db and a tcl interpreter. Both need to be included in your buildroot make config before adding dtn to it. I found that building those first helps as well. The package files assume berkeleydb is the one installed. Also, the dtn package files assume that there is a local tcl build for arm in /usr/local/tcl-arm. You can change that by modifying the dtn2.mk file. Lastly, I forgot to amend the patch and it currently breaks. The fix is to add "-I/usr/local/tcl-arm/include" to LDFLAGS otherwise it won't be able to locate the tcl.h file. The file to modify for this is Rules.in in the ${dtn2}/oasys folder. After this dtn should build fine.

Once dtn is built, to configure it for dtlsr the following has to be done. For a simple scenario, you have to specify the interfaces and route type, as well as the node name. The interfaces are specified with "interface name type", e.g. interface udp0 udp or interface tcp0 tcp. This will create a listening socket on 0.0.0.0 on the default port (4556). To specify the node name add 'route local_eid "name"' in the routing configuration. Another piece is to set the routing to use the dtlsr router. This can be done with 'route set type dtlsr'.

Lastly to use dtlsr the nodes need to send and listen for discoveries from other nodes. To set up the listening portion use the following command: 'discovery add discovery_name ip port=2000 local_addr=192.168.1.1'. The local_addr option is not required but useful if dtn should listen on only one interface. The port option is required and the ip type uses udp packets to broadcast. Now to add the announcements use the following: discovery announce name discovery_name tcp interval=5 cl_addr=192.168.1.1. This will send announcements using udp every 5 seconds on the interface with address 192.168.1.1. If you have multiple interfaces, each of these has to be specified, i.e. you need an announcement for each with the interface ip address.

In order to change configuration of a running dtn instance, one can telnet to port 5050 on localhost and then execute all of the commands specified in the config file manually. One can also view the available routes, links, bundles, etc. To view the bundles use "bundle list". To view the routing table use "route dump".

This is sufficient to set up a simple dtn with link state routing. Often times you'd like to retrieve the data from this network. For that purpose one could define a static link to a receiving computer that has a static ip. To do that use this command:
link add NAME dtn.dtnrg.org:4556 ONDEMAND tcp. Also add a route for it with: route add dtn://eid/* linkNAME. For example, route add dtn://dtnrg.dtn/* NAME. This will setup a static link to dtn.dtnrg.org node on port 4556 and create a route for it, assuming the eid is dtn://dtnrg.dtn. The information sent can be viewed on the receiver with bundle list or use the dtnrecv command, which takes the destination dtn node eid and prints bundles addressed to it to screen.

Lastly, before running the dtn daemon for the first time you have to initialize the storage database. Do that with dtnd --init-db. Add "-c config_file" to use the "config_file". To set the storage, comment out
foreach dir {/var/dtn /var/tmp/dtn} {
if {[file isdirectory $dir]} {
set dbdir $dir
break
}
}
and specify the db with 'set dbdir "/home/dtn"' for example.

Monday, August 6, 2007

dtlsr and discovery

I got dtlsr to work properly, thanks to Mike Demmer for the pointers. In order to set it up one has to set route type to dtlsr and then it is important to also add discovery to the configuration. Here are the lines I used to set that up:
discovery add discovery_bonjour ip port=2000
discovery announce tcp0 discovery_bonjour tcp interval=5

They're pretty straightforward and there are more options for the commands I believe. In the end you should see node announcements broadcast every 5 seconds on port UDP 2000. You can verify if it's running by looking at a packet capture through wireshark. My next step is to test a simple three-four node network. The setup will involve a three wireless nodes: one with just one card in ad-hoc mode, acting as an end node; one with two cards on two different ad-hoc networks acting as a relay; lastly, the last gumstix node will be a gateway to a wired network where a destination node, my laptop is setup. I would like to test if dtn will handle traversing different subnets and also I'd like to see how long it takes to discover a path and how disconnected the network can be (essentially verify the paper on dtlsr: http://www.cs.berkeley.edu/~demmer/papers/dtlsr-nsdr.pdf)

Thursday, August 2, 2007

ad-hoc on prism2 with wlan-ng drivers

We were doing range tests with the antennae yesterday and I realized that I forgot how to put the prism2 cards with the wlan-ng driver in ad-hoc mode. I figured I'd put it here in case anyone else has that issue. Here is the command:
wlanctl-ng wlan0 dot11req_start ssid=gumstix bsstype=independent \
beaconperiod=100 dtimperiod=3 cfpollable=false cfpollreq=false cfpperiod=3 \
cfpmaxduration=100 probedelay=100 dschannel=11 basicrate1=2 \
basicrate2=4 operationalrate1=2 operationalrate2=4 operationalrate3=11
It should be run after wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable. Sometimes the cards needs to be reset for this to work properly as well. Also, not all the options are required. For instance I believe the rates may be omitted.

I also have dtn running on the gumstix and I've been thinking of the best way to handle links, since we would want to do store and forward at every node, thus if packets are sent to the gateway they will not be stored on the hops in between. I learnt that there is a linkstate routing implementation for dtn. The router is named dtlsr. I will try to set it up and get working, since it seems exactly what we've been looking for.