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 \
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 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='. 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= This will send announcements using udp every 5 seconds on the interface with address 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
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.

Friday, July 27, 2007

RTC on the PXA270

In order to get DTN working properly in the future we need to have RTC setup and working on the gumstix. Jeremy and I at first thought that we could simply attach a backup battery to the V_BACKUP pin on the power control chip. We tried that and had 3V coming out on the V_RTC pin, but still the RTC would reset on every power down/restart. Then we thought it may be in software, so I looked through the driver code and commented out the line that resets the clock if the status register is misbehaving. The resets still persisted. Finally, I found out that on the PXA270 the RTC is on the chip and in order to keep the oscillator running we'd need to power the whole chip (at least keep it in deep sleep mode) and keep RAM alive. We decided to order an external RTC board, which is a DS1307 board which has I2C interface. Gumstix already has the patches for these boards and it should be pretty easy to get them setup once they come in and just set the PXA RTC to the external RTC.

Also, I've started to look at the CLA code for DTN2 and I'm still trying to figure out whether DTN sends out the bundles or if the CL has to do that. I should be able to understand that pretty soon. Ideally, I'll be able to simply notify DTN2 of link changes and have it handle message delivery. All the discovery can already be done by OLSR anyway.

Wednesday, July 25, 2007

more dtn on gumstix

I found that for some reason berkeleydb refuses to use pthreads installed on the gumstix. I've tried building the db with test and set by supplying "ARM/gcc-assembly". Also, I had to add -fPIC to CFLAGS to get it dtnd to load it on the verdex board. Lastly, it appears that the dtn build compiles in absolute paths, which has its issues since now it looks for the tcl in /home/timur/.... I ended up adding a symlink to the build. I will add more here once I make more progress.

Ok, Berkeley DB seems to be running with test-and-set, but now dtn crashes at the assertion: ASSERTION FAILED ((u_int)now.tv_sec >= TIMEVAL_CONVERSION) at bundling/BundleTimestamp.cc:39. I tried adding printf in there to see the value of now.tv_sec and I tried printing it to a file, but neither way produced any output (I did replace the dtnd file after recompiling). I'm not sure what the issue is and how to go about resolving it. I will look into this more tomorrow. I'm hoping Brian will know something about this, but not keeping my hopes up. If I can figure out why nothing is printed it'd be a big step in troubleshooting.

EDIT: Ok, the problem is not with the code or the assertion. DTN checks if the time is past midnight UTC December 31st, 1999 is (probably to make sure packet dates can be used correctly). The gumstix were set to midnight December 31st, 1969, thus the assertion was failing. I have DTN now running on the gumstix.

Monday, July 23, 2007

dtn and hostap

I built DTN for verdex with reasonable success and no big issues. For connex, using revision 1360 proved to be difficult so I tried a different one. Right now I'm trying to build revision 1340 with the packages required by dtn. One thing I have to fix is the path for berkeley db (which was also an issue with verdex). I think this will be done by tomorrow and then I can test it out.

On another note, with hostap it appears that ap_scan is very useful, as we can check ssids without invoking scan directly but instead examine the file in proc. This can be great in the future when we want passive scans to happen and simply check whether a new access point is available. I don't know if the linux-wlan driver supports this, but would be neat.

Justin has the communication setup and we looked into powering devices up/down. Looks like we can do it with wireless pretty easily by pccardctl and eject/insert commands. We're going to do more power measurements to verify that the card does indeed consume less power in that mode. I could not find a gpio pin to toggle to turn it off. Hopefully this will be sufficient.