Hi Romeu

In the standard configuration all bundles are kept in RAM, so yes: Upon shutdown everything is lost. Of course IBR-DTN has also persistent storage. See the storage options in the config file. You want to set at least a storage_path

# # define a folder for persistent storage of bundles # if this is not defined bundles will stored in memory only # storage_path = /var/spool/ibrdtn/bundles

if you use uci-style configuration in OpenWRT set "option bundles" under the "config 'daemon' 'storage'" group in the ibrdtn config

If you are working with large bundles you might also want to set a blob_path (option blobs)

I am not sure about your network situation, however, as long as IP works, IBR-DTN should work. Is the problem, that the nodes do not _discover_ each other (i.e. you do not see "nodeXX available" log messages)? IP-Multicast needs to work for discovery to work. Or is the problem, that the nodes discover each other, but IBR-DTN is unable to establish a TCP connection? If this is the case, can other apps establish a TCP connection (e.g. netcat) ?

Sebastian

On 2014-04-08 10:11, Romeu Monteiro wrote:

Dear all,

I have two questions regarding IBR-DTN:

• If the daemon (or the device where the daemon is running) is turned

off, all the bundles in storage and data from the Prophet routing algorithm are lost, right? Is there anyway to prevent this? We have devices which are sometimes turned off and we would not like them to loose all their information each time that happens.

• We are having problems transfering files between devices, and

perhaps between different subgroups of IP addresses. In our case, we have 3 devices originally set on the IP addresses: 20.0.5.13/24 [1], 20.0.5.56/24 [2] and 20.0.6.66/24 [3]. We changed the network mask (to 16 bits) to allow all the devices to contact each other. With this change, we can ping and even dtnping all the devices with each other. In spite of that, while we are able to send files from 20.0.5.13 to 20.0.5.56, we cannot send them from 20.0.6.66 to 20.0.5.56. It seems we cannot exchange files with the 20.0.6.66 board at all using IBR-DTN. Is there something we should be careful about in this situation? Some kind of network mask situation IBR-DTN cannot handle yet?

Thank you,

Romeu

Links:

[1] http://20.0.5.13/24 [2] http://20.0.5.56/24 [3] http://20.0.6.66/24