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

Re: [ibr-dtn] What does "IBR-DTN" stand for?
by Frank Steinberg 14 Oct '22

14 Oct '22

IBR is simply the abbreviation of the german name of the institute at Technische Universität Braunschweig, where this software has been developed: Institut für Betriebssysteme und Rechnerverbund – Institute of Operating Systems and Computer Networks. https://www.ibr.cs.tu-bs.de/projects/ibr-dtn/?lang=de

1 0

What does "IBR-DTN" stand for?
by adria mallorqui 15 Sep '22

15 Sep '22

Hello everyone, I do not know if this has been answered before, but I could not find anywhere on the Internet an answer to this simple question. What does "IBR-DTN" stand for? I assume "DTN" stands for Delay Tolerant Network(ing), but what about "IBR"? Thank you in advance for your kind answer!

1 0

bash: dtninbox: command not found
by Daniel Serra Bernad 21 Sep '21

21 Sep '21

Hi, I'm currently working with IBR-DTN to connect two raspberries. The commands dtnping, dtnsend and dtnrecv work perfectly. Nevertheless, when I try to use the commands dtninbox and dtnoutbox a message saying "bash: dtninbox: command not found" appears. In both raspberries I built the protocol from source following the steps on this guide " https://github.com/ibrdtn/ibrdtn/wiki/Build-IBR-DTN#git-repository ". I also fixed the bug https://mail.ibr.cs.tu-bs.de/pipermail/ibr-dtn/2016-May/001082.html before doing the ./configure make and make install commands. If there´s something I missed or did wrong, please tell me. Thank you very much, Dani. [https://opengraph.githubassets.com/f2b6c207727365cdbbd697410b15388d32a9665e…]<https://github.com/ibrdtn/ibrdtn/wiki/Build-IBR-DTN#git-repository> Build IBR DTN · ibrdtn/ibrdtn Wiki<https://github.com/ibrdtn/ibrdtn/wiki/Build-IBR-DTN#git-repository> A modular and lightweight implementation of the bundle protocol. - Build IBR DTN · ibrdtn/ibrdtn Wiki github.com 

1 1

Bundle rejected due to invalid authentification
by Daniel Serra Bernad 13 Jul '21

13 Jul '21

Hi, I am trying to connect two raspberry pi between them using the protocol IBR-DTN. I builted them both from source. The built and install worked perfectly, but even though both nodes can see eachother i have not been able to dtnping one node from the other one. Every time I try to do a dtnping a message saying “bundle rejected due to invalid authentication ([0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm)” appears on the log file. I will attach here the log file from the device that sends the dtnping: Tue Jul 13 09:14:01 2021 INFO NativeDaemon: IBR-DTN daemon 1.0.1 (build 294b543) Tue Jul 13 09:14:01 2021 INFO Configuration: Configuration: /etc/ibrdtn/ibrdtnd.conf Tue Jul 13 09:14:01 2021 INFO NativeDaemon: use logfile for output: /var/log/ibrdtn/ibrdtn.log Tue Jul 13 09:14:01 2021 INFO NativeDaemon: Parallel event processing enabled using 4 processes. Tue Jul 13 09:14:01 2021 INFO BundleCore: Local node name: dtn://node49.dtn Tue Jul 13 09:14:01 2021 INFO BundleCore: Forwarding of bundles enabled. Tue Jul 13 09:14:01 2021 INFO NativeDaemon: using bundle storage in memory-only mode Tue Jul 13 09:14:01 2021 NOTICE GlobalEvent: Internet connection is available. Tue Jul 13 09:14:01 2021 INFO DTNTPWorker: Time-Synchronization enabled: slave mode Tue Jul 13 09:14:01 2021 INFO NativeDaemon: API initialized using tcp socket: any:4550 Tue Jul 13 09:14:01 2021 INFO NativeDaemon: TCP ConvergenceLayer added on any:4556 Tue Jul 13 09:14:01 2021 INFO DiscoveryAgent: listen to [224.0.0.142]:4551 Tue Jul 13 09:14:01 2021 INFO DiscoveryAgent: listen to [ff02::142]:4551 Tue Jul 13 09:14:01 2021 INFO DiscoveryAgent: add interface any Tue Jul 13 09:14:01 2021 NOTICE ConnectionEvent: connection setup dtn://node48.dtn Tue Jul 13 09:14:01 2021 NOTICE NodeEvent: Node dtn://node48.dtn available Tue Jul 13 09:14:01 2021 INFO NativeDaemon: Using default routing extensions Tue Jul 13 09:14:01 2021 NOTICE ConnectionEvent: connection up dtn://node48.dtn Tue Jul 13 09:17:47 2021 NOTICE BundleReceivedEvent: Bundle received [0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm (local) Tue Jul 13 09:17:47 2021 NOTICE BundleEvent: bundle [0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm received Tue Jul 13 09:17:47 2021 NOTICE QueueBundleEvent: New bundle queued [0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm Tue Jul 13 09:17:47 2021 NOTICE BundlePurgeEvent: purging bundle [0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm Tue Jul 13 09:17:47 2021 NOTICE TransferAbortedEvent: transfer of bundle [0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm to dtn://node48.dtn aborted. (bundle has been refused) And here I attach the log file from the device that receives the dtnping: Tue Jul 13 09:13:59 2021 INFO NativeDaemon: IBR-DTN daemon 1.0.1 (build 294b543) Tue Jul 13 09:13:59 2021 INFO Configuration: Configuration: /etc/ibrdtn/ibrdtnd.conf Tue Jul 13 09:13:59 2021 INFO NativeDaemon: use logfile for output: /var/log/ibrdtn/ibrdtn.log Tue Jul 13 09:13:59 2021 INFO NativeDaemon: Parallel event processing enabled using 4 processes. Tue Jul 13 09:13:59 2021 INFO BundleCore: Local node name: dtn://node48.dtn Tue Jul 13 09:13:59 2021 INFO BundleCore: Forwarding of bundles enabled. Tue Jul 13 09:13:59 2021 NOTICE GlobalEvent: Internet connection is available. Tue Jul 13 09:13:59 2021 INFO NativeDaemon: using bundle storage in memory-only mode Tue Jul 13 09:13:59 2021 INFO DTNTPWorker: Time-Synchronization enabled: master mode Tue Jul 13 09:13:59 2021 INFO NativeDaemon: API initialized using tcp socket: any:4550 Tue Jul 13 09:13:59 2021 INFO NativeDaemon: TCP ConvergenceLayer added on any:4556 Tue Jul 13 09:13:59 2021 INFO DiscoveryAgent: listen to [224.0.0.142]:4551 Tue Jul 13 09:13:59 2021 INFO DiscoveryAgent: listen to [ff02::142]:4551 Tue Jul 13 09:13:59 2021 INFO DiscoveryAgent: add interface any Tue Jul 13 09:13:59 2021 NOTICE NodeEvent: Node dtn://node49.dtn available Tue Jul 13 09:13:59 2021 NOTICE ConnectionEvent: connection setup dtn://node49.dtn Tue Jul 13 09:13:59 2021 WARNING TCPConnection: connection to dtn://node49.dtn failed Tue Jul 13 09:13:59 2021 INFO NativeDaemon: Using default routing extensions Tue Jul 13 09:14:01 2021 NOTICE ConnectionEvent: connection up dtn://node49.dtn Tue Jul 13 09:17:47 2021 WARNING BundleFilter: bundle rejected due to invalid authentication ([0.1200640435] dtn://node49.dtn/wswNupEItdVEiINm) I will attach now a summary of the configuraion file: ##################################### # IBR-DTN daemon # ##################################### local_uri = dtn://node48.dtn logfile = /var/log/ibrdtn/ibrdtn.log ##################################### # convergence layer configuration # ##################################### discovery_address = ff02::142 224.0.0.142 discovery_crosslayer = yes net_interfaces = lan0 net_autoconnect = 30 net_internet = eth0 net_lan0_type = tcp # we want to use TCP as protocol net_lan0_interface = any # listen on interface eth0 net_lan0_port = 4556 # with port 4556 (default) ##################################### # routing configuration # ##################################### routing = default routing_forwarding = yes routing_prefer_direct = yes ## node49.dtn ### static1_address = 172.16.21.49 # the node has the address 172.16.21.49 static1_port = 4556 # accept bundles on port 4556 static1_uri = dtn://node49.dtn # eid of the node is "dtn://node49.dtn" static1_proto = tcp # reachable over TCP static1_immediately = yes # connect immediately to this node static1_global = no # this node is only reachable with internet Access ##################################### # bundle security protocol # ##################################### security_level = 0 security_path = /etc/ibrdtn/bpsec security_trusted_ca_path = /etc/ibrdtn/certs ##################################### # time synchronization # ##################################### time_synchronize = yes ##################################### # DHTNameService settings # ##################################### dht_enabled = yes dht_bootstrapping = no The other node has the same config file but with the static route of the first node. Any solution or advice will be welcomed, thank you! Daniel.

2 1

TCP connection failing via port 4556
by Daniel Serra Bernad 13 May '21

13 May '21

Hi, We recently decided to use IBR DTN on our project. By now we are only trying to connect two virtual machines with Ubuntu16: VM1(master) & VM2(slave). The connection we are trying to make is TCP via port 4556 (I will try to summarize the configuration files below). I am guessing that this is not really a problem, but we are using the interface ens160 since it does not appear any eth0 when we call the ifconfig command as shown below: docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:0d:4f:20:73 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.2.133 netmask 255.255.255.0 broadcast 172.16.2.255 inet6 fe80::311d:dd0f:5b1f:10a0 prefixlen 64 scopeid 0x20<link> ether 00:50:56:b8:d3:96 txqueuelen 1000 (Ethernet) RX packets 48696 bytes 32047604 (32.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14348 bytes 1994383 (1.9 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 1434 bytes 155169 (155.1 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1434 bytes 155169 (155.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 As soon as we start the daemon at the master this message appears in its log file: Mon May 10 09:41:37 2021 INFO NativeDaemon: IBR-DTN daemon 1.0.1 (build 294b543) Mon May 10 09:41:37 2021 INFO Configuration: Configuration: /etc/ibrdtn/ibrdtnd.conf Mon May 10 09:41:37 2021 INFO NativeDaemon: use logfile for output: /var/log/ibrdtn/ibrdtn.log Mon May 10 09:41:37 2021 INFO NativeDaemon: Parallel event processing enabled using 3 processes. Mon May 10 09:41:37 2021 INFO BundleCore: Local node name: dtn://VM1 Mon May 10 09:41:37 2021 INFO BundleCore: Forwarding of bundles enabled. Mon May 10 09:41:37 2021 INFO SecurityKeyManager: initialized; path: /etc/ibrdtn/bpsec Mon May 10 09:41:37 2021 INFO NativeDaemon: using bundle storage in memory-only mode Mon May 10 09:41:37 2021 INFO DTNTPWorker: Time-Synchronization enabled: master mode Mon May 10 09:41:37 2021 INFO NativeDaemon: API initialized using tcp socket: any:4550 Mon May 10 09:41:37 2021 INFO NativeDaemon: TCP ConvergenceLayer added on ens160:4556 Mon May 10 09:41:37 2021 INFO NativeDaemon: TCP ConvergenceLayer added on any:4556 Mon May 10 09:41:37 2021 INFO DiscoveryAgent: listen to [224.0.0.142]:4551 Mon May 10 09:41:37 2021 INFO DiscoveryAgent: listen to [ff03::142]:4551 Mon May 10 09:41:37 2021 INFO DiscoveryAgent: add interface ens160 Mon May 10 09:41:37 2021 INFO DiscoveryAgent: add interface any Mon May 10 09:41:37 2021 NOTICE GlobalEvent: Internet connection is available. Mon May 10 09:41:37 2021 ERROR TCPConvergenceLayer: bind failed (failed to getaddrinfo with address: [fe80::311d:dd0f:5b1f:10a0%ens160]:4556 (link)) Mon May 10 09:41:37 2021 INFO DHTNameService: DHT initialized on Port: 9999 with ID: Mon May 10 09:41:37 2021 ERROR IPNDAgent: Join failed on ens160 ([fe80::311d:dd0f:5b1f:10a0%ens160]:4551 (link), family: 10); failed to getaddrinfo with address: [fe80::311d:dd0f:5b1f:10a0%ens160]:4551 (link) Mon May 10 09:41:37 2021 INFO NativeDaemon: Using default routing extensions Mon May 10 09:41:37 2021 WARNING DHTNameService: bootstrapping from default domain failed with error: -2 Mon May 10 09:41:46 2021 WARNING DHTNameService: bootstrapping from default domain failed with error: -2 Mon May 10 09:42:00 2021 NOTICE NodeEvent: Node dtn://VM2 available Then, when we start the second daemon this message is shown in its log file: Mon May 10 09:41:59 2021 INFO NativeDaemon: IBR-DTN daemon 1.0.1 (build 294b543) Mon May 10 09:41:59 2021 INFO Configuration: Configuration: /etc/ibrdtn/ibrdtnd.conf Mon May 10 09:41:59 2021 INFO NativeDaemon: use logfile for output: /var/log/ibrdtn/ibrdtn.log Mon May 10 09:41:59 2021 INFO NativeDaemon: Parallel event processing enabled using 3 processes. Mon May 10 09:41:59 2021 INFO BundleCore: Local node name: dtn://VM6 Mon May 10 09:41:59 2021 INFO BundleCore: Forwarding of bundles enabled. Mon May 10 09:41:59 2021 INFO SecurityKeyManager: initialized; path: /etc/ibrdtn/bpsec Mon May 10 09:41:59 2021 INFO NativeDaemon: using bundle storage in memory-only mode Mon May 10 09:41:59 2021 INFO DTNTPWorker: Time-Synchronization enabled: slave mode Mon May 10 09:41:59 2021 NOTICE GlobalEvent: Internet connection is available. Mon May 10 09:41:59 2021 INFO NativeDaemon: API initialized using tcp socket: any:4550 Mon May 10 09:41:59 2021 INFO NativeDaemon: TCP ConvergenceLayer added on ens160:4556 Mon May 10 09:41:59 2021 INFO DiscoveryAgent: listen to [224.0.0.142]:4551 Mon May 10 09:41:59 2021 INFO DiscoveryAgent: listen to [ff02::142]:4551 Mon May 10 09:41:59 2021 INFO DiscoveryAgent: add interface ens160 Mon May 10 09:41:59 2021 ERROR TCPConvergenceLayer: bind failed (failed to getaddrinfo with address: [fe80::49b0:e031:c4a5:6586%ens160]:4556 (link)) Mon May 10 09:41:59 2021 INFO DHTNameService: DHT initialized on Port: 9999 with ID: Mon May 10 09:41:59 2021 ERROR IPNDAgent: Join failed on ens160 ([fe80::49b0:e031:c4a5:6586%ens160]:4551 (link), family: 10); failed to getaddrinfo with address: [fe80::49b0:e031:c4a5:6586%ens160]:4551 (link) Mon May 10 09:41:59 2021 INFO NativeDaemon: Using default routing extensions Mon May 10 09:42:00 2021 WARNING DHTNameService: bootstrapping from default domain failed with error: -2 Mon May 10 09:42:03 2021 NOTICE NodeEvent: Node dtn://VM1 available Mon May 10 09:42:03 2021 NOTICE BundleReceivedEvent: Bundle received [0.1547405242] dtn://VM2/dtntp (local) Mon May 10 09:42:03 2021 NOTICE QueueBundleEvent: New bundle queued [0.1547405242] dtn://VM2/dtntp Mon May 10 09:42:03 2021 NOTICE BundleEvent: bundle [0.1547405242] dtn:// VM2/dtntp received Mon May 10 09:42:03 2021 NOTICE ConnectionEvent: connection setup dtn:// VM1 Mon May 10 09:42:03 2021 WARNING TCPConnection: connection to dtn:// VM1 failed Mon May 10 09:42:03 2021 NOTICE RequeueBundleEvent: Bundle requeued [0.1547405242] dtn://VM2/dtntp >From that point on, the last three messages keep repeating every few seconds. I have read in past messages from this list that the ERROR line which says “bind failed” only concerns to IPv6 and that we should not worry about it, but the daemons still cannot connect to each other. They can see each other but testing it with Wireshark we have seen that when the slave sends a packet to establish the TCP connection to the master the second one returns a packet with the reset flag activated. I have attached two images on this mail showing the results of the wireshark monitoring of the interface ens160 on both machines. Looking for the meaning of the reset flag we found that usually means that the port wanted to be used is closed. And indeed, it seems to be closed. Using the command “netstat -tulpen” we can see the following ports (VM1 example): Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN - tcp6 0 0 ::1:631 :::* LISTEN - tcp6 0 0 :::4550 :::* LISTEN - As you can see the port 4556 does not appear at all. In addition, when we write from VM2 the command “nmap -p- <IP VM1>” the results are the following: Starting Nmap 7.60 ( https://nmap.org ) at 2021-05-10 11:01 CEST Nmap scan report for 172.16.2.133 Host is up (0.00031s latency). Not shown: 65534 closed ports PORT STATE SERVICE 4550/tcp open gds-adppiw-db Nmap done: 1 IP address (1 host up) scanned in 1.80 seconds As you can see again the only port that seems to be open is port 4550, but not port 4556. I will greatly appreciate any kind of help. Best regards, Daniel Serra. Config files: (the only thing that changes from both machines is that the only config file with the option “time_reference” set to yes is VM1 the rest have this option disabled) ##################################### # IBR-DTN daemon # ##################################### logfile = /var/log/ibrdtn/ibrdtn.log api_interface = any api_port = 4550 ##################################### # convergence layer configuration # ##################################### discovery_address = ff03::142 224.0.0.142 discovery_crosslayer = yes net_interfaces = lan0 net_autoconnect = 60 net_internet = ens160 net_lan0_type = tcp # we want to use TCP as protocol net_lan0_interface = ens160 # listen on interface ens160 net_lan0_port = 4556 # with port 4556 (default) ##################################### # routing configuration # ##################################### routing = default routing_forwarding = yes routing_prefer_direct = yes ##################################### # bundle security protocol # ##################################### security_path = /etc/ibrdtn/bpsec security_trusted_ca_path = /etc/ibrdtn/certs ##################################### # time synchronization # ##################################### time_reference = yes time_synchronize = yes time_discovery_announcements = yes ##################################### # DHTNameService settings # ##################################### dht_enabled = ye

1 0

Re: [ibr-dtn] dtnstream: Lost Bundles
by João Pedro Loureiro 19 Jan '21

19 Jan '21

Hello, again! I'm sorry for the delay in the answer. First, I want to thank you for the attention and the advice, it was very helpful! .....But I still have some issues with this situation, so I'm here to ask some more questions. --' In fact, dtnrecv does work even when some bundles are lost but, in my case the order should be kept, i.e., I want to proceed with the next seq. nr. available even when some bundles are lost. I tried to use the parameter “-t” of dtnstream, but my dtnstream receiver keeps waiting forever, and the video is never displayed again, although the bundles are supposedly delivered (I've realized that accessing the API of the daemon via telnet and using the option: protocol management->stats bundles). Can this be a bug, or am I missing something? Thanks (a lot) in advance! João P. T. Loureiro Dr. Johannes Morgenroth <johannes(a)morgenroth.me> escreveu no dia quarta, 23/12/2020 à(s) 09:21: > Hello João. > > > > Your observation is correct. The tool dtnstream is designed to split-up a > continuous stream into chunks and bring it into the right order at the > receiver. As long as your DTN assures delivery without lost bundles, this > should work. In case you are not interested in the right order, you can > simply use dtnstream as sender and dtnrecv as receiver. The additional data > for the streaming and reordering is stored in an extension block of the > bundle and not within the payload. So it is possible to just receive the > payload of the stream by calling dtnrecv. > > > > If you just looking for a timeout mechanism to skip lost bundles after a > timeout, you can just set the parameter “-t” of dtnstream. > > > > To modify the behavior, you need to adapt the class BundleStreamBuf [1] > within the tools package. The method __underflow(), checks if the next > sequence number is available and blocks until this is available or a > predefined timeout is reached [2]. > > > > Kind regards, > > Johannes > > > > [1] > https://github.com/ibrdtn/ibrdtn/blob/master/ibrdtn/tools/src/streaming/Bun… > > [2] > https://github.com/ibrdtn/ibrdtn/blob/master/ibrdtn/tools/src/streaming/Bun… > > > > > > *Von:* Ibr-dtn <ibr-dtn-bounces(a)ibr.cs.tu-bs.de> *Im Auftrag von *João > Pedro Loureiro via Ibr-dtn > *Gesendet:* Freitag, 18. Dezember 2020 13:53 > *An:* ibr-dtn(a)ibr.cs.tu-bs.de > *Betreff:* [ibr-dtn] dtnstream: Lost Bundles > > > > Hello! > > > > My name is João Loureiro and I'm a MSc student at University of Porto > (Portugal) & INESC-TEC (a research institute). > > > > In my master thesis, I'm performing some tests using the IBR-DTN tool > "dtnstream" and 3 nodes, where the first node (sender) only reaches the > third (final destination) through the "middle" node. > > > > The problem I'm facing is the following: I want the destination (where the > video/audio stream is being reproduced and piped into VLC player) to > ignore lost bundles/chunks, i.e., If I receive at this node, for example, > the chunks with the seq. nrs. 0,1 and 3, I want to have a continuous video > streaming, ignoring the packet with seq. nr. 2, and passing from 1 to 3 > instantaneously or with a specified timeout. > > > > I've read the documentation and this paper: > https://doi.org/10.1145/2030652.2030673, but, in my understanding, and > following the dozens of tests I've already performed, currently dtnstream > keeps waiting for the right sequence number instead of keep going with the > last received one. I just wanted to confirm that is truly what is happening > and, if it is, if there's some simple tips for modifying the code in order > to obtain this behavior (I have already tried several modifications but > with no success...). > > > > Thanks a lot for your help, in advance! > > João P. T. Loureiro >

1 1

Re: [ibr-dtn] dtnstream: Lost Bundles
by morgenroth＠ibr.cs.tu-bs.de 23 Dec '20

23 Dec '20

Hello João. Your observation is correct. The tool dtnstream is designed to split-up a continuous stream into chunks and bring it into the right order at the receiver. As long as your DTN assures delivery without lost bundles, this should work. In case you are not interested in the right order, you can simply use dtnstream as sender and dtnrecv as receiver. The additional data for the streaming and reordering is stored in an extension block of the bundle and not within the payload. So it is possible to just receive the payload of the stream by calling dtnrecv. If you just looking for a timeout mechanism to skip lost bundles after a timeout, you can just set the parameter “-t” of dtnstream. To modify the behavior, you need to adapt the class BundleStreamBuf [1] within the tools package. The method __underflow(), checks if the next sequence number is available and blocks until this is available or a predefined timeout is reached [2]. Kind regards, Johannes [1] https://github.com/ibrdtn/ibrdtn/blob/master/ibrdtn/tools/src/streaming/Bun… [2] https://github.com/ibrdtn/ibrdtn/blob/master/ibrdtn/tools/src/streaming/Bun… Von: Ibr-dtn <ibr-dtn-bounces(a)ibr.cs.tu-bs.de> Im Auftrag von João Pedro Loureiro via Ibr-dtn Gesendet: Freitag, 18. Dezember 2020 13:53 An: ibr-dtn(a)ibr.cs.tu-bs.de Betreff: [ibr-dtn] dtnstream: Lost Bundles Hello! My name is João Loureiro and I'm a MSc student at University of Porto (Portugal) & INESC-TEC (a research institute). In my master thesis, I'm performing some tests using the IBR-DTN tool "dtnstream" and 3 nodes, where the first node (sender) only reaches the third (final destination) through the "middle" node. The problem I'm facing is the following: I want the destination (where the video/audio stream is being reproduced and piped into VLC player) to ignore lost bundles/chunks, i.e., If I receive at this node, for example, the chunks with the seq. nrs. 0,1 and 3, I want to have a continuous video streaming, ignoring the packet with seq. nr. 2, and passing from 1 to 3 instantaneously or with a specified timeout. I've read the documentation and this paper: https://doi.org/10.1145/2030652.2030673, but, in my understanding, and following the dozens of tests I've already performed, currently dtnstream keeps waiting for the right sequence number instead of keep going with the last received one. I just wanted to confirm that is truly what is happening and, if it is, if there's some simple tips for modifying the code in order to obtain this behavior (I have already tried several modifications but with no success...). Thanks a lot for your help, in advance! João P. T. Loureiro

1 0

dtnstream: Lost Bundles
by João Pedro Loureiro 18 Dec '20

18 Dec '20

Hello! My name is João Loureiro and I'm a MSc student at University of Porto (Portugal) & INESC-TEC (a research institute). In my master thesis, I'm performing some tests using the IBR-DTN tool "dtnstream" and 3 nodes, where the first node (sender) only reaches the third (final destination) through the "middle" node. The problem I'm facing is the following: I want the destination (where the video/audio stream is being reproduced and piped into VLC player) to ignore lost bundles/chunks, i.e., If I receive at this node, for example, the chunks with the seq. nrs. 0,1 and 3, I want to have a continuous video streaming, ignoring the packet with seq. nr. 2, and passing from 1 to 3 instantaneously or with a specified timeout. I've read the documentation and this paper: https://doi.org/10.1145/2030652.2030673, but, in my understanding, and following the dozens of tests I've already performed, currently dtnstream keeps waiting for the right sequence number instead of keep going with the last received one. I just wanted to confirm that is truly what is happening and, if it is, if there's some simple tips for modifying the code in order to obtain this behavior (I have already tried several modifications but with no success...). Thanks a lot for your help, in advance! João P. T. Loureiro

1 0

Trouble Implementing Store-Carry-Forward
by Kainaat Singh 16 Jan '20

16 Jan '20

Hello, I am trying to implement the following scenario where I have 3 nodes, A, B and C: At time t1 = A and B dtnd daemons are active and C is inactive. A sends a message to C C. So, it forwards the bundle to B. At time t2 = B and C dtnd daemons are active and A is inactive. B forwards the bundle received from A to C. I tried implementing this through dtnsend/dtnrecv. I notice that A does not send message to B even if I configure epidemic routing. DTNSEND from A to C gives an error that TCP connection refused. I have read the documentation but it is still unclear as to how can I implement this. I am attaching the configuration with this email. I have olsrd2_static as the routing agent in the background. Any help would be appreciated! Regards, Kainaat

1 0

bundle Put plain :ERROR 406
by Mehrdad Asadi 20 Dec '19

20 Dec '19

Hello Dears, I am trying to use bundle put plain command in two different machines (with eid registration) to save/send bundle but it gives me following error. however, I have followed api document formats like this: set endpoint xx bundle put plain Source: api:me Destination: dtn://ubuntu/xx1 (it is another machine which i have made regisetration of its endpoint) Blocks: 1 Flags: LAST_BLOCK Length: 4 helloworld *406 PUT FAILED* *whats wrong?*

1 0