- Ibr-dtn - lists.ibr.cs.tu-bs.de

IBR DTN and Raspbian Jessie
by Walter Preuninger 16 Sep '16

16 Sep '16

I would really like to start experimenting with DTN. I have ION installed from packages on both Ubuntu x64 and Raspberry Pi (jessie) I can’t seem to to get DTN complied cleanly for OS X 10.11 or on Linux. I have IBR installed on my x64 Ubuntu machine, but it won’t cleanly compile on Jessie. Can anyone help, or point me to jessie .deb packages instead of wheezy? Thanks, Walter

3 2

Queries with IBR-DTN
by Himanshu Avinash Jethawa 29 Jul '16

29 Jul '16

Hello all, I am a student at Missouri University, USA. I have been doing research on DTNs and came across IBR-DTN. I found the paper really intriguing. I have been using the applications IBR-DTN and ShareBox on Android and I found that it uses only wi Fi for connection. I know how it uses wifi router as a storage device. I have three questions as follows and any help on these will be highly appreciated. 1)Will I be able to use Bluetooth for this, atleast only for android? 2) If yes, will it be easy to do development for Bluetooth? 3) Also, does it have multi hop feature as well? Thanks and regards, Himanshu Jethawa, Computer science, Missouri University of Science and technology, Rolls-MO, USA.

1 0

buffer management policy‏
by Jorg Eloy 27 Jul '16

27 Jul '16

Dear all, Do you know which buffer management policy is used by IBR-DTN to flush the buffer and send out the buffered bundles to the end node? To me, it looks like a random (I mean not FIFO, not LIFO). I have looked on the web information but I could not find any concrete information about it. Thank you very much in advance. Best regards, Jorg

1 0

Build for android
by Chen Yang 11 May '16

11 May '16

Hi guys, I've been trying to build ibr-dtn for android on OS X 10.11. When I try to build the java code, there was an error: ibrdtn/android/app/src/main/java/de/tubs/ibr/dtn/stats/StatsEntry.java:16: error: package de.tubs.ibr.dtn.swig does not exist I notice that I should probably run generate_swig_classes.sh first, but in that script, the output was set to *src*/de/tubs/ibr/dtn/swig/ instead of *java*/de/tubs/ibr/dtn/swig/. If I copy the folder (*src*/de/tubs/ibr/dtn/swig/) to the latter one, it compiles successfully. Is this a typo in the script? Best regards, Chen

2 1

missing the bundle security protocols key pairs
by Jorg Eloy 08 May '16

08 May '16

Dear all, I am using IBR-DTN 1.0.1 (294b543) among three raspberry pi devices called (dtn1,dtn2,dtn3). In order to try to connect to the other side with dtnsend and dtnrecv applications. With one RPi works fine but with the rest I get an error on open and requeue the bundles, I resume on the next lines: ORIG -> DST = OBSERVATION ------------------------------ dtn1 -> dtn2 = works fine :) dtn1 -> dtn3 = TCPConnection: connection to dtn://dtn3 failed dtn2 -> dtn1 = bundle rejected due to invalid authentication dtn2 -> dtn3 = bundle rejected due to invalid authentication dtn3 -> dtn1 = bundle rejected due to invalid authentication dtn3 -> dtn2 = works fine :) I am using the default demon configuration, calling the command "dtnd -i eth0" on each raspberry Pi. The files that are in each terminal are: pi@dtn1 ~ $ ls /etc/ibrdtn/bpsec/ dh_params.pem pi@dtn2 ~ $ ls /etc/ibrdtn/bpsec/ 64746e3a2f2f6963747064746e32.pkey 64746e3a2f2f6963747064746e32.pub 64746e3a2f2f6963747064746e32.pub.txt 64746e3a2f2f7261737062657272797069.pkey 64746e3a2f2f7261737062657272797069.pub 64746e3a2f2f7261737062657272797069.pub.txt dh_params.pem pi@dtn3 ~ $ ls /etc/ibrdtn/bpsec/ dh_params.pem So, As you can see the problem looks like missing files on RPi dtn1 and dtn3. My question is how I can generate a new local key-pair? Thank you very much in advance for any kind of help you might be able to give me. Best regards, Jorg pd. I have seen a similar problem in http://comments.gmane.org/gmane.network.ibrdtn/975 but I do not use the "security_bab_default_key" and the solution of this problem still open.

2 1

Fwd: RE: TCP CL & interoperability with ION
by Carlo Caini 04 May '16

04 May '16

Dear IBR-DTN maintainers, I have just received the answer below from Scott Burleigh, regarding ipn syntax and interoperability between IBR-DTN and ION via TCP-CL. I will remail it on this mailing list. In the meantime I have also tested routing rules with ipn scheme in IBR-DTN and I am happy to inform you all that all tests passed! This means that full interoperability with ION can be achieved with the (I suppose not too difficult) fix suggested below. I have not tested BSP security yet. Of course, I am willing to provide you with further details or explanations if useful. I look forward to hearing from you. Yours, Carlo >Hi, Carlo. I'm sorry, the last couple of weeks >have been quite difficult and I am only now >catching up on the emails. Some remarks in-line below. > >Scott > >-----Original Message----- >From: Carlo Caini [<mailto:carlo.caini@unibo.it>mailto:carlo.caini@unibo.it] >Sent: Sunday, April 24, 2016 3:40 AM >To: ibr-dtn(a)ibr.cs.tu-bs.de >Cc: Burleigh, Scott C (312B) <scott.c.burleigh(a)jpl.nasa.gov> >Subject: TCP CL & interoperability with ION > >In these days I have carried out some >interoperability tests between IBR-DTN and ION >with TCP as CL (RFC7242, June 2014). >When the TCP connection is established, the TCP >CL sends a message, called contact header, >including the local EID. Each end-node sends its >contact header to the corresponding pair. What >happens then is largely left to the implementation. >Let me assume that you have two nodes, 1 and 2, >with IBR-DTN on 1 and ION on 2. When the TCP >connection is started by ION, we have a failure >because IBR-DTN advertises itself back as ipn:1 >instead of ipn:1.0. In other words, ION performs >a check on the EID of the corresponding node, >and this check fails because of the lack of the last part of the EID (".0"). > > > Right. When ION initiates the > connection, it does so under the guidance of > the "egress plans" that identify its > neighbors. Each egress plan associates a node > ID with a convergence-layer endpoint ID, e.g., > a socket name; since node IDs are formed as DTN > endpoint IDs, the ION node's egress plan for > the IBR-DTN node associated the EID "ipn:1.0" > with that node's socket name. When the > answering contact header says that the > neighboring node identifies itself as "ipn:1" > instead, ION detects that the node it has > connected to is not the one it was trying to > connect to, so for safety it drops the connection. > >If the connection is started from IBR-DTN it >succeeds, maybe because ION does not perform a >similar check in input, but I am not sure. > > > Yes. In this case, ION has no idea who > the connecting node is, so the EID in the > IBR-DTN node's contact header can't be > validated against anything; it is simply accepted. > >The details of my test (Test3) are below. >I have noticed that in other logs IBR-DTN makes >use of a "shothened" ipn EID to identify a node, as below: >Sat Apr 23 20:52:51 2016 NOTICE ConnectionEvent: connection up ipn:2 > >Sat Apr 23 20:52:51 2016 NOTICE NodeEvent: Node ipn:2 available > >Sat Apr 23 20:52:51 2016 NOTICE ConnectionEvent: connection down ipn:2 > > From the man of ipnadmin (see below) it seems > that an ipn EID always includes a service > number, and in practice that "0" is used as default. > > > Actually the service number is simply > mandatory; the registered definition for the > "ipn" URI scheme requires it. The definition > also reserves service number 0 for > "administration" or something like that, as I recall. > >If this is correct, I suppose that IBR-DTN >should always use ipn:1.0 instead of ipn:1. However, I could also be wrong. > > > Nope, you are correct. > >I have also successfully performed an analogue >test (Test 4) with the dtn scheme. In this case >the EID given back by IBR-DTN is dtn://vm1.dtn, >which is the same EID expected by ION; note that >in ION configuration, in the line a plan >//vm1.dtn x tcp/10.0.1.1 "//vm1.dtn" is the name >of the node, equivalent to "1" in ipn. In brief, >in the dtn scheme it seems not necessary to include a demux token as in ipn. >As ipn and dtn syntaxes are often challenging >also to people that are familiar with DTN, I >send this mail in cc also to Scott Burleigh, >which is the ION and ipn scheme designer in >order to have confirmation of the ipn syntax. >Yours, > Carlo > >Test 3) Failed. The TCP CL of IBR DTN gives >ipn:1 where ipn:1.0 is expected by ION (syn from ION) From vm1 ibrdtn.conf > ># the local eid of the dtn node ># default is the hostname >local_uri = ipn:1.0 > > From vm2 ION configuration file >#Outduct to Vm1 >a outduct tcp 10.0.1.1 '' >a plan 1 x tcp/10.0.1.1 > > From vm2 logs >[2016/04/23-19:01:10] [i] Connected to TCP >socket: 10.0.1.1:4556 [2016/04/23-19:01:10] [?] >expected tcpcl EID: ipn:1.0 >[2016/04/23-19:01:10] [?] received tcpcl EID: >ipn:1 [2016/04/23-19:01:10] [i] tcpcli got no valid contact header: ipn:1.0 > >Test 4) Passed The TCP CL of IBR DTN gives >dtn://vm1 as expected by ION (syn from ION) From >vm1 ibrdtn.conf # the local eid of the dtn node ># default is the hostname local_uri = dtn://vm1.dtn > > From vm2 ION configuration >#Outduct to Vm1 >a outduct tcp 10.0.1.1 '' >a plan //vm1.dtn x tcp/10.0.1.1 > > > From the man of ipnadmin (ION) >ipnadmin configures the local ION node's routing >of bundles to endpoints whose IDs conform to the >ipn endpoint ID scheme. ipn is a CBHE-conformant scheme; > that is, every endpoint ID in the ipn > scheme is a string of the form > "ipn:node_number.service_number" where node_number is a CBHE "node number" and > service_number identifies a specific application processing point. > >5x1000 AI GIOVANI RICERCATORI >DELL'UNIVERSITÃEUR DI BOLOGNA >Codice Fiscale: 80007010376 > 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI BOLOGNA Codice Fiscale: 80007010376

2 3

TCP CL & interoperability with ION
by Carlo Caini 29 Apr '16

29 Apr '16

In these days I have carried out some interoperability tests between IBR-DTN and ION with TCP as CL (RFC7242, June 2014). When the TCP connection is established, the TCP CL sends a message, called contact header, including the local EID. Each end-node sends its contact header to the corresponding pair. What happens then is largely left to the implementation. Let me assume that you have two nodes, 1 and 2, with IBR-DTN on 1 and ION on 2. When the TCP connection is started by ION, we have a failure because IBR-DTN advertises itself back as ipn:1 instead of ipn:1.0. In other words, ION performs a check on the EID of the corresponding node, and this check fails because of the lack of the last part of the EID (".0"). If the connection is started from IBR-DTN it succeeds, maybe because ION does not perform a similar check in input, but I am not sure. The details of my test (Test3) are below. I have noticed that in other logs IBR-DTN makes use of a "shothened" ipn EID to identify a node, as below: Sat Apr 23 20:52:51 2016 NOTICE ConnectionEvent: connection up ipn:2 Sat Apr 23 20:52:51 2016 NOTICE NodeEvent: Node ipn:2 available Sat Apr 23 20:52:51 2016 NOTICE ConnectionEvent: connection down ipn:2 From the man of ipnadmin (see below) it seems that an ipn EID always includes a service number, and in practice that "0" is used as default. If this is correct, I suppose that IBR-DTN should always use ipn:1.0 instead of ipn:1. However, I could also be wrong. I have also successfully performed an analogue test (Test 4) with the dtn scheme. In this case the EID given back by IBR-DTN is dtn://vm1.dtn, which is the same EID expected by ION; note that in ION configuration, in the line a plan //vm1.dtn x tcp/10.0.1.1 "//vm1.dtn" is the name of the node, equivalent to "1" in ipn. In brief, in the dtn scheme it seems not necessary to include a demux token as in ipn. As ipn and dtn syntaxes are often challenging also to people that are familiar with DTN, I send this mail in cc also to Scott Burleigh, which is the ION and ipn scheme designer in order to have confirmation of the ipn syntax. Yours, Carlo Test 3) Failed. The TCP CL of IBR DTN gives ipn:1 where ipn:1.0 is expected by ION (syn from ION) From vm1 ibrdtn.conf # the local eid of the dtn node # default is the hostname local_uri = ipn:1.0 From vm2 ION configuration file #Outduct to Vm1 a outduct tcp 10.0.1.1 '' a plan 1 x tcp/10.0.1.1 From vm2 logs [2016/04/23-19:01:10] [i] Connected to TCP socket: 10.0.1.1:4556 [2016/04/23-19:01:10] [?] expected tcpcl EID: ipn:1.0 [2016/04/23-19:01:10] [?] received tcpcl EID: ipn:1 [2016/04/23-19:01:10] [i] tcpcli got no valid contact header: ipn:1.0 Test 4) Passed The TCP CL of IBR DTN gives dtn://vm1 as expected by ION (syn from ION) From vm1 ibrdtn.conf # the local eid of the dtn node # default is the hostname local_uri = dtn://vm1.dtn From vm2 ION configuration #Outduct to Vm1 a outduct tcp 10.0.1.1 '' a plan //vm1.dtn x tcp/10.0.1.1 From the man of ipnadmin (ION) ipnadmin configures the local ION node's routing of bundles to endpoints whose IDs conform to the ipn endpoint ID scheme. ipn is a CBHE-conformant scheme; that is, every endpoint ID in the ipn scheme is a string of the form "ipn:node_number.service_number" where node_number is a CBHE "node number" and service_number identifies a specific application processing point. 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI BOLOGNA Codice Fiscale: 80007010376

2 1

dtnd and CPU usage
by Maël Auzias 10 Apr '16

10 Apr '16

Hi you all! I would like to know you some of you experienced a 100% CPU usage by dtnd. If so in which case, what triggered this behavior and how was it corrected (if it was). As for me, some of the node I run consume 100% of CPU and still cannot find out why. Any help or suggestion welcome. Have a nice day! --- The dtnd version is 1.0.1, as for the configuration: local_uri = dtn://$HOSTNAME logfile = /dev/null discovery_address = 224.0.0.142 discovery_timeout = 1 discovery_interval = 1 net_interfaces = eth net_eth_type = tcp net_eth_interface = ethwe0 net_eth_port = 4556 keepalive_timeout = 5 routing = flooding static1_proto = tcp static1_immediately = yes static1_global = no dht_enable_ipv6 = no dht_enabled = yes limit_bundles_in_transit = 100 Best regards, --- Auzias Maël auzias.net <https://www.auzias.net/en/> - vcard <https://www.auzias.net/auzias.vcf> - thesis <http://people.irisa.fr/Mael.Auzias/> *GSM: 0033 695 118 774*

2 2

Re: [ibr-dtn] Bluetooth convergence layer support?
by Sebastian Schildt 28 Feb '16

28 Feb '16

Hello Xiaoyang There is a clear answer to this: It depends. 1. So, if a Wi-Fi interfaces is deactivated (no „wlan0“ or something device) IBR-DTN can not bind a convergence layer or discovery to the interface when starting. So probably it will also not work after the interface comes online (IBR-DTN on the mobile phone can handle this, for the normal Linux version I am not sure, if there will be a late-bind to the interface when it comes online. Johannes would know…) 2. If there is a Wi-Fi interface, and it looses/changes IP addresses for example because it is roaming between different Wi-Fis or looses contact for some time, it is not a problem. IBR-DTN will always broadcast/multicast on the local network segment, so once two nodes are in the same segment/broadcast domain, they can discover each other and exchange messages 3. If the nodes are in different networks, they can still discover each other if the „cloud uplink“ is activated in the Android version. This goes through the internet through a DTN Router we provide. You can achieve the same effect with your own setup, by adding a static neighbour, that can be reached from all your networks to the configuration of all DTN nodes (maybe this is not possible with the GUI in Android…) 4. IBR-DTN has nothing to do with auto-configuration of IP addresses, however it should work just fine with such addresses. So, if two nodes in the same network segment use IPV6 Link local addresses only, or they randomly choose some IPv4 address using ZeroConf/APIPA (169…) or some similar approach, they should be able to discover each other and communicate. Sebastian > On 21 Feb 2016, at 08:27, Xiaoyang Zhu <zxcykuaile(a)gmail.com> wrote: > > Dear Schildt, > > Thanks for your response. I still have a question. If two IBR-DTN nodes are not in the same local network, but the WiFi switch turns on, I was wondering whether this two nodes can discover each other and send the message. In another words, if they could form the self-organized network, auto-configure IP address. > > Best Regards > > Xiaoyang > > > >> On Feb 20, 2016, at 12:10 PM, Sebastian Schildt <schildt(a)ibr.cs.tu-bs.de> wrote: >> >> Hello Xiaoyang, >> >> If you just need to use Bluetooth as transport, but do not need any deep integration or dynamic with BT this might already be possible out of the box using the BT NAP profile. This basically allows IP networks over a BT connection (this is usually used for Bluetooth Tethering). For example on {.}Ubuntu platforms this already works out of the box using „Bluman“ and „Networkmanager“. >> >> When working on security, note that there is some work going on developing an updated version of the Bundle Security protocol in the DTN WG (https://www.ietf.org/proceedings/90/dtn.html). The current version is found here https://tools.ietf.org/html/draft-ietf-dtn-bpsec-00 >> So far nobody has implemented it for iBR-DTN (or any other platform for that matter), but when researching/developing any new security features, it is probably a good idea to check how well the align with/complement the new specification >> >> >> Sebastian >> >> >> >> >> >>> On 19 Feb 2016, at 10:12, Xiaoyang Zhu <xiaoyang.zhu(a)insa-lyon.fr> wrote: >>> >>> Dear All, >>> >>> Recently, we launched a project to develop a set of the security interfaces using secret sharing method to enhance the security of DTN based on IBR-DTN. >>> >>> Since the project may use the Bluetooth as the communication protocol, we want to figure out whether there is any ongoing group developing the Bluetooth convergence layer adapter? >>> >>> >>> Xiaoyang Zhu >>> INL, INSA de Lyon >>> Bâtiment Blaise Pascal >>> 20, Avenue Albert Einstein >>> 69621 Villeurbanne Cedex >>> >>> >>> >>> >>> >>> >>> -- >>> !! This message is brought to you via the `ibr-dtn' mailing list. >>> !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust >>> !! your settings, send a mail message to <ibr-dtn-request(a)ibr.cs.tu-bs.de> >>> !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn. >> >

3 2

Streaming using webcam IBR-DTN
by Nazmi Febrian 27 Feb '16

27 Feb '16

Hi Everyone, Currently I'm working on streaming video project using IBR-DTN. I have run this command in sender machine: dtntunnel dtn://node1.dtn/tunnel *noe2.dtn as sender, node1.dtn as receiver. I have set the type of convergence layer to udp. But I have no idea how to listen the streaming in receiver because command 'dtntunnel' in receiver dooesn't have Listening mode. How can I do that? Best Regards, Nazmi Febrian Electrical Engineering, Institut Teknologi Bandung

1 0