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

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

Bluetooth convergence layer support?
by Xiaoyang Zhu 23 Feb '16

23 Feb '16

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

4 3

Beacon issues when using IBR-DTN on Android
by Gwilherm Baudic 20 Feb '16

20 Feb '16

Hello everyone, I am currently experimenting with the IBR-DTN application for Android in order to get familiar with it. More specifically, my setup is as follows: * 2 Android smartphones (Android 4.1 and 6.1.0) running IBR-DTN from the Play store (app 1.0 dtnd 1.0.1 build 570f2b9) and Whisper 1.6, also downloaded from the Play store. Smartphones do not have any 3G/4G connection enabled and only have Wifi available for the experiment. * 1 Wifi access point to which both smartphones are connected. What I am trying to achieve is very simply, as a first step, to check if both phones can see each others as neighbours (in the Neighbor list of IBR-DTN), and try to transfer some Whisper text messages between them. The settings on IBR-DTN are: Epidemic routing Discovery policy always on Cloud connect Off Wifi direct Off Security is deactivated Time synchronization is also deactivated Log parameters are set to Debugging with verbosity level 99 and I chose to save the text files as well for further inspection. I experimented with several access points (ISP router at home, campus Wifi, dedicated router on my desk in the lab). From the observations I made from the phones and the log files, it seems that beacons are getting produced (and exchanged) only when the access point has a connection to the Internet. I feel like I am missing something here, and that the actual reason for the lack of beacons is totally unrelated to the Internet connectivity. Does anyone have any idea on this? On a side note, the naming scheme for the log files looks rather strange to me. For example, for a log file starting on February 15th, 2016 at 16:15:02, the resulting filename I obtain is 2016115154152 while I would expect something closer to 20160215161502. With the changing length, the current naming scheme has the drawback of breaking the alphabetical order, thus making it really inconvenient to work with lots of files with different start dates. Best regards, Gwilherm Baudic PhD student, ISAE-SUPAERO

3 3

Re: [ibr-dtn] Missing link on IBR-DTN site
by Kris Grala 05 Feb '16

05 Feb '16

Thank you Johannes... K‎ris From: morgenroth(a)ibr.cs.tu-bs.de Sent: Friday, February 5, 2016 11:18 AM To: Kris Grala; ibr-dtn(a)ibr.cs.tu-bs.de Subject: AW: [ibr-dtn] Missing link on IBR-DTN site Hello Kris, the page has been merged into a generic page for ARM based platforms. https://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/platform/debian-arm Kind regards, Johannes Morgenroth Von: Ibr-dtn [mailto:ibr-dtn-bounces@ibr.cs.tu-bs.de] Im Auftrag von Kris Grala Gesendet: Donnerstag, 4. Februar 2016 23:03 An: ibr-dtn(a)ibr.cs.tu-bs.de Betreff: [ibr-dtn] Missing link on IBR-DTN site Hi, I have noticed that: The link in IBR-DTN (platform/raspberrypi) is not there anymore. Can you re-post the link so the link from https://www.ibr.cs.tu-bs.de/trac/ibr-dt ... aspberrypi will point to the correct location? Currently the link to: https://trac.ibr.cs.tu-bs.de/project-cm ... aspberrypi<https://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/platform/raspberry…> has this error: Track Error: Page platform/raspberrypi not found Thank you.

1 0

Missing link on IBR-DTN site
by Kris Grala 05 Feb '16

05 Feb '16

Hi, I have noticed that: The link in IBR-DTN (platform/raspberrypi) is not there anymore. Can you re-post the link so the link from https://www.ibr.cs.tu-bs.de/trac/ibr-dt ... aspberrypi will point to the correct location? Currently the link to: https://trac.ibr.cs.tu-bs.de/project-cm ... aspberrypi<https://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/platform/raspberry…> has this error: Track Error: Page platform/raspberrypi not found Thank you.

3 2

UDP Convergence Layer Ignored
by Nik Ansell 02 Feb '16

02 Feb '16

Thank you for the clarification Johannes. Kind Regards, Nik > > Message: 2 > Date: Sun, 31 Jan 2016 10:36:37 +0100 > From: <morgenroth(a)ibr.cs.tu-bs.de> > To: <nikansell00(a)gmail.com> > Cc: ibr-dtn(a)ibr.cs.tu-bs.de > Subject: Re: [ibr-dtn] UDP Convergence Layer Ignored > Message-ID: <020001d15c0a$e1eae0f0$a5c0a2d0$(a)ibr.cs.tu-bs.de> > Content-Type: text/plain; charset="utf-8" > > Just to clarify the confusion. > > The parameter “-i <interface>” is a short-cut for a TCP Convergence Layer > entry bound on that interface. It just adds an entry to the existing ones > within the configuration. > > > > Kind regards, > > Johannes Morgenroth > > > > > > Von: Ibr-dtn [mailto:ibr-dtn-bounces@ibr.cs.tu-bs.de] Im Auftrag von Nik > Ansell > Gesendet: Montag, 18. Januar 2016 15:11 > An: Stephan Rottmann <rottmann(a)ibr.cs.tu-bs.de> > Cc: ibr-dtn(a)ibr.cs.tu-bs.de > Betreff: Re: [ibr-dtn] UDP Convergence Layer Ignored > > > > Yes, this fixed it. > > > > The -i <interface> dtnd startup option was conflicting with the interface > definition in the conf file. > > Starting dtnd without the -i option worked fine. > > > > > Kind Regards, > Nik > > > > On Mon, Jan 18, 2016 at 4:02 PM, Nik Ansell <nikansell00(a)gmail.com > <mailto:nikansell00@gmail.com> > wrote: > > Hi Stephan, > > > > I have just tried again on a brand new installation and observed something > strange, hopefully I have found a fix to the problem. > > I tried to troubleshoot in stages, this is what I did: > > > > 1. Start dtnd with default conf file - Started OK with no convergence layer > > 2. Add custom conf file (below conf1), but do not specify the correct > interface name, also do not start dtnd with -i option - Started OK with UDP > Convergence layer (Datagram ConvergenceLayer (UDP) added on eth0:4556) > > 3. Add custom conf file (below conf2) with correct interface name and use > -i option - Fails: (TCP ConvergenceLayer added on eno16777736:4556) > > 4. Revert back to step 2 - Started OK with UDP Convergence layer (Datagram > ConvergenceLayer (UDP) added on eth0:4556) > > 5. Add custom conf file (below conf2) with correct interface name and > _do_not_ use -i dtnd startup option - Works: (Datagram ConvergenceLayer > (UDP) added on eno16777736:4556) > > > > I think perhaps the net_eth_interface option in the conf file and the -i > dtnd startup option may be conflicting with each other. It appears to start > OK using only the net_eth_interface option in the conf file. > > When I am logged on to my test bed in a few hours I will try some data > transfers and report back. > > > > Kind Regards, > > Nik > > > > Conf1: > > local_uri = dtn://rx > > net_eth_type = dgram:udp > > #net_internet = eth0 > > net_eth_interface = eth0 > > net_eth_port = 4556 > > net_interfaces = eth > > > > # Create a route to tx > > static1_uri = dtn://tx > > static1_port = 4556 > > static1_address = 10.0.0.1 > > static1_proto = dgram:udp > > static1_immediately = yes # connect immediately to this node > > #static1_global = no # this node is only reachable with internet access > > > > Conf2: > > local_uri = dtn://rx > > net_eth_type = dgram:udp > > #net_internet = eno16777736 > > net_eth_interface = eno16777736 > > net_eth_port = 4556 > > net_interfaces = eth > > > > # Create a route to tx > > static1_uri = dtn://tx > > static1_port = 4556 > > static1_address = 10.0.0.1 > > static1_proto = dgram:udp > > static1_immediately = yes # connect immediately to this node > > #static1_global = no # this node is only reachable with internet access > > > > routing = default > > stats_traffic = yes > > api_interface = lo > > > > **dtnd startup line and output (UDP starts OK, but not bound to a working > nic) > > /home/alarm/downloads/ibr-dtn/install/sbin/dtnd -c > /home/alarm/downloads/ibr-dtn/source/ibrdtn-repo/ibrdtn/daemon/etc/rx.conf > > Mon Jan 18 15:33:05 2016 INFO NativeDaemon: IBR-DTN daemon 1.0.1 (build > a5f9012) > > Mon Jan 18 15:33:05 2016 INFO Configuration: Configuration: > /home/alarm/downloads/ibr-dtn/source/ibrdtn-repo/ibrdtn/daemon/etc/rx.conf > > Mon Jan 18 15:33:05 2016 INFO BundleCore: Local node name: dtn://rx > > Mon Jan 18 15:33:05 2016 INFO BundleCore: Forwarding of bundles enabled. > > Mon Jan 18 15:33:05 2016 INFO BundleCore: Non-singleton bundles are > accepted. > > Mon Jan 18 15:33:05 2016 INFO NativeDaemon: using bundle storage in > memory-only mode > > Mon Jan 18 15:33:05 2016 INFO NativeDaemon: API initialized using tcp > socket: lo:4550 > > Mon Jan 18 15:33:05 2016 INFO NativeDaemon: Datagram ConvergenceLayer > (UDP) added on eth0:4556 > > Mon Jan 18 15:33:05 2016 INFO DiscoveryAgent: listen to [ff02::142]:4551 > > Mon Jan 18 15:33:05 2016 INFO DiscoveryAgent: listen to [224.0.0.142]:4551 > > Mon Jan 18 15:33:05 2016 INFO DiscoveryAgent: add interface eth0 > > Mon Jan 18 15:33:05 2016 INFO NativeDaemon: Using default routing > extensions > > > > ** dtnd startup line and output (Always uses TCP Convergence layer) > > /home/alarm/downloads/ibr-dtn/install/sbin/dtnd -c > /home/alarm/downloads/ibr-dtn/source/ibrdtn-repo/ibrdtn/daemon/etc/rx.conf > -i eno16777736 > > Mon Jan 18 15:37:33 2016 INFO NativeDaemon: IBR-DTN daemon 1.0.1 (build > a5f9012) > > Mon Jan 18 15:37:33 2016 INFO Configuration: Configuration: > /home/alarm/downloads/ibr-dtn/source/ibrdtn-repo/ibrdtn/daemon/etc/rx.conf > > Mon Jan 18 15:37:33 2016 INFO BundleCore: Local node name: dtn://rx > > Mon Jan 18 15:37:33 2016 INFO BundleCore: Forwarding of bundles enabled. > > Mon Jan 18 15:37:33 2016 INFO BundleCore: Non-singleton bundles are > accepted. > > Mon Jan 18 15:37:33 2016 INFO NativeDaemon: using bundle storage in > memory-only mode > > Mon Jan 18 15:37:33 2016 INFO NativeDaemon: API initialized using tcp > socket: lo:4550 > > Mon Jan 18 15:37:33 2016 INFO NativeDaemon: TCP ConvergenceLayer added on > eno16777736:4556 > > Mon Jan 18 15:37:33 2016 INFO DiscoveryAgent: listen to [ff02::142]:4551 > > Mon Jan 18 15:37:33 2016 INFO DiscoveryAgent: listen to [224.0.0.142]:4551 > > Mon Jan 18 15:37:33 2016 INFO DiscoveryAgent: add interface eno16777736 > > Mon Jan 18 15:37:33 2016 INFO NativeDaemon: Using default routing > extensions > > > > > Kind Regards, > Nik > > > > On Mon, Jan 18, 2016 at 2:18 PM, Nik Ansell <nikansell00(a)gmail.com > <mailto:nikansell00@gmail.com> > wrote: > > Hi Stephan, > > > > Thank you for your kind reply. > > > > I originally tried both net_eth_type = udp & static1_proto = udp, but this > didn't work. > > I will try them both as dgram:udp later and respond back. > > > > > Kind Regards, > Nik > > > > On Mon, Jan 18, 2016 at 2:00 PM, Stephan Rottmann < > rottmann(a)ibr.cs.tu-bs.de <mailto:rottmann@ibr.cs.tu-bs.de> > wrote: > > Hi Nik, > > > static1_uri = dtn://rx > > static1_port = 4556 > > static1_address = 10.0.1.3 > > static1_proto = udp > Have you tried dgram:udp at this point? > > > Best regards, > Stephan > > > > > > > > > >

1 0