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

Re: [ibr-dtn] dtnping crashes ibrdtnd
by Johannes Morgenroth 20 Aug '13

20 Aug '13

Am 20.08.2013 11:06, schrieb ssireskin(a)gmail.com: > Johannes, > > I wanted to test these new scheduling features. Here is what I really > need from priorities. I want bundle priority to be considered by dtnd > on all stages of bundle processing, for example taking bundles out of > storage, placing bundles to a routing queue, sending bundles to a > convergence layer, sending bundles to underlying transport, etc. Is > "scheduling = yes" about this, or it's a completely different feature? In IBR-DTN priorities are only considered within the storage. Bundles are sorted using the priorities and this results in a strict ordered processing in several other modules, including routing and API delivery. As example: If you put in three bundles with priority bulk, expedited and normal. The expedited bundles will be processed and forwarded first to other nodes. The order in which the bundles are stored does not matter here. The mechanism enabled by "scheduling = yes" activates advanced scheduling, which allow +/- 128 priority levels. These are not encoded in the bundle primary block. Instead an extension block is necessary to define the priority of each bundle. This mechanism behaves like the basic priorities and just change the ordering of bundles in the storage. > With dtn2 i have seen the following scenario. I have two nodes, link > between them is down. I send in a series, without delay 30 bulk, then > 2 normal, than 2 expedited bundles. Then immediately I repeat this > series two times. Then I turn link up and see what sequence of bundles > i get on the receiving node. The sequence is: 8 bulk (b), 1 normal > (n), 9b, 1n, 8b, 1e, 1b, 1e, 26b, 1n, 1b, 1n, 1b, 1e, 1b, 1e, 27b, 1e, > 4b, 2n, 1e. This looks line priorities practically don't work. I > tested with TCP-CL, 10 KByte bundle payload size, 16Kbit/s link. To mention here is, that the ordering using priorities in IBR-DTN is not strict to the RFC 5050, but the one you noticed in DTN2 might be. The detail is that RFC 5050 only defines priorities within the same destination. If the bundles are addressed to different destinations, then the priorities should not have any effect on the forwarding order. In IBR-DTN, the priorities are considered globally and even if the bundle is addresses to a different destination, the expedited bundle will get forward before the bulk bundles. Maybe that puts some light into the observations you made. Kind regards, Johannes Morgenroth

1 0

[update] compiling ibr-dtn on windows via cygwin
by Tom Sparks 20 Aug '13

20 Aug '13

I decided not to contact the cygwin mailing list I stop trying to work out why it was not compiling under cygwin I tried to short-cut the compiling step by using colinux/andlinux but they don't have a 64bit version :( I am currently using virtualbox with a Debian guest here is a incomplete to change list for ibr-dtn to compile under cygwin " cygwin ibr-dtn: ibrcommon: ./ibrcommon/config.in keep #undef HAVE_FEATURES_H ./ibrcommon/link/PosixLinkManager.cpp remove #include <netinet/ip6.h> .ibrcommon/thread/Semaphore.h change #include <sys/semaphore.h> to #include </usr/include/semaphore.h> ./ibrcommon/ssl/* todo " --- tom_a_sparks "It's a nerdy thing I like to do" Child of the Internet born 1983 PGP ID: A7EF6006 Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html Ubuntu wiki page https://wiki.ubuntu.com/tomsparks

1 0

Re: [ibr-dtn] dtnping crashes ibrdtnd
by Johannes Morgenroth 20 Aug '13

20 Aug '13

Hi again, thank you for the trace. Indeed, it is very helpful! The issue seems to be related to the scheduling approach enabled with "scheduling = yes". That feature is quite experimental and honestly not well-tested. Are you sure you need it? Basic scheduling via priorities according to RFC5050 is always present and considered in IBR-DTN. The scheduling options allows to consider extended scheduling blocks, which are injected in each bundle and provides more priority levels than specified in the RFC 5050. To be completely sure that the issue is related to the scheduling, could you repeat the experiment without the "scheduling = yes" option in your configuration files? Kind regards, Johannes Morgenroth Am 20.08.2013 10:21, schrieb ssireskin(a)gmail.com: > Johannes, > > I have problems installing debuginfo for standard libraries such as > glibc, libgcc, etc. If the attached gdb.txt is not ok, I'll try to > install debuginfo again and re-do dbg. Please let me know if this > dbg.txt is ok.

1 0

dtnping crashes ibrdtnd
by ssireskin＠gmail.com 20 Aug '13

20 Aug '13

Hi, I have set up several ibr-dtn nodes with multiple interconnections, without discovery and with static routing. I have defined all possible routes in ibrdnd config files to test path fail-over. When I start dtnping, dtnd crashes after several successful pings. Then ping continues via an alternative route, until the other intermediate node crashes. Sometimes the end node, which is being pinged, crashes first. I have attached a network diagram, ibrdtnd config files and logs. I was pinging node 226 from node 224. The route was 224 -> 225 -> 226. The node 226 has crashed. The route changed to 224 -> 227 -> 226. The node 227 has crashed. Please, advise, what could be done to fix this issue. -- Best regards, Sergey Sireskin

2 1

Re: [ibr-dtn] Ibr-dtn Digest, Vol 37, Issue 5
by Bruno Tavares 15 Aug '13

15 Aug '13

Yes , thank you Bruno Tavares ________________________________________ De: ibr-dtn-bounces(a)ibr.cs.tu-bs.de [ibr-dtn-bounces(a)ibr.cs.tu-bs.de] em nome de ibr-dtn-request(a)ibr.cs.tu-bs.de [ibr-dtn-request(a)ibr.cs.tu-bs.de] Enviado: quinta-feira, 15 de Agosto de 2013 11:00 Para: ibr-dtn(a)ibr.cs.tu-bs.de Assunto: Ibr-dtn Digest, Vol 37, Issue 5 Send Ibr-dtn mailing list submissions to ibr-dtn(a)ibr.cs.tu-bs.de To subscribe or unsubscribe via the World Wide Web, visit https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn or, via email, send a message with subject or body 'help' to ibr-dtn-request(a)ibr.cs.tu-bs.de You can reach the person managing the list at ibr-dtn-owner(a)ibr.cs.tu-bs.de When replying, please edit your Subject line so it is more specific than "Re: Contents of Ibr-dtn digest..." Today's Topics: 1. Re: transfer of bundles (Johannes Morgenroth) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Aug 2013 09:55:39 +0200 From: Johannes Morgenroth <morgenroth(a)ibr.cs.tu-bs.de> Subject: Re: [ibr-dtn] transfer of bundles To: ibr-dtn(a)ibr.cs.tu-bs.de Message-ID: <520C897B.104(a)ibr.cs.tu-bs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello Bruno, the channel between two nodes are exclusive and only one bundle can transmitted at once. Answers that your question? Kind regards, Johannes Morgenroth Am 31.07.2013 11:20, schrieb Bruno Tavares: > Hello > > In order to analyze the results of some experiences I made, I need to know if two bundles are sent at the same time in one node. > > Let's say that the scenario has three nodes. The middle node receives a fragment from the first and starts to send it for the last node. In the meanwhile the first node sends a second fragment to the middle one while he is still sending the first one to the last node. What happen? Are the two fragments sent at the same time or the last fragment is only sent to the last node when the transfer of first fragment to the last node is finished ? > > Thank you > > Best regards > > Bruno Tavares ------------------------------ -- !! 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://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn. End of Ibr-dtn Digest, Vol 37, Issue 5 **************************************

1 0

transfer of bundles
by Bruno Tavares 15 Aug '13

15 Aug '13

Hello In order to analyze the results of some experiences I made, I need to know if two bundles are sent at the same time in one node. Let's say that the scenario has three nodes. The middle node receives a fragment from the first and starts to send it for the last node. In the meanwhile the first node sends a second fragment to the middle one while he is still sending the first one to the last node. What happen? Are the two fragments sent at the same time or the last fragment is only sent to the last node when the transfer of first fragment to the last node is finished ? Thank you Best regards Bruno Tavares

2 1

Fwd: DTN Issue (attachment)
by Francisco Cuesta 13 Aug '13

13 Aug '13

Hello, I'm facing some issue with ibrdtn, the main scenario is described in the picture attached. The point is that both computers have ibrdtn installed, and with the same configuration. On certain time, ibrdtn node A cannot see node B, just mention that node A is a raspberry pi wroking with ibrdtn packages. Thanks in advance, regards!

2 1

Re: [ibr-dtn] compiling ibr-dtn on windows via cygwin
by Tom Sparks 13 Aug '13

13 Aug '13

>Date: Mon, 12 Aug 2013 17:31:41 +0200 >From: Johannes Morgenroth <morgenroth(a)ibr.cs.tu-bs.de> >Subject: Re: [ibr-dtn] compiling ibr-dtn on windows via >cygwin >To: ibr-dtn(a)ibr.cs.tu-bs.de >Message-ID: <5208FFDD.4040000(a)ibr.cs.tu-bs.de> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Hello Tom, >Windows is not our target platform and since Windows is not >POSIX compatible you can not compile it directly for it. > However, >the challenges to master should not be very complicated, but >since we are >doing research we do not have the man power to investigate >the compilation process for win32. that's understandable >The issue with "basename()" you have found might be only a >specific missing include. >Did you already asked google for that issue? i am asking on cygwin mailing list to see if there is configuration issue >Kind regards, >Johannes

1 0

compiling ibr-dtn on windows via cygwin
by Tom Sparks 12 Aug '13

12 Aug '13

I am attempting to compile ibr-dtn 0.10.0 on windows via cyqwin and it stops with " File.cpp: In member function 'std::string ibrcommon::File::getBasename() const': File.cpp:174:44: error: 'basename' was not declared in this scope return std::string(basename(_path.c_str())); ^ Makefile:420: recipe for target `File.lo' failed " ./config and make output bellow -----cut-here------- configure: WARNING: unrecognized options: --with-curl, --with-sqlite, --with-dtnsec, --with-compression, --with-tls configure: WARNING: Libtool does not cope well with whitespace in `pwd` checking build system type... x86_64-unknown-cygwin checking host system type... x86_64-unknown-cygwin checking how to print strings... printf checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/x86_64-pc-cygwin/bin/ld.exe checking if the linker (/usr/x86_64-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-cygwin file names to x86_64-unknown-cygwin format... func_convert_file_noop checking how to convert x86_64-unknown-cygwin file names to toolchain format... func_convert_file_noop checking for /usr/x86_64-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_implib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking for gawk... gawk checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for cppunit-config... /usr/bin/cppunit-config checking for Cppunit - version >= 1.9.6... 1.12.1 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/x86_64-pc-cygwin/bin/ld.exe checking if the linker (/usr/x86_64-pc-cygwin/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking dependency style of g++... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether build environment is sane... yes checking whether time.h and sys/time.h may both be included... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for alarm... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for clock_gettime in -lrt... yes checking for bzero... yes checking for clock_gettime... yes checking for gethostname... yes checking for gettimeofday... yes checking for inet_ntoa... yes checking for memset... yes checking for mkdir... yes checking for pow... yes checking for rmdir... yes checking for socket... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/time.h... (cached) yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking features.h usability... yes checking features.h presence... yes checking for features.h... yes checking mach/mach_time.h usability... no checking mach/mach_time.h presence... no checking for mach/mach_time.h... no checking sys/semaphore.h usability... no checking sys/semaphore.h presence... no checking for sys/semaphore.h... no checking semaphore.h usability... yes checking semaphore.h presence... yes checking for semaphore.h... yes checking for sys/semaphore.h... (cached) no checking for inline... inline checking for error_at_line... yes checking for working mktime... yes checking for stdbool.h that conforms to C99... yes checking for _Bool... no checking for int64_t... yes checking for size_t... yes checking for uint16_t... yes checking for uint32_t... yes checking for uint8_t... yes checking for NL... no checking for NL... no checking for pthread_attr_init in -lpthread... yes checking for pthread_create in -lpthread... yes checking for pthread_mutex_init in -lpthread... yes checking for pthread_cond_init in -lpthread... yes checking for pthread_condattr_setclock in -lpthread... yes checking for pthread_setconcurrency in -lpthread... yes checking for pthread_yield in -lpthread... yes checking for pthread_delay in -lpthread... no checking for pthread_delay_np in -lpthread... no checking for pthread_setschedprio in -lpthread... yes checking for OPENSSL... yes configure: WARNING: lowpan extension requested, but no libnl library is found. lowpan support is disabled. configure: creating ./config.status config.status: creating Makefile config.status: creating ibrcommon.pc config.status: creating ibrcommon/Makefile config.status: creating ibrcommon/data/Makefile config.status: creating ibrcommon/link/Makefile config.status: creating ibrcommon/net/Makefile config.status: creating ibrcommon/thread/Makefile config.status: creating ibrcommon/ssl/Makefile config.status: creating ibrcommon/ssl/gcm/Makefile config.status: creating ibrcommon/xml/Makefile config.status: creating tests/Makefile config.status: creating tests/unittests/Makefile config.status: creating tests/stress/Makefile config.status: creating ibrcommon/config.h config.status: executing libtool commands config.status: executing depfiles commands ---cut-here--------- configure: WARNING: unrecognized options: --with-curl, --with-sqlite, --with-dtnsec, --with-compression, --with-tls Making all in ibrcommon make[1]: Entering directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' make all-recursive make[2]: Entering directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' Making all in data make[3]: Entering directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon/data' CXX BLOB.lo CXX ConfigFile.lo CXX File.lo File.cpp: In member function 'std::string ibrcommon::File::getBasename() const': File.cpp:174:44: error: 'basename' was not declared in this scope return std::string(basename(_path.c_str())); ^ Makefile:420: recipe for target `File.lo' failed make[3]: *** [File.lo] Error 1 make[3]: Leaving directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon/data' Makefile:545: recipe for target `all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' Makefile:395: recipe for target `all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' Makefile:422: recipe for target `all-recursive' failed make: *** [all-recursive] Error 1 error while compiling ibrcommon -----cut-here------------ --- tom_a_sparks "It's a nerdy thing I like to do" Child of the Internet born 1983 PGP ID: A7EF6006 Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html Ubuntu wiki page https://wiki.ubuntu.com/tomsparks

2 1