Subject: Re: [dtn-users] dtn on arm
From: Ricardo Martins <[email-masked]>
To: [email-masked]
Date: Thu, 30 Aug 2007 01:54:34 +0100
List-Id: discussion/answers list for users of the dtn reference implementation <dtn-users.mailman.dtnrg.org>

Hi,

This website explains the cause of this problem:
http://www.arm.linux.org.uk/docs/faqs/signedchar.php

Regards,
Ricardo Martins

Michael Demmer wrote:
> No need for a patch -- I committed the fixes. Let me know if I missed
> anything.
> 
> -m
> 
> On Aug 15, 2007, at 7:21 AM, Timur Alperovich wrote:
> 
>> Right, that works :)
>> That was the first solution I was thinking of. Do you want patches for
>> that? It's a minor fix really.
>>
>> Timur
>>
>> On 8/14/07, *Michael Demmer * <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     Can you try changing the "char c" declaration into "int c" and see
>>     if that fixes the problem? getopt is supposed to return an int of
>>     -1 when reaching the end of the option string, so my guess is that
>>     the incompatibility occurs when casting that int to a char.
>>
>>     -m
>>
>>     On Aug 14, 2007, at 1:26 PM, Timur Alperovich wrote:
>>
>>>     Hi,
>>>
>>>     I've been putting dtn on small nodes, gumstix (www.gumstix.com
>>>     <http://www.gumstix.com>). What I noticed is that I could not run
>>>     the dtnsend, dtnrecv commands as well as a few others. The
>>>     commands would simply print out the usage information regardless
>>>     of the arguments and no errors. It turned out in the code for
>>>     these there is an assignment such as "char c = getopt(...);",
>>>     which results in c = 255 when getopt returns -1 on completion on
>>>     the arm7. I found there are two ways to avoid this: 1. use code
>>>     similar to that dtnperf: int c; while((c = getopt(...)) != EOF);
>>>     2. add case 255 in the switch statement that also results in the
>>>     "done" condition. I think the first approach is preferred.
>>>     Anyway, I wanted to point this out for anyone who is doing
>>>     anything similar. I can submit patches for files to change the
>>>     parsing if that would be useful.
>>>
>>>     Timur
>>
>>
> 

From: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 configure problems with BerkeleyDB using distcc
Date: Mon, 20 Aug 2007 00:37:15 +0100
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Hi Mike,

Thanks very much.  configure succeeds now with either method, i.e.  
the exports or the switches to force use of distcc.

I think Macs support distcc.  I've only got one, so there's no point  
me trying, but if you have a few, it may be worth a go.

Cheers,

Darren

On 19 Aug 2007, at 23:05, Michael Demmer wrote:

> Ah sure.... it's because the configure script tries to infer the C+ 
> + compiler to use based on the C compiler settings:
>
>         ac_try_cxx=`echo $ac_with_cc | sed 's/cc/++/'`
>
> I just checked in a change to allow explicit setting of the C++  
> compiler based on the CXX environment variable or the --with-cxx  
> configure option, with a fallback to use the same inferred setting  
> as before if the cxx compiler isn't supplied.
>
> Update and let me know if that works better for you.
>
> -m
>
>
> On Aug 19, 2007, at 1:12 PM, Darren Long wrote:
>
>> On 19 Aug 2007, at 19:41, Michael Demmer wrote:
>>>  --with-cc="distcc arm-linux-gnu-gcc"
>>
>>
>> Hi Mike,
>>
>> I had a go with that, no joy, but got some clues.   I went back to  
>> using the exports, and configure does pick up the CC correctly,  
>> but seems to ignore CXX and tries to make something up for the C++  
>> compiler name - "dist++", at configure:4060.  This seems to be the  
>> reason for the configure problem with BerkeleyDB, as the tests use  
>> the c++ compiler, and fail on the missing binary.
>>
>>
>> Some output from configure.log is below, called with ./configure -- 
>> disable-ecl --disable-edp --with-db=/usr/local/BerkeleyDB.4.5
>>
>> Cheers,
>>
>> Darren
>>
>> ## ----------- ##
>> ## Core tests. ##
>> ## ----------- ##
>>
>> configure:1860: checking location of source directory
>> configure:1863: result: "/home/darren/source/DTN2"
>> configure:1868: checking location of build directory
>> configure:1870: result: "/home/darren/source/DTN2"
>> configure:1972: checking for gcc
>> configure:1999: result: distcc arm-linux-gnu-gcc
>> configure:2237: checking for C compiler version
>> configure:2244: distcc arm-linux-gnu-gcc --version >&5
>> arm-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>> Copyright (C) 2006 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.   
>> There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
>> PURPOSE.
>>
>> configure:2247: $? = 0
>> configure:2254: distcc arm-linux-gnu-gcc -v >&5
>> Using built-in specs.
>> Target: arm-linux-gnu
>> Configured with: ../src/configure -v --enable-languages=c,c+ 
>> +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared -- 
>> with-system-zlib --libexecdir=/usr/lib --without-included-gettext  
>> --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- 
>> __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug -- 
>> enable-mpfr --enable-checking=release arm-linux-gnu
>> Thread model: posix
>> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>> configure:2257: $? = 0
>> configure:2264: distcc arm-linux-gnu-gcc -V >&5
>> arm-linux-gnu-gcc: '-V' option must have argument
>> distcc[26074] ERROR: compile (null) on localhost failed
>> configure:2267: $? = 1
>> configure:2290: checking for C compiler default output file name
>> configure:2317: distcc arm-linux-gnu-gcc    conftest.c  >&5
>> configure:2320: $? = 0
>> configure:2358: result: a.out
>> configure:2375: checking whether the C compiler works
>> configure:2385: ./a.out
>> configure:2388: $? = 0
>> configure:2405: result: yes
>> configure:2412: checking whether we are cross compiling
>> configure:2414: result: no
>> configure:2417: checking for suffix of executables
>> configure:2424: distcc arm-linux-gnu-gcc -o conftest     
>> conftest.c  >&5
>> configure:2427: $? = 0
>> configure:2451: result:
>> configure:2457: checking for suffix of object files
>> configure:2483: distcc arm-linux-gnu-gcc -c   conftest.c >&5
>> configure:2486: $? = 0
>> configure:2509: result: o
>> configure:2513: checking whether we are using the GNU C compiler
>> configure:2542: distcc arm-linux-gnu-gcc -c   conftest.c >&5
>> configure:2548: $? = 0
>> configure:2565: result: yes
>> configure:2570: checking whether distcc arm-linux-gnu-gcc accepts -g
>> configure:2600: distcc arm-linux-gnu-gcc -c -g  conftest.c >&5
>> configure:2606: $? = 0
>> configure:2705: result: yes
>> configure:2722: checking for distcc arm-linux-gnu-gcc option to  
>> accept ISO C89
>> configure:2796: distcc arm-linux-gnu-gcc  -c -g -O2  conftest.c >&5
>> configure:2802: $? = 0
>> configure:2825: result: none needed
>> configure:2907: checking for ar
>> configure:2923: found /usr/bin/ar
>> configure:2934: result: ar
>> configure:3003: checking for ranlib
>> configure:3019: found /usr/bin/ranlib
>> configure:3030: result: ranlib
>> configure:3071: checking whether to compile with debugging
>> configure:3073: result: yes
>> configure:3092: checking whether to compile with memory debugging
>> configure:3094: result: no
>> configure:3113: checking whether to compile with lock debugging  
>> (default yes)
>> configure:3115: result: yes
>> configure:3135: checking whether to compile with optimization
>> configure:3137: result: no
>> configure:3158: checking whether to compile with profiling
>> configure:3160: result: no
>> configure:3178: checking whether to link statically
>> configure:3180: result: no
>> configure:3191: checking whether to link using static external  
>> libraries
>> configure:3193: result: no
>> configure:3205: checking whether to try to build shared libraries
>> configure:3220: result: yes
>> configure:3231: checking whether the compiler supports -fPIC
>> configure:3242: distcc arm-linux-gnu-gcc -c -fPIC -DPIC -g -O2 - 
>> Werror  conftest.c >&5
>> configure:3248: $? = 0
>> configure:3262: result: yes
>> configure:3268: checking whether the compiler can link a dynamic  
>> library with -shared
>> configure:3280: distcc arm-linux-gnu-gcc -o conftest -fPIC -DPIC - 
>> g -O2 -Werror  -shared  conftest.c  >&5
>> configure:3286: $? = 0
>> configure:3302: result: yes
>> configure:3310: checking extension for dynamic libraries
>> configure:3322: result: so
>> configure:3325: checking if the compiler supports -Wl,--rpath=.
>> configure:3337: distcc arm-linux-gnu-gcc -o conftest -fPIC -DPIC - 
>> g -O2 -Werror  -shared  -Wl,-rpath=/foo conftest.c  >&5
>> configure:3343: $? = 0
>> configure:3359: result: yes
>> configure:3413: checking for grep that handles long lines and -e
>> configure:3487: result: /bin/grep
>> configure:3492: checking for egrep
>> configure:3570: result: /bin/grep -E
>> configure:3576: checking for a C compiler (trying distcc arm-linux- 
>> gnu-gcc)
>> configure:3578: result:
>> configure:3697: checking for C compiler version
>> configure:3704: distcc arm-linux-gnu-gcc --version >&5
>> arm-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>> Copyright (C) 2006 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.   
>> There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
>> PURPOSE.
>>
>> configure:3707: $? = 0
>> configure:3714: distcc arm-linux-gnu-gcc -v >&5
>> Using built-in specs.
>> Target: arm-linux-gnu
>> Configured with: ../src/configure -v --enable-languages=c,c+ 
>> +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared -- 
>> with-system-zlib --libexecdir=/usr/lib --without-included-gettext  
>> --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- 
>> __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug -- 
>> enable-mpfr --enable-checking=release arm-linux-gnu
>> Thread model: posix
>> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>> configure:3717: $? = 0
>> configure:3724: distcc arm-linux-gnu-gcc -V >&5
>> arm-linux-gnu-gcc: '-V' option must have argument
>> distcc[26235] ERROR: compile (null) on localhost failed
>> configure:3727: $? = 1
>> configure:3730: checking whether we are using the GNU C compiler
>> configure:3782: result: yes
>> configure:3787: checking whether distcc arm-linux-gnu-gcc accepts -g
>> configure:3922: result: yes
>> configure:3939: checking for distcc arm-linux-gnu-gcc option to  
>> accept ISO C89
>> configure:4042: result: none needed
>> configure:4060: checking for a C++ compiler (trying dist++ arm- 
>> linux-gnu-gcc)
>> configure:4062: result:
>> configure:4180: checking for C++ compiler version
>> configure:4187: dist++ arm-linux-gnu-gcc --version >&5
>> ./configure: line 4188: dist++: command not found
>> configure:4190: $? = 127
>> configure:4197: dist++ arm-linux-gnu-gcc -v >&5
>> ./configure: line 4198: dist++: command not found
>> configure:4200: $? = 127
>> configure:4207: dist++ arm-linux-gnu-gcc -V >&5
>> ./configure: line 4208: dist++: command not found
>> configure:4210: $? = 127
>> configure:4213: checking whether we are using the GNU C++ compiler
>> configure:4242: dist++ arm-linux-gnu-gcc -c   conftest.cpp >&5
>> ./configure: line 4243: dist++: command not found
>> configure:4248: $? = 127
>> configure: failed program was:
>> | /* confdefs.h.  */
>> | #define PACKAGE_NAME ""
>> | #define PACKAGE_TARNAME ""
>> | #define PACKAGE_VERSION ""
>> | #define PACKAGE_STRING ""
>> | #define PACKAGE_BUGREPORT ""
>> | #define HAVE_CONFIG_STATE 1
>> | #define INSTALL_SYSCONFDIR "/etc"
>> | #define INSTALL_LOCALSTATEDIR "/var"
>> | #define OASYS_DEBUG_LOCKING_ENABLED 1
>> | /* end confdefs.h.  */
>> |
>> | int
>> | main ()
>> | {
>> | #ifndef __GNUC__
>> |        choke me
>> | #endif
>> |
>> |   ;
>> |   return 0;
>> | }
>> configure:4265: result: no
>> configure:4270: checking whether dist++ arm-linux-gnu-gcc accepts -g
>> configure:4300: dist++ arm-linux-gnu-gcc -c -g  conftest.cpp >&5
>> ./configure: line 4301: dist++: command not found
>> configure:4306: $? = 127
>> configure: failed program was:
>> | /* confdefs.h.  */
>>
>>
>>
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] DTN2 configure problems with BerkeleyDB using distcc
Date: Sun, 19 Aug 2007 15:05:58 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Ah sure.... it's because the configure script tries to infer the C++  
compiler to use based on the C compiler settings:

         ac_try_cxx=`echo $ac_with_cc | sed 's/cc/++/'`

I just checked in a change to allow explicit setting of the C++  
compiler based on the CXX environment variable or the --with-cxx  
configure option, with a fallback to use the same inferred setting as  
before if the cxx compiler isn't supplied.

Update and let me know if that works better for you.

-m

On Aug 19, 2007, at 1:12 PM, Darren Long wrote:

> On 19 Aug 2007, at 19:41, Michael Demmer wrote:
>>  --with-cc="distcc arm-linux-gnu-gcc"
>
>
> Hi Mike,
>
> I had a go with that, no joy, but got some clues.   I went back to  
> using the exports, and configure does pick up the CC correctly, but  
> seems to ignore CXX and tries to make something up for the C++  
> compiler name - "dist++", at configure:4060.  This seems to be the  
> reason for the configure problem with BerkeleyDB, as the tests use  
> the c++ compiler, and fail on the missing binary.
>
>
> Some output from configure.log is below, called with ./configure -- 
> disable-ecl --disable-edp --with-db=/usr/local/BerkeleyDB.4.5
>
> Cheers,
>
> Darren
>
> ## ----------- ##
> ## Core tests. ##
> ## ----------- ##
>
> configure:1860: checking location of source directory
> configure:1863: result: "/home/darren/source/DTN2"
> configure:1868: checking location of build directory
> configure:1870: result: "/home/darren/source/DTN2"
> configure:1972: checking for gcc
> configure:1999: result: distcc arm-linux-gnu-gcc
> configure:2237: checking for C compiler version
> configure:2244: distcc arm-linux-gnu-gcc --version >&5
> arm-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.   
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
> PURPOSE.
>
> configure:2247: $? = 0
> configure:2254: distcc arm-linux-gnu-gcc -v >&5
> Using built-in specs.
> Target: arm-linux-gnu
> Configured with: ../src/configure -v --enable-languages=c,c+ 
> +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared -- 
> with-system-zlib --libexecdir=/usr/lib --without-included-gettext -- 
> enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- 
> __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- 
> mpfr --enable-checking=release arm-linux-gnu
> Thread model: posix
> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> configure:2257: $? = 0
> configure:2264: distcc arm-linux-gnu-gcc -V >&5
> arm-linux-gnu-gcc: '-V' option must have argument
> distcc[26074] ERROR: compile (null) on localhost failed
> configure:2267: $? = 1
> configure:2290: checking for C compiler default output file name
> configure:2317: distcc arm-linux-gnu-gcc    conftest.c  >&5
> configure:2320: $? = 0
> configure:2358: result: a.out
> configure:2375: checking whether the C compiler works
> configure:2385: ./a.out
> configure:2388: $? = 0
> configure:2405: result: yes
> configure:2412: checking whether we are cross compiling
> configure:2414: result: no
> configure:2417: checking for suffix of executables
> configure:2424: distcc arm-linux-gnu-gcc -o conftest    conftest.c   
> >&5
> configure:2427: $? = 0
> configure:2451: result:
> configure:2457: checking for suffix of object files
> configure:2483: distcc arm-linux-gnu-gcc -c   conftest.c >&5
> configure:2486: $? = 0
> configure:2509: result: o
> configure:2513: checking whether we are using the GNU C compiler
> configure:2542: distcc arm-linux-gnu-gcc -c   conftest.c >&5
> configure:2548: $? = 0
> configure:2565: result: yes
> configure:2570: checking whether distcc arm-linux-gnu-gcc accepts -g
> configure:2600: distcc arm-linux-gnu-gcc -c -g  conftest.c >&5
> configure:2606: $? = 0
> configure:2705: result: yes
> configure:2722: checking for distcc arm-linux-gnu-gcc option to  
> accept ISO C89
> configure:2796: distcc arm-linux-gnu-gcc  -c -g -O2  conftest.c >&5
> configure:2802: $? = 0
> configure:2825: result: none needed
> configure:2907: checking for ar
> configure:2923: found /usr/bin/ar
> configure:2934: result: ar
> configure:3003: checking for ranlib
> configure:3019: found /usr/bin/ranlib
> configure:3030: result: ranlib
> configure:3071: checking whether to compile with debugging
> configure:3073: result: yes
> configure:3092: checking whether to compile with memory debugging
> configure:3094: result: no
> configure:3113: checking whether to compile with lock debugging  
> (default yes)
> configure:3115: result: yes
> configure:3135: checking whether to compile with optimization
> configure:3137: result: no
> configure:3158: checking whether to compile with profiling
> configure:3160: result: no
> configure:3178: checking whether to link statically
> configure:3180: result: no
> configure:3191: checking whether to link using static external  
> libraries
> configure:3193: result: no
> configure:3205: checking whether to try to build shared libraries
> configure:3220: result: yes
> configure:3231: checking whether the compiler supports -fPIC
> configure:3242: distcc arm-linux-gnu-gcc -c -fPIC -DPIC -g -O2 - 
> Werror  conftest.c >&5
> configure:3248: $? = 0
> configure:3262: result: yes
> configure:3268: checking whether the compiler can link a dynamic  
> library with -shared
> configure:3280: distcc arm-linux-gnu-gcc -o conftest -fPIC -DPIC -g  
> -O2 -Werror  -shared  conftest.c  >&5
> configure:3286: $? = 0
> configure:3302: result: yes
> configure:3310: checking extension for dynamic libraries
> configure:3322: result: so
> configure:3325: checking if the compiler supports -Wl,--rpath=.
> configure:3337: distcc arm-linux-gnu-gcc -o conftest -fPIC -DPIC -g  
> -O2 -Werror  -shared  -Wl,-rpath=/foo conftest.c  >&5
> configure:3343: $? = 0
> configure:3359: result: yes
> configure:3413: checking for grep that handles long lines and -e
> configure:3487: result: /bin/grep
> configure:3492: checking for egrep
> configure:3570: result: /bin/grep -E
> configure:3576: checking for a C compiler (trying distcc arm-linux- 
> gnu-gcc)
> configure:3578: result:
> configure:3697: checking for C compiler version
> configure:3704: distcc arm-linux-gnu-gcc --version >&5
> arm-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.   
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
> PURPOSE.
>
> configure:3707: $? = 0
> configure:3714: distcc arm-linux-gnu-gcc -v >&5
> Using built-in specs.
> Target: arm-linux-gnu
> Configured with: ../src/configure -v --enable-languages=c,c+ 
> +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared -- 
> with-system-zlib --libexecdir=/usr/lib --without-included-gettext -- 
> enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- 
> __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- 
> mpfr --enable-checking=release arm-linux-gnu
> Thread model: posix
> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> configure:3717: $? = 0
> configure:3724: distcc arm-linux-gnu-gcc -V >&5
> arm-linux-gnu-gcc: '-V' option must have argument
> distcc[26235] ERROR: compile (null) on localhost failed
> configure:3727: $? = 1
> configure:3730: checking whether we are using the GNU C compiler
> configure:3782: result: yes
> configure:3787: checking whether distcc arm-linux-gnu-gcc accepts -g
> configure:3922: result: yes
> configure:3939: checking for distcc arm-linux-gnu-gcc option to  
> accept ISO C89
> configure:4042: result: none needed
> configure:4060: checking for a C++ compiler (trying dist++ arm- 
> linux-gnu-gcc)
> configure:4062: result:
> configure:4180: checking for C++ compiler version
> configure:4187: dist++ arm-linux-gnu-gcc --version >&5
> ./configure: line 4188: dist++: command not found
> configure:4190: $? = 127
> configure:4197: dist++ arm-linux-gnu-gcc -v >&5
> ./configure: line 4198: dist++: command not found
> configure:4200: $? = 127
> configure:4207: dist++ arm-linux-gnu-gcc -V >&5
> ./configure: line 4208: dist++: command not found
> configure:4210: $? = 127
> configure:4213: checking whether we are using the GNU C++ compiler
> configure:4242: dist++ arm-linux-gnu-gcc -c   conftest.cpp >&5
> ./configure: line 4243: dist++: command not found
> configure:4248: $? = 127
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define HAVE_CONFIG_STATE 1
> | #define INSTALL_SYSCONFDIR "/etc"
> | #define INSTALL_LOCALSTATEDIR "/var"
> | #define OASYS_DEBUG_LOCKING_ENABLED 1
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> | #ifndef __GNUC__
> |        choke me
> | #endif
> |
> |   ;
> |   return 0;
> | }
> configure:4265: result: no
> configure:4270: checking whether dist++ arm-linux-gnu-gcc accepts -g
> configure:4300: dist++ arm-linux-gnu-gcc -c -g  conftest.cpp >&5
> ./configure: line 4301: dist++: command not found
> configure:4306: $? = 127
> configure: failed program was:
> | /* confdefs.h.  */
>
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

From: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 configure problems with BerkeleyDB using distcc
Date: Sun, 19 Aug 2007 21:12:49 +0100
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

On 19 Aug 2007, at 19:41, Michael Demmer wrote:
>  --with-cc="distcc arm-linux-gnu-gcc"

Hi Mike,

I had a go with that, no joy, but got some clues.   I went back to  
using the exports, and configure does pick up the CC correctly, but  
seems to ignore CXX and tries to make something up for the C++  
compiler name - "dist++", at configure:4060.  This seems to be the  
reason for the configure problem with BerkeleyDB, as the tests use  
the c++ compiler, and fail on the missing binary.

Some output from configure.log is below, called with ./configure -- 
disable-ecl --disable-edp --with-db=/usr/local/BerkeleyDB.4.5

Cheers,

Darren

## ----------- ##
## Core tests. ##
## ----------- ##

configure:1860: checking location of source directory
configure:1863: result: "/home/darren/source/DTN2"
configure:1868: checking location of build directory
configure:1870: result: "/home/darren/source/DTN2"
configure:1972: checking for gcc
configure:1999: result: distcc arm-linux-gnu-gcc
configure:2237: checking for C compiler version
configure:2244: distcc arm-linux-gnu-gcc --version >&5
arm-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

configure:2247: $? = 0
configure:2254: distcc arm-linux-gnu-gcc -v >&5
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c+ 
+,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- 
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- 
threads=posix --enable-nls --program-suffix=-4.1 --enable- 
__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- 
mpfr --enable-checking=release arm-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
configure:2257: $? = 0
configure:2264: distcc arm-linux-gnu-gcc -V >&5
arm-linux-gnu-gcc: '-V' option must have argument
distcc[26074] ERROR: compile (null) on localhost failed
configure:2267: $? = 1
configure:2290: checking for C compiler default output file name
configure:2317: distcc arm-linux-gnu-gcc    conftest.c  >&5
configure:2320: $? = 0
configure:2358: result: a.out
configure:2375: checking whether the C compiler works
configure:2385: ./a.out
configure:2388: $? = 0
configure:2405: result: yes
configure:2412: checking whether we are cross compiling
configure:2414: result: no
configure:2417: checking for suffix of executables
configure:2424: distcc arm-linux-gnu-gcc -o conftest    conftest.c  >&5
configure:2427: $? = 0
configure:2451: result:
configure:2457: checking for suffix of object files
configure:2483: distcc arm-linux-gnu-gcc -c   conftest.c >&5
configure:2486: $? = 0
configure:2509: result: o
configure:2513: checking whether we are using the GNU C compiler
configure:2542: distcc arm-linux-gnu-gcc -c   conftest.c >&5
configure:2548: $? = 0
configure:2565: result: yes
configure:2570: checking whether distcc arm-linux-gnu-gcc accepts -g
configure:2600: distcc arm-linux-gnu-gcc -c -g  conftest.c >&5
configure:2606: $? = 0
configure:2705: result: yes
configure:2722: checking for distcc arm-linux-gnu-gcc option to  
accept ISO C89
configure:2796: distcc arm-linux-gnu-gcc  -c -g -O2  conftest.c >&5
configure:2802: $? = 0
configure:2825: result: none needed
configure:2907: checking for ar
configure:2923: found /usr/bin/ar
configure:2934: result: ar
configure:3003: checking for ranlib
configure:3019: found /usr/bin/ranlib
configure:3030: result: ranlib
configure:3071: checking whether to compile with debugging
configure:3073: result: yes
configure:3092: checking whether to compile with memory debugging
configure:3094: result: no
configure:3113: checking whether to compile with lock debugging  
(default yes)
configure:3115: result: yes
configure:3135: checking whether to compile with optimization
configure:3137: result: no
configure:3158: checking whether to compile with profiling
configure:3160: result: no
configure:3178: checking whether to link statically
configure:3180: result: no
configure:3191: checking whether to link using static external libraries
configure:3193: result: no
configure:3205: checking whether to try to build shared libraries
configure:3220: result: yes
configure:3231: checking whether the compiler supports -fPIC
configure:3242: distcc arm-linux-gnu-gcc -c -fPIC -DPIC -g -O2 - 
Werror  conftest.c >&5
configure:3248: $? = 0
configure:3262: result: yes
configure:3268: checking whether the compiler can link a dynamic  
library with -shared
configure:3280: distcc arm-linux-gnu-gcc -o conftest -fPIC -DPIC -g - 
O2 -Werror  -shared  conftest.c  >&5
configure:3286: $? = 0
configure:3302: result: yes
configure:3310: checking extension for dynamic libraries
configure:3322: result: so
configure:3325: checking if the compiler supports -Wl,--rpath=.
configure:3337: distcc arm-linux-gnu-gcc -o conftest -fPIC -DPIC -g - 
O2 -Werror  -shared  -Wl,-rpath=/foo conftest.c  >&5
configure:3343: $? = 0
configure:3359: result: yes
configure:3413: checking for grep that handles long lines and -e
configure:3487: result: /bin/grep
configure:3492: checking for egrep
configure:3570: result: /bin/grep -E
configure:3576: checking for a C compiler (trying distcc arm-linux- 
gnu-gcc)
configure:3578: result:
configure:3697: checking for C compiler version
configure:3704: distcc arm-linux-gnu-gcc --version >&5
arm-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

configure:3707: $? = 0
configure:3714: distcc arm-linux-gnu-gcc -v >&5
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c+ 
+,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- 
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- 
threads=posix --enable-nls --program-suffix=-4.1 --enable- 
__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- 
mpfr --enable-checking=release arm-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
configure:3717: $? = 0
configure:3724: distcc arm-linux-gnu-gcc -V >&5
arm-linux-gnu-gcc: '-V' option must have argument
distcc[26235] ERROR: compile (null) on localhost failed
configure:3727: $? = 1
configure:3730: checking whether we are using the GNU C compiler
configure:3782: result: yes
configure:3787: checking whether distcc arm-linux-gnu-gcc accepts -g
configure:3922: result: yes
configure:3939: checking for distcc arm-linux-gnu-gcc option to  
accept ISO C89
configure:4042: result: none needed
configure:4060: checking for a C++ compiler (trying dist++ arm-linux- 
gnu-gcc)
configure:4062: result:
configure:4180: checking for C++ compiler version
configure:4187: dist++ arm-linux-gnu-gcc --version >&5
./configure: line 4188: dist++: command not found
configure:4190: $? = 127
configure:4197: dist++ arm-linux-gnu-gcc -v >&5
./configure: line 4198: dist++: command not found
configure:4200: $? = 127
configure:4207: dist++ arm-linux-gnu-gcc -V >&5
./configure: line 4208: dist++: command not found
configure:4210: $? = 127
configure:4213: checking whether we are using the GNU C++ compiler
configure:4242: dist++ arm-linux-gnu-gcc -c   conftest.cpp >&5
./configure: line 4243: dist++: command not found
configure:4248: $? = 127
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define HAVE_CONFIG_STATE 1
| #define INSTALL_SYSCONFDIR "/etc"
| #define INSTALL_LOCALSTATEDIR "/var"
| #define OASYS_DEBUG_LOCKING_ENABLED 1
| /* end confdefs.h.  */
|
| int
| main ()
| {
| #ifndef __GNUC__
|        choke me
| #endif
|
|   ;
|   return 0;
| }
configure:4265: result: no
configure:4270: checking whether dist++ arm-linux-gnu-gcc accepts -g
configure:4300: dist++ arm-linux-gnu-gcc -c -g  conftest.cpp >&5
./configure: line 4301: dist++: command not found
configure:4306: $? = 127
configure: failed program was:
| /* confdefs.h.  */

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] DTN2 configure problems with BerkeleyDB using distcc
Date: Sun, 19 Aug 2007 11:41:34 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Try running configure --with-cc="distcc arm-linux-gnu-gcc" and see if  
that works.

I don't think that the DTN2 configure actually respects the CC  
environment variable -- though it probably should to be consistent  
with other configure scripts.

-m

On Aug 19, 2007, at 6:25 AM, Darren Long wrote:

> Hi,
>
> I decided to do something about the horribly slow build times on my  
> NSLU2 (about 12 hours for DTN2), so I got crosstool to build an arm- 
> linux-gnu toolchain and set up distcc so I could farm off cross- 
> compilation to my dual-core Ubuntu box.
>
> I did this following the guide at http://www.mythtv.org/wiki/ 
> index.php/Myth_On_NSLU2
>
> However, when using distcc, I can't get configure to configure DTN2  
> (fresh CVS) properly for BerkeleyDB.  To use distcc, I'm exporting  
> the following before running configure:
>
> export CC="distcc arm-linux-gnu-gcc"
> export CXX="distcc arm-linux-gnu-g++"
> export DISTCC_HOSTS="192.168.0.4"
>
> I even did a fresh source build of BerkeleyDB, using distcc into / 
> usr/local/BerkeleyDB.4.5, so I know configuring and building with  
> distcc works fine.
>
> I've just tried a workaround, where I configure without having  
> exported CC and CXX as distcc, then edited the Rules.make files to  
> switch CC and CXX to point at distcc,  then export as above, and  
> finally make.  This seems to be working and although it's not  
> finished building yet, it seems much faster.
>
> So, in summary, DTN2 configures fine when I'm not using distcc,  
> both with and without the explicit --with-db path, picking up the  
> newly built 4.5 version, but fails to configure if I export CC and  
> CXX as distcc beforehand.
>
> Any ideas what the problem might be?
>
> Cheers,
>
> Darren
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

From: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 configure problems with BerkeleyDB using distcc
Date: Sun, 19 Aug 2007 17:25:54 +0100
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

By the way, using distcc trimmed more than 10 hours off the build  
time :-)

Linking is still like watching paint dry :-(

It would be good to get the distcc configure problem sorted.

Cheers,

Darren

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Sun, 19 Aug 2007 14:25:55 +0100
Subject: [dtn-users] DTN2 configure problems with BerkeleyDB using distcc
Sender: [email-masked]
Reply-To: [email-masked]

Hi,

I decided to do something about the horribly slow build times on my  
NSLU2 (about 12 hours for DTN2), so I got crosstool to build an arm- 
linux-gnu toolchain and set up distcc so I could farm off cross- 
compilation to my dual-core Ubuntu box.

I did this following the guide at http://www.mythtv.org/wiki/ 
index.php/Myth_On_NSLU2

However, when using distcc, I can't get configure to configure DTN2  
(fresh CVS) properly for BerkeleyDB.  To use distcc, I'm exporting  
the following before running configure:

export CC="distcc arm-linux-gnu-gcc"
export CXX="distcc arm-linux-gnu-g++"
export DISTCC_HOSTS="192.168.0.4"

I even did a fresh source build of BerkeleyDB, using distcc into /usr/ 
local/BerkeleyDB.4.5, so I know configuring and building with distcc  
works fine.

I've just tried a workaround, where I configure without having  
exported CC and CXX as distcc, then edited the Rules.make files to  
switch CC and CXX to point at distcc,  then export as above, and  
finally make.  This seems to be working and although it's not  
finished building yet, it seems much faster.

So, in summary, DTN2 configures fine when I'm not using distcc, both  
with and without the explicit --with-db path, picking up the newly  
built 4.5 version, but fails to configure if I export CC and CXX as  
distcc beforehand.

Any ideas what the problem might be?

Cheers,

Darren

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] dtn on arm
Date: Wed, 15 Aug 2007 08:22:38 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

--Apple-Mail-1-578244764
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

No need for a patch -- I committed the fixes. Let me know if I missed  
anything.

-m

On Aug 15, 2007, at 7:21 AM, Timur Alperovich wrote:

> Right, that works :)
> That was the first solution I was thinking of. Do you want patches  
> for that? It's a minor fix really.
>
> Timur
>
> On 8/14/07, Michael Demmer <[email-masked]> wrote:
>
> Can you try changing the "char c" declaration into "int c" and see  
> if that fixes the problem? getopt is supposed to return an int of  
> -1 when reaching the end of the option string, so my guess is that  
> the incompatibility occurs when casting that int to a char.
>
> -m
>
> On Aug 14, 2007, at 1:26 PM, Timur Alperovich wrote:
>
>> Hi,
>>
>> I've been putting dtn on small nodes, gumstix (www.gumstix.com).  
>> What I noticed is that I could not run the dtnsend, dtnrecv  
>> commands as well as a few others. The commands would simply print  
>> out the usage information regardless of the arguments and no  
>> errors. It turned out in the code for these there is an assignment  
>> such as "char c = getopt(...);", which results in c = 255 when  
>> getopt returns -1 on completion on the arm7. I found there are two  
>> ways to avoid this: 1. use code similar to that dtnperf: int c;  
>> while((c = getopt(...)) != EOF); 2. add case 255 in the switch  
>> statement that also results in the "done" condition. I think the  
>> first approach is preferred. Anyway, I wanted to point this out  
>> for anyone who is doing anything similar. I can submit patches for  
>> files to change the parsing if that would be useful.
>>
>> Timur
>
>

--Apple-Mail-1-578244764
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=US-ASCII

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
No need for a patch -- I committed the fixes. Let me know if I missed =
anything.<div><br =
class=3D"webkit-block-placeholder"></div><div>-m</div><div><br><div><div>O=
n Aug 15, 2007, at 7:21 AM, Timur Alperovich wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Right, =
that works :)<br>That was the first solution I was thinking of. Do you =
want patches for that? It's a minor fix =
really.<br><br>Timur<br><br><div><span class=3D"gmail_quote">On 8/14/07, =
<b class=3D"gmail_sendername">Michael Demmer </b> &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-left: 1px =
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;"> <div style=3D""> <div><br></div><div>Can you try changing the =
"char c" declaration into "int c" and see if that fixes the problem? =
getopt is supposed to return an int of -1 when reaching the end of the =
option string, so my guess is that the incompatibility occurs when =
casting that int to a char. </div><span =
class=3D"sg"><div><br></div><div>-m</div></span><div><span class=3D"e" =
id=3D"q_114661adcc3db677_2"><div><br><div><div>On Aug 14, 2007, at 1:26 =
PM, Timur Alperovich wrote:</div><br><blockquote type=3D"cite">Hi,<br><br>=
 I've been putting dtn on small nodes, gumstix (<a =
href=3D"http://www.gumstix.com" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">www.gumstix.com</a>). What I =
noticed is that I could not run the dtnsend, dtnrecv commands as well as =
a few others. The commands would simply print out the usage information =
regardless of the arguments and no errors. It turned out in the code for =
these there is an assignment such as "char c =3D getopt(...);", which =
results in c =3D 255 when getopt returns -1 on completion on the arm7. I =
found there are two ways to avoid this: 1. use code similar to that =
dtnperf: int c; while((c =3D getopt(...)) !=3D EOF); 2. add case 255 in =
the switch statement that also results in the "done" condition. I think =
the first approach is preferred. Anyway, I wanted to point this out for =
anyone who is doing anything similar. I can submit patches for files to =
change the parsing if that would be useful. =
<br><br>Timur<br></blockquote></div><br></div></span></div></div></blockqu=
ote></div><br></blockquote></div><br></div></body></html>=

--Apple-Mail-1-578244764--

Date: Wed, 15 Aug 2007 10:21:20 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtn on arm
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_20334_3968903.1187187680891
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Right, that works :)
That was the first solution I was thinking of. Do you want patches for that?
It's a minor fix really.

Timur

On 8/14/07, Michael Demmer <[email-masked]> wrote:
>
>
> Can you try changing the "char c" declaration into "int c" and see if that
> fixes the problem? getopt is supposed to return an int of -1 when reaching
> the end of the option string, so my guess is that the incompatibility occurs
> when casting that int to a char.
>
> -m
>
> On Aug 14, 2007, at 1:26 PM, Timur Alperovich wrote:
>
> Hi,
>
> I've been putting dtn on small nodes, gumstix (www.gumstix.com). What I
> noticed is that I could not run the dtnsend, dtnrecv commands as well as a
> few others. The commands would simply print out the usage information
> regardless of the arguments and no errors. It turned out in the code for
> these there is an assignment such as "char c = getopt(...);", which results
> in c = 255 when getopt returns -1 on completion on the arm7. I found there
> are two ways to avoid this: 1. use code similar to that dtnperf: int c;
> while((c = getopt(...)) != EOF); 2. add case 255 in the switch statement
> that also results in the "done" condition. I think the first approach is
> preferred. Anyway, I wanted to point this out for anyone who is doing
> anything similar. I can submit patches for files to change the parsing if
> that would be useful.
>
> Timur
>
>
>

------=_Part_20334_3968903.1187187680891
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Right, that works :)<br>That was the first solution I was thinking of. Do you want patches for that? It&#39;s a minor fix really.<br><br>Timur<br><br><div><span class="gmail_quote">On 8/14/07, <b class="gmail_sendername">Michael Demmer
</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">
<div><br></div><div>Can you try changing the &quot;char c&quot; declaration into &quot;int c&quot; and see if that fixes the problem? getopt is supposed to return an int of -1 when reaching the end of the option string, so my guess is that the incompatibility occurs when casting that int to a char.
</div><span class="sg"><div><br></div><div>-m</div></span><div><span class="e" id="q_114661adcc3db677_2"><div><br><div><div>On Aug 14, 2007, at 1:26 PM, Timur Alperovich wrote:</div><br><blockquote type="cite">Hi,<br><br>
I&#39;ve been putting dtn on small nodes, gumstix (<a href="http://www.gumstix.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.gumstix.com</a>). What I noticed is that I could not run the dtnsend, dtnrecv commands as well as a few others. The commands would simply print out the usage information regardless of the arguments and no errors. It turned out in the code for these there is an assignment such as &quot;char c = getopt(...);&quot;, which results in c = 255 when getopt returns -1 on completion on the arm7. I found there are two ways to avoid this: 1. use code similar to that dtnperf: int c; while((c = getopt(...)) != EOF); 2. add case 255 in the switch statement that also results in the &quot;done&quot; condition. I think the first approach is preferred. Anyway, I wanted to point this out for anyone who is doing anything similar. I can submit patches for files to change the parsing if that would be useful. 
<br><br>Timur<br></blockquote></div><br></div></span></div></div></blockquote></div><br>

------=_Part_20334_3968903.1187187680891--

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] dtn on arm
Date: Tue, 14 Aug 2007 13:39:24 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

--Apple-Mail-2-510850283
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Can you try changing the "char c" declaration into "int c" and see if  
that fixes the problem? getopt is supposed to return an int of -1  
when reaching the end of the option string, so my guess is that the  
incompatibility occurs when casting that int to a char.

-m

On Aug 14, 2007, at 1:26 PM, Timur Alperovich wrote:

> Hi,
>
> I've been putting dtn on small nodes, gumstix (www.gumstix.com).  
> What I noticed is that I could not run the dtnsend, dtnrecv  
> commands as well as a few others. The commands would simply print  
> out the usage information regardless of the arguments and no  
> errors. It turned out in the code for these there is an assignment  
> such as "char c = getopt(...);", which results in c = 255 when  
> getopt returns -1 on completion on the arm7. I found there are two  
> ways to avoid this: 1. use code similar to that dtnperf: int c;  
> while((c = getopt(...)) != EOF); 2. add case 255 in the switch  
> statement that also results in the "done" condition. I think the  
> first approach is preferred. Anyway, I wanted to point this out for  
> anyone who is doing anything similar. I can submit patches for  
> files to change the parsing if that would be useful.
>
> Timur

--Apple-Mail-2-510850283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=US-ASCII

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
<div><br class=3D"webkit-block-placeholder"></div><div>Can you try =
changing the "char c" declaration into "int c" and see if that fixes the =
problem? getopt is supposed to return an int of -1 when reaching the end =
of the option string, so my guess is that the incompatibility occurs =
when casting that int to a char.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>-m</div><div><br><div><div>O=
n Aug 14, 2007, at 1:26 PM, Timur Alperovich wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Hi,<br><br>I've been putting dtn on small nodes, gumstix =
(<a href=3D"http://www.gumstix.com">www.gumstix.com</a>). What I noticed =
is that I could not run the dtnsend, dtnrecv commands as well as a few =
others. The commands would simply print out the usage information =
regardless of the arguments and no errors. It turned out in the code for =
these there is an assignment such as "char c =3D getopt(...);", which =
results in c =3D 255 when getopt returns -1 on completion on the arm7. I =
found there are two ways to avoid this: 1. use code similar to that =
dtnperf: int c; while((c =3D getopt(...)) !=3D EOF); 2. add case 255 in =
the switch statement that also results in the "done" condition. I think =
the first approach is preferred. Anyway, I wanted to point this out for =
anyone who is doing anything similar. I can submit patches for files to =
change the parsing if that would be useful. =
<br><br>Timur<br></blockquote></div><br></div></body></html>=

--Apple-Mail-2-510850283--

Date: Tue, 14 Aug 2007 16:26:18 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] dtn on arm
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_18000_14281115.1187123178517
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I've been putting dtn on small nodes, gumstix (www.gumstix.com). What I
noticed is that I could not run the dtnsend, dtnrecv commands as well as a
few others. The commands would simply print out the usage information
regardless of the arguments and no errors. It turned out in the code for
these there is an assignment such as "char c = getopt(...);", which results
in c = 255 when getopt returns -1 on completion on the arm7. I found there
are two ways to avoid this: 1. use code similar to that dtnperf: int c;
while((c = getopt(...)) != EOF); 2. add case 255 in the switch statement
that also results in the "done" condition. I think the first approach is
preferred. Anyway, I wanted to point this out for anyone who is doing
anything similar. I can submit patches for files to change the parsing if
that would be useful.

Timur

------=_Part_18000_14281115.1187123178517
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br><br>I&#39;ve been putting dtn on small nodes, gumstix (<a href="http://www.gumstix.com">www.gumstix.com</a>). What I noticed is that I could not run the dtnsend, dtnrecv commands as well as a few others. The commands would simply print out the usage information regardless of the arguments and no errors. It turned out in the code for these there is an assignment such as &quot;char c = getopt(...);&quot;, which results in c = 255 when getopt returns -1 on completion on the arm7. I found there are two ways to avoid this: 1. use code similar to that dtnperf: int c; while((c = getopt(...)) != EOF); 2. add case 255 in the switch statement that also results in the &quot;done&quot; condition. I think the first approach is preferred. Anyway, I wanted to point this out for anyone who is doing anything similar. I can submit patches for files to change the parsing if that would be useful.
<br><br>Timur<br>

------=_Part_18000_14281115.1187123178517--

Date: Mon, 13 Aug 2007 14:33:56 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] more multi hop issues
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_13740_9975667.1187030036884
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Michael,

Thanks for the help. I think it works now. I was able to send a dtn message
from one node to another over one hop.

Timur

On 8/9/07, Michael Demmer <[email-masked]> wrote:
>
> I just committed a change to the cvs HEAD so the daemon will
> typically by default open opportunistic links that are found by the
> discovery mechanism. let me know if that works better for you.
>
> -m
>
>
> On Aug 9, 2007, at 12:36 PM, Timur Alperovich wrote:
>
> > Hi,
> >
> > I apologize for the stream of questions but I seem to be stuck
> > again. I have discoveries being sent on the multi-homed nodes and
> > nodes appear to detect their neighbors, but there are no routes
> > added for them and no multi-hop neighbors are added. What could be
> > the reason for this? I'm just trying to get a simple multi-hop
> > network to work.
> >
> > Timur
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

------=_Part_13740_9975667.1187030036884
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Michael,<br><br>Thanks for the help. I think it works now. I was able to send a dtn message from one node to another over one hop.<br><br>Timur<br><br><div><span class="gmail_quote">On 8/9/07, <b class="gmail_sendername">Michael Demmer
</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I just committed a change to the cvs HEAD so the daemon will<br>typically by default open opportunistic links that are found by the<br>discovery mechanism. let me know if that works better for you.<br><br>-m<br><br><br>On Aug 9, 2007, at 12:36 PM, Timur Alperovich wrote:
<br><br>&gt; Hi,<br>&gt;<br>&gt; I apologize for the stream of questions but I seem to be stuck<br>&gt; again. I have discoveries being sent on the multi-homed nodes and<br>&gt; nodes appear to detect their neighbors, but there are no routes
<br>&gt; added for them and no multi-hop neighbors are added. What could be<br>&gt; the reason for this? I&#39;m just trying to get a simple multi-hop<br>&gt; network to work.<br>&gt;<br>&gt; Timur<br><br>_______________________________________________
<br>dtn-users mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="http://mailman.dtnrg.org/mailman/listinfo/dtn-users">http://mailman.dtnrg.org/mailman/listinfo/dtn-users
</a><br></blockquote></div><br>

------=_Part_13740_9975667.1187030036884--

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] more multi hop issues
Date: Thu, 9 Aug 2007 17:09:40 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

I just committed a change to the cvs HEAD so the daemon will  
typically by default open opportunistic links that are found by the  
discovery mechanism. let me know if that works better for you.

-m

On Aug 9, 2007, at 12:36 PM, Timur Alperovich wrote:

> Hi,
>
> I apologize for the stream of questions but I seem to be stuck  
> again. I have discoveries being sent on the multi-homed nodes and  
> nodes appear to detect their neighbors, but there are no routes  
> added for them and no multi-hop neighbors are added. What could be  
> the reason for this? I'm just trying to get a simple multi-hop  
> network to work.
>
> Timur

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] more multi hop issues
Date: Thu, 9 Aug 2007 13:20:54 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

I think you're hitting a flaw in the routing code (in this case  
DTLSR) in that it doesn't actually open the discovered links, so  
never finds out about other nodes that are reachable through them....

I'm going to work on a patch now, stay tuned.

-m

On Aug 9, 2007, at 12:36 PM, Timur Alperovich wrote:

> Hi,
>
> I apologize for the stream of questions but I seem to be stuck  
> again. I have discoveries being sent on the multi-homed nodes and  
> nodes appear to detect their neighbors, but there are no routes  
> added for them and no multi-hop neighbors are added. What could be  
> the reason for this? I'm just trying to get a simple multi-hop  
> network to work.
>
> Timur

Date: Thu, 9 Aug 2007 15:36:12 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] more multi hop issues
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_2961_30333414.1186688172907
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I apologize for the stream of questions but I seem to be stuck again. I have
discoveries being sent on the multi-homed nodes and nodes appear to detect
their neighbors, but there are no routes added for them and no multi-hop
neighbors are added. What could be the reason for this? I'm just trying to
get a simple multi-hop network to work.

Timur

------=_Part_2961_30333414.1186688172907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br><br>I apologize for the stream of questions but I seem to be stuck again. I have discoveries being sent on the multi-homed nodes and nodes appear to detect their neighbors, but there are no routes added for them and no multi-hop neighbors are added. What could be the reason for this? I&#39;m just trying to get a simple multi-hop network to work.
<br><br>Timur<br>

------=_Part_2961_30333414.1186688172907--

Cc: [email-masked], dtn-dev <[email-masked]>
From: Michael Demmer <[email-masked]>
Date: Wed, 8 Aug 2007 10:27:03 -0700
To: "Scott, Keith L." <[email-masked]>
Subject: [dtn-users] Re: [dtn-dev] changing version control systems
Sender: [email-masked]
Reply-To: [email-masked]

Good point -- even with the distributed VC systems, I would still  
maintain a master copy of the source tree on code.dtnrg.org. Anyone  
will be able to pull from that using http. There's also a way to push  
changes over ssh, just like in CVS today.

The advantage is that for an individual developer, you can do  
incremental checkins to your own "repository". With mercurial at  
least, you can easily share changes with other people inside a  
firewall in an ad-hoc manner, since it can run in an http server mode  
as well. But the master copy would be controlled via ssh like it is  
today.

-m

On Aug 8, 2007, at 10:14 AM, Scott, Keith L. wrote:

> I don't have any experience with subversion or Mercurial.  My one
> comment with respect to distributed revision control is that some  
> of us
> spend a good portion of our lives behind rather strong firewalls where
> it is virtually impossible to instantiate inbound connections to our
> machines.  In such a configuration, I suppose our (firewalled  
> peoples')
> interactions would primarily be via the distributed repository process
> running at code.dtnrg.org?
>
> 		--keith
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Demmer
> Sent: Tuesday, August 07, 2007 8:44 PM
> To: [email-masked]; dtn-dev
> Subject: [dtn-dev] changing version control systems
>
>
> I'm considering changing the main DTN reference implementation source
> repository from CVS to subversion[1] or mercurial[2].
>
> There are numerous reasons why these other systems are better version
> control mechanisms than CVS, including the ability to rename files,
> grouping modifications into logical changesets, directories that are
> editable in the VC system, and better support for branching, to name
> a few. Mercurial adds the additional advantages of being a
> distributed rather than centralized system.
>
> On the other hand, switching will likely entail transition pain, and
> some people may not be familiar with the new systems. In particular,
> mercurial has a very different usage model which will change how
> people interact with the source repository.
>
> The intent of this mail is to get a sense of the overall temperature
> of the DTN user base out there with respect to this change:
>
> Do you think it's a great idea? Is it a terrible idea?
> Will it impede your interactions with the code?
> Do you have horror stories about subversion and/or mercurial?
> Does anyone have a strong preference for one versus the other?
>
> -m
>
> ---
>
> [1] http://subversion.tigris.org/
> [2] http://www.selenic.com/mercurial/wiki/
> _______________________________________________
> dtn-dev mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-dev

Content-class: urn:content-classes:message
Date: Wed, 8 Aug 2007 13:14:43 -0400
From: "Scott, Keith L." <[email-masked]>
To: "Michael Demmer" <[email-masked]>, <[email-masked]>, "dtn-dev" <[email-masked]>
Subject: [dtn-users] RE: [dtn-dev] changing version control systems
Sender: [email-masked]
Reply-To: [email-masked]

I don't have any experience with subversion or Mercurial.  My one
comment with respect to distributed revision control is that some of us
spend a good portion of our lives behind rather strong firewalls where
it is virtually impossible to instantiate inbound connections to our
machines.  In such a configuration, I suppose our (firewalled peoples')
interactions would primarily be via the distributed repository process
running at code.dtnrg.org?

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Demmer
Sent: Tuesday, August 07, 2007 8:44 PM
To: [email-masked]; dtn-dev
Subject: [dtn-dev] changing version control systems

I'm considering changing the main DTN reference implementation source  
repository from CVS to subversion[1] or mercurial[2].

There are numerous reasons why these other systems are better version  
control mechanisms than CVS, including the ability to rename files,  
grouping modifications into logical changesets, directories that are  
editable in the VC system, and better support for branching, to name  
a few. Mercurial adds the additional advantages of being a  
distributed rather than centralized system.

On the other hand, switching will likely entail transition pain, and  
some people may not be familiar with the new systems. In particular,  
mercurial has a very different usage model which will change how  
people interact with the source repository.

The intent of this mail is to get a sense of the overall temperature  
of the DTN user base out there with respect to this change:

Do you think it's a great idea? Is it a terrible idea?
Will it impede your interactions with the code?
Do you have horror stories about subversion and/or mercurial?
Does anyone have a strong preference for one versus the other?

-m

---

[1] http://subversion.tigris.org/
[2] http://www.selenic.com/mercurial/wiki/
_______________________________________________
dtn-dev mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-dev

Date: Wed, 8 Aug 2007 13:01:13 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: dtn on a three node multi-hop
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_949_13989698.1186592473889
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I actually got it to work now: I had to set the local_addr of each of the
interfaces when creating the dtn interfaces and then use those to set up
discovery. It seems to be working now.

Timur

On 8/8/07, Michael Demmer <[email-masked]> wrote:
>
>
> The interfaces are only related to incoming bundles, and so yes, only
> impact which address the node listens on for connections.
>
> You might want to try the bonjour discovery -- If you're on Linux, you can
> install the avahi-daemon to get the mDNS stack. The ip discovery hasn't been
> well-tested on multi-homed systems (as you've seen) so it may not set up the
> bindings properly. No guarantees that bonjour will do better, but it's worth
> a shot.
>
> -m
>
> On Aug 8, 2007, at 8:40 AM, Timur Alperovich wrote:
>
> Thanks. I'll give that a try. What about specifying local_addr in the
> interface command? Does that only set the listening address?
>
> I'm using the ip module right now. From what I read in the help it appears
> only bluetooth and ip exist. Are there any others which may be better suited
> for what I'm doing?
>
> Timur
>
> On 8/8/07, Michael Demmer <[email-masked]> wrote:
> >
> > There's a local_addr option in the link configuration which tells it
> > which interface to use, if you were to set up an explicit link to the
> > other node. For example, adding this to node B's config:
> >
> > link add l-C 10.0.0.C ALWAYSON TCP local_addr=10.0.0.B
> >
> > This assumes that 10.0.0.C is C's ip address on the ad-hoc network
> > and 10.0.0.B is B's address on the ad-hoc network. The local_addr
> > option tells the node which address to bind to before connecting to
> > the other node.
> >
> > Given that, I'd love it if the discovery mechanism were to figure out
> > the situation automatically. Which discovery module are you using?
> >
> > -m <http://mailman.dtnrg.org/mailman/listinfo/dtn-users>
> >
>

------=_Part_949_13989698.1186592473889
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I actually got it to work now: I had to set the local_addr of each of the interfaces when creating the dtn interfaces and then use those to set up discovery. It seems to be working now.<br><br>Timur<br><br><div><span class="gmail_quote">
On 8/8/07, <b class="gmail_sendername">Michael Demmer</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><br></div><div>The interfaces are only related to incoming bundles, and so yes, only impact which address the node listens on for connections.</div><div><br></div><div>You might want to try the bonjour discovery -- If you&#39;re on Linux, you can install the avahi-daemon to get the mDNS stack. The ip discovery hasn&#39;t been well-tested on multi-homed systems (as you&#39;ve seen) so it may not set up the bindings properly. No guarantees that bonjour will do better, but it&#39;s worth a shot.
</div><span class="sg"><div><br></div><div>-m</div></span><div><span class="e" id="q_114462ef3b95e62b_2"><div><br><div><div>On Aug 8, 2007, at 8:40 AM, Timur Alperovich wrote:</div><br><blockquote type="cite">Thanks. I&#39;ll give that a try. What about specifying local_addr in the interface command? Does that only set the listening address? 
<br><br>I&#39;m using the ip module right now. From what I read in the help it appears only bluetooth and ip exist. Are there any others which may be better suited for what I&#39;m doing? <br><br>Timur<br><br><div><span class="gmail_quote">
On 8/8/07, <b class="gmail_sendername">Michael Demmer</b> &lt;<a href="mailto:[email-masked]" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 There&#39;s a local_addr option in the link configuration which tells it<br>which interface to use, if you were to set up an explicit link to the<br>other node. For example, adding this to node B&#39;s config:<br><br>link add l-C 
10.0.0.C ALWAYSON TCP local_addr=10.0.0.B<br><br>This assumes that 10.0.0.C is C&#39;s ip address on the ad-hoc network<br>and 10.0.0.B is B&#39;s address on the ad-hoc network. The local_addr<br>option tells the node which address to bind to before connecting to 
<br>the other node.<br><br>Given that, I&#39;d love it if the discovery mechanism were to figure out<br>the situation automatically. Which discovery module are you using?<br><br>-m<a href="http://mailman.dtnrg.org/mailman/listinfo/dtn-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
</a><br></blockquote></div></blockquote></div></div></span></div></div></blockquote></div>

------=_Part_949_13989698.1186592473889--

Date: Wed, 8 Aug 2007 11:59:25 -0500
From: "Jeff Wilson" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: dtn on a three node multi-hop
Sender: [email-masked]
Reply-To: [email-masked]

This weakness on multi-homed systems may well be inherent to the
design of the discovery module.  Both the IP and the Bluetooth modules
were designed so that the discovery piece applies to the address
family, and the announce piece serves as the registration for each
distinct Interface (listening Convergence Layer instance).  With
hindsight, it seems like a better approach is to move the discovery
module to represent a physical interface, and the announce piece
remains as a registration per CL listener.

But Mike has hit on the real zinger -- how does this get automated?  I
propose a boolean flag -- enable discovery -- per listening CL, then
"somehow" the system "automagically" figures out the rest.  Notice the
hand-waving ... :) ... I dunno how to make it happen, just proposing a
"How It Ought To Be" scenario.

 Jeff

On Aug 8, 2007, at 10:53 AM, Michael Demmer wrote:

The interfaces are only related to incoming bundles, and so yes, only
impact which address the node listens on for connections.

You might want to try the bonjour discovery -- If you're on Linux, you
can install the avahi-daemon to get the mDNS stack. The ip discovery
hasn't been well-tested on multi-homed systems (as you've seen) so it
may not set up the bindings properly. No guarantees that bonjour will
do better, but it's worth a shot.

-m

On Aug 8, 2007, at 8:40 AM, Timur Alperovich wrote:
Thanks. I'll give that a try. What about specifying local_addr in the
interface command? Does that only set the listening address?

I'm using the ip module right now. From what I read in the help it
appears only bluetooth and ip exist. Are there any others which may be
better suited for what I'm doing?

Timur

On 8/8/07, Michael Demmer <[email-masked]> wrote:
> There's a local_addr option in the link configuration which tells it
> which interface to use, if you were to set up an explicit link to the
> other node. For example, adding this to node B's config:
>
> link add l-C 10.0.0.C ALWAYSON TCP local_addr=10.0.0.B
>
> This assumes that 10.0.0.C is C's ip address on the ad-hoc network
> and 10.0.0.B is B's address on the ad-hoc network. The local_addr
> option tells the node which address to bind to before connecting to
> the other node.
>
> Given that, I'd love it if the discovery mechanism were to figure out
> the situation automatically. Which discovery module are you using?
>
> -m
>
> On Aug 8, 2007, at 7:49 AM, Timur Alperovich wrote:
>
> > Ok, I'm still not sure how to make dtn use a particular interface.
> > I tried using the interfaces command and specifying the address. I
> > also tried specifying the address in the discovery command. In both
> > cases all packets are sent out on only one of the interfaces (eth0
> > in my case). I'd like to also use the wireless and have the node
> > act as a bridge on two different subnets. What else do I need to do
> > to do that?
> >
> > Timur
> >
> > >Hi,
> > >
> > >I'm trying to use DTN to do some multi-hop networking with the
> > dtlsr router and I'm running into a problem with what I >think may
> > be the config. I have three nodes. Node A just has an ethernet
> > connection. Node B is connected to A over >ethernet and also has a
> > wireless card in ad-hoc mode using which it connects to node C. I
> > cannot seem to detect any >discoveries over the wireless from node
> > B to C. Is there anything I need to add to have dtn work across
> > multiple >interfaces? The wireless network is also on a different
> > subnet. Would that make a difference?
> > >
> > >Thank you,
> > >Timur
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] Fwd: dtn on a three node multi-hop
Date: Wed, 8 Aug 2007 08:53:21 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

--Apple-Mail-1--24712719
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

The interfaces are only related to incoming bundles, and so yes, only  
impact which address the node listens on for connections.

You might want to try the bonjour discovery -- If you're on Linux,  
you can install the avahi-daemon to get the mDNS stack. The ip  
discovery hasn't been well-tested on multi-homed systems (as you've  
seen) so it may not set up the bindings properly. No guarantees that  
bonjour will do better, but it's worth a shot.

-m

On Aug 8, 2007, at 8:40 AM, Timur Alperovich wrote:

> Thanks. I'll give that a try. What about specifying local_addr in  
> the interface command? Does that only set the listening address?
>
> I'm using the ip module right now. From what I read in the help it  
> appears only bluetooth and ip exist. Are there any others which may  
> be better suited for what I'm doing?
>
> Timur
>
> On 8/8/07, Michael Demmer <[email-masked]> wrote:
> There's a local_addr option in the link configuration which tells it
> which interface to use, if you were to set up an explicit link to the
> other node. For example, adding this to node B's config:
>
> link add l-C 10.0.0.C ALWAYSON TCP local_addr=10.0.0.B
>
> This assumes that 10.0.0.C is C's ip address on the ad-hoc network
> and 10.0.0.B is B's address on the ad-hoc network. The local_addr
> option tells the node which address to bind to before connecting to
> the other node.
>
> Given that, I'd love it if the discovery mechanism were to figure out
> the situation automatically. Which discovery module are you using?
>
> -m
>
> On Aug 8, 2007, at 7:49 AM, Timur Alperovich wrote:
>
> > Ok, I'm still not sure how to make dtn use a particular interface.
> > I tried using the interfaces command and specifying the address. I
> > also tried specifying the address in the discovery command. In both
> > cases all packets are sent out on only one of the interfaces (eth0
> > in my case). I'd like to also use the wireless and have the node
> > act as a bridge on two different subnets. What else do I need to do
> > to do that?
> >
> > Timur
> >
> > >Hi,
> > >
> > >I'm trying to use DTN to do some multi-hop networking with the
> > dtlsr router and I'm running into a problem with what I >think may
> > be the config. I have three nodes. Node A just has an ethernet
> > connection. Node B is connected to A over >ethernet and also has a
> > wireless card in ad-hoc mode using which it connects to node C. I
> > cannot seem to detect any >discoveries over the wireless from node
> > B to C. Is there anything I need to add to have dtn work across
> > multiple >interfaces? The wireless network is also on a different
> > subnet. Would that make a difference?
> > >
> > >Thank you,
> > >Timur
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

--Apple-Mail-1--24712719
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=US-ASCII

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The interfaces are only =
related to incoming bundles, and so yes, only impact which address the =
node listens on for connections.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>You might want to try the =
bonjour discovery -- If you're on Linux, you can install the =
avahi-daemon to get the mDNS stack. The ip discovery hasn't been =
well-tested on multi-homed systems (as you've seen) so it may not set up =
the bindings properly. No guarantees that bonjour will do better, but =
it's worth a shot.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>-m</DIV><DIV><BR><DIV><DIV>On=
 Aug 8, 2007, at 8:40 AM, Timur Alperovich wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite">Thanks. =
I'll give that a try. What about specifying local_addr in the interface =
command? Does that only set the listening address? <BR><BR>I'm using the =
ip module right now. =46rom what I read in the help it appears only =
bluetooth and ip exist. Are there any others which may be better suited =
for what I'm doing? <BR><BR>Timur<BR><BR><DIV><SPAN =
class=3D"gmail_quote">On 8/8/07, <B class=3D"gmail_sendername">Michael =
Demmer</B> &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt; =
wrote:</SPAN><BLOCKQUOTE class=3D"gmail_quote" style=3D"border-left: 1px =
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;"> There's a local_addr option in the link configuration which tells =
it<BR>which interface to use, if you were to set up an explicit link to =
the<BR>other node. For example, adding this to node B's =
config:<BR><BR>link add l-C 10.0.0.C ALWAYSON TCP =
local_addr=3D10.0.0.B<BR><BR>This assumes that 10.0.0.C is C's ip =
address on the ad-hoc network<BR>and 10.0.0.B is B's address on the =
ad-hoc network. The local_addr<BR>option tells the node which address to =
bind to before connecting to <BR>the other node.<BR><BR>Given that, I'd =
love it if the discovery mechanism were to figure out<BR>the situation =
automatically. Which discovery module are you using?<BR><BR>-m<BR><BR>On =
Aug 8, 2007, at 7:49 AM, Timur Alperovich wrote: <BR><BR>&gt; Ok, I'm =
still not sure how to make dtn use a particular interface.<BR>&gt; I =
tried using the interfaces command and specifying the address. I<BR>&gt; =
also tried specifying the address in the discovery command. In both =
<BR>&gt; cases all packets are sent out on only one of the interfaces =
(eth0<BR>&gt; in my case). I'd like to also use the wireless and have =
the node<BR>&gt; act as a bridge on two different subnets. What else do =
I need to do <BR>&gt; to do that?<BR>&gt;<BR>&gt; Timur<BR>&gt;<BR>&gt; =
&gt;Hi,<BR>&gt; &gt;<BR>&gt; &gt;I'm trying to use DTN to do some =
multi-hop networking with the<BR>&gt; dtlsr router and I'm running into =
a problem with what I &gt;think may <BR>&gt; be the config. I have three =
nodes. Node A just has an ethernet<BR>&gt; connection. Node B is =
connected to A over &gt;ethernet and also has a<BR>&gt; wireless card in =
ad-hoc mode using which it connects to node C. I <BR>&gt; cannot seem to =
detect any &gt;discoveries over the wireless from node<BR>&gt; B to C. =
Is there anything I need to add to have dtn work across<BR>&gt; multiple =
&gt;interfaces? The wireless network is also on a different <BR>&gt; =
subnet. Would that make a difference?<BR>&gt; &gt;<BR>&gt; &gt;Thank =
you,<BR>&gt; =
&gt;Timur<BR><BR>_______________________________________________<BR>dtn-us=
ers mailing list<BR><A href=3D"mailto:[email-masked]"> =
[email-masked]</A><BR><A =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-users">http://mailma=
n.dtnrg.org/mailman/listinfo/dtn-users</A><BR></BLOCKQUOTE></DIV><BR></BLO=
CKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-1--24712719--

Date: Wed, 8 Aug 2007 11:40:28 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: dtn on a three node multi-hop
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_701_29221967.1186587628209
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks. I'll give that a try. What about specifying local_addr in the
interface command? Does that only set the listening address?

I'm using the ip module right now. From what I read in the help it appears
only bluetooth and ip exist. Are there any others which may be better suited
for what I'm doing?

Timur

On 8/8/07, Michael Demmer <[email-masked]> wrote:
>
> There's a local_addr option in the link configuration which tells it
> which interface to use, if you were to set up an explicit link to the
> other node. For example, adding this to node B's config:
>
> link add l-C 10.0.0.C ALWAYSON TCP local_addr=10.0.0.B
>
> This assumes that 10.0.0.C is C's ip address on the ad-hoc network
> and 10.0.0.B is B's address on the ad-hoc network. The local_addr
> option tells the node which address to bind to before connecting to
> the other node.
>
> Given that, I'd love it if the discovery mechanism were to figure out
> the situation automatically. Which discovery module are you using?
>
> -m
>
> On Aug 8, 2007, at 7:49 AM, Timur Alperovich wrote:
>
> > Ok, I'm still not sure how to make dtn use a particular interface.
> > I tried using the interfaces command and specifying the address. I
> > also tried specifying the address in the discovery command. In both
> > cases all packets are sent out on only one of the interfaces (eth0
> > in my case). I'd like to also use the wireless and have the node
> > act as a bridge on two different subnets. What else do I need to do
> > to do that?
> >
> > Timur
> >
> > >Hi,
> > >
> > >I'm trying to use DTN to do some multi-hop networking with the
> > dtlsr router and I'm running into a problem with what I >think may
> > be the config. I have three nodes. Node A just has an ethernet
> > connection. Node B is connected to A over >ethernet and also has a
> > wireless card in ad-hoc mode using which it connects to node C. I
> > cannot seem to detect any >discoveries over the wireless from node
> > B to C. Is there anything I need to add to have dtn work across
> > multiple >interfaces? The wireless network is also on a different
> > subnet. Would that make a difference?
> > >
> > >Thank you,
> > >Timur
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

------=_Part_701_29221967.1186587628209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks. I&#39;ll give that a try. What about specifying local_addr in the interface command? Does that only set the listening address? <br><br>I&#39;m using the ip module right now. From what I read in the help it appears only bluetooth and ip exist. Are there any others which may be better suited for what I&#39;m doing?
<br><br>Timur<br><br><div><span class="gmail_quote">On 8/8/07, <b class="gmail_sendername">Michael Demmer</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There&#39;s a local_addr option in the link configuration which tells it<br>which interface to use, if you were to set up an explicit link to the<br>other node. For example, adding this to node B&#39;s config:<br><br>link add l-C 
10.0.0.C ALWAYSON TCP local_addr=10.0.0.B<br><br>This assumes that 10.0.0.C is C&#39;s ip address on the ad-hoc network<br>and 10.0.0.B is B&#39;s address on the ad-hoc network. The local_addr<br>option tells the node which address to bind to before connecting to
<br>the other node.<br><br>Given that, I&#39;d love it if the discovery mechanism were to figure out<br>the situation automatically. Which discovery module are you using?<br><br>-m<br><br>On Aug 8, 2007, at 7:49 AM, Timur Alperovich wrote:
<br><br>&gt; Ok, I&#39;m still not sure how to make dtn use a particular interface.<br>&gt; I tried using the interfaces command and specifying the address. I<br>&gt; also tried specifying the address in the discovery command. In both
<br>&gt; cases all packets are sent out on only one of the interfaces (eth0<br>&gt; in my case). I&#39;d like to also use the wireless and have the node<br>&gt; act as a bridge on two different subnets. What else do I need to do
<br>&gt; to do that?<br>&gt;<br>&gt; Timur<br>&gt;<br>&gt; &gt;Hi,<br>&gt; &gt;<br>&gt; &gt;I&#39;m trying to use DTN to do some multi-hop networking with the<br>&gt; dtlsr router and I&#39;m running into a problem with what I &gt;think may
<br>&gt; be the config. I have three nodes. Node A just has an ethernet<br>&gt; connection. Node B is connected to A over &gt;ethernet and also has a<br>&gt; wireless card in ad-hoc mode using which it connects to node C. I
<br>&gt; cannot seem to detect any &gt;discoveries over the wireless from node<br>&gt; B to C. Is there anything I need to add to have dtn work across<br>&gt; multiple &gt;interfaces? The wireless network is also on a different
<br>&gt; subnet. Would that make a difference?<br>&gt; &gt;<br>&gt; &gt;Thank you,<br>&gt; &gt;Timur<br><br>_______________________________________________<br>dtn-users mailing list<br><a href="mailto:[email-masked]">
[email-masked]</a><br><a href="http://mailman.dtnrg.org/mailman/listinfo/dtn-users">http://mailman.dtnrg.org/mailman/listinfo/dtn-users</a><br></blockquote></div><br>

------=_Part_701_29221967.1186587628209--

From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] Fwd: dtn on a three node multi-hop
Date: Wed, 8 Aug 2007 08:02:56 -0700
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

There's a local_addr option in the link configuration which tells it  
which interface to use, if you were to set up an explicit link to the  
other node. For example, adding this to node B's config:

link add l-C 10.0.0.C ALWAYSON TCP local_addr=10.0.0.B

This assumes that 10.0.0.C is C's ip address on the ad-hoc network  
and 10.0.0.B is B's address on the ad-hoc network. The local_addr  
option tells the node which address to bind to before connecting to  
the other node.

Given that, I'd love it if the discovery mechanism were to figure out  
the situation automatically. Which discovery module are you using?

-m

On Aug 8, 2007, at 7:49 AM, Timur Alperovich wrote:

> Ok, I'm still not sure how to make dtn use a particular interface.  
> I tried using the interfaces command and specifying the address. I  
> also tried specifying the address in the discovery command. In both  
> cases all packets are sent out on only one of the interfaces (eth0  
> in my case). I'd like to also use the wireless and have the node  
> act as a bridge on two different subnets. What else do I need to do  
> to do that?
>
> Timur
>
> >Hi,
> >
> >I'm trying to use DTN to do some multi-hop networking with the  
> dtlsr router and I'm running into a problem with what I >think may  
> be the config. I have three nodes. Node A just has an ethernet  
> connection. Node B is connected to A over >ethernet and also has a  
> wireless card in ad-hoc mode using which it connects to node C. I  
> cannot seem to detect any >discoveries over the wireless from node  
> B to C. Is there anything I need to add to have dtn work across  
> multiple >interfaces? The wireless network is also on a different  
> subnet. Would that make a difference?
> >
> >Thank you,
> >Timur

Date: Wed, 8 Aug 2007 10:49:28 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Fwd: dtn on a three node multi-hop
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_517_11235481.1186584568931
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Ok, I'm still not sure how to make dtn use a particular interface. I tried
using the interfaces command and specifying the address. I also tried
specifying the address in the discovery command. In both cases all packets
are sent out on only one of the interfaces (eth0 in my case). I'd like to
also use the wireless and have the node act as a bridge on two different
subnets. What else do I need to do to do that?

Timur

>Hi,
>
>I'm trying to use DTN to do some multi-hop networking with the dtlsr router
and I'm running into a problem with what I >think may be the config. I have
three nodes. Node A just has an ethernet connection. Node B is connected to
A over >ethernet and also has a wireless card in ad-hoc mode using which it
connects to node C. I cannot seem to detect any >discoveries over the
wireless from node B to C. Is there anything I need to add to have dtn work
across multiple >interfaces? The wireless network is also on a different
subnet. Would that make a difference?
>
>Thank you,
>Timur

------=_Part_517_11235481.1186584568931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Ok, I&#39;m still not sure how to make dtn use a particular interface. I tried using the interfaces command and specifying the address. I also tried specifying the address in the discovery command. In both cases all packets are sent out on only one of the interfaces (eth0 in my case). I&#39;d like to also use the wireless and have the node act as a bridge on two different subnets. What else do I need to do to do that?
<br><br>Timur<br><span class="gmail_quote"><span class="sg"><br></span></span><div><span class="e" id="q_11442b3dd27ac2cf_3"><div><span><span class="gmail_quote"></span>&gt;Hi,<br>&gt;
<br>&gt;I&#39;m trying to use DTN to do some multi-hop networking with the dtlsr router and I&#39;m running into a problem with what I &gt;think may be the config. I have three nodes. Node A just has an ethernet connection. Node B is connected to A over &gt;ethernet and also has a wireless card in ad-hoc mode using which it connects to node C. I cannot seem to detect any &gt;discoveries over the wireless from node B to C. Is there anything I need to add to have dtn work across multiple &gt;interfaces? The wireless network is also on a different subnet. Would that make a difference?
<br>&gt;<br>&gt;Thank you,<br><span>&gt;Timur<br>
</span>
</span></div>
</span></div>

------=_Part_517_11235481.1186584568931--

From: Michael Demmer <[email-masked]>
Date: Tue, 7 Aug 2007 17:43:41 -0700
To: [email-masked], dtn-dev <[email-masked]>
Subject: [dtn-users] changing version control systems
Sender: [email-masked]
Reply-To: [email-masked]

I'm considering changing the main DTN reference implementation source  
repository from CVS to subversion[1] or mercurial[2].

There are numerous reasons why these other systems are better version  
control mechanisms than CVS, including the ability to rename files,  
grouping modifications into logical changesets, directories that are  
editable in the VC system, and better support for branching, to name  
a few. Mercurial adds the additional advantages of being a  
distributed rather than centralized system.

On the other hand, switching will likely entail transition pain, and  
some people may not be familiar with the new systems. In particular,  
mercurial has a very different usage model which will change how  
people interact with the source repository.

The intent of this mail is to get a sense of the overall temperature  
of the DTN user base out there with respect to this change:

Do you think it's a great idea? Is it a terrible idea?
Will it impede your interactions with the code?
Do you have horror stories about subversion and/or mercurial?
Does anyone have a strong preference for one versus the other?

-m

---

[1] http://subversion.tigris.org/
[2] http://www.selenic.com/mercurial/wiki/

Date: Tue, 7 Aug 2007 19:40:57 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Fwd: dtn on a three node multi-hop
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_34006_17606343.1186530057591
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Never mind. I realized that I have to specify addresses for the interfaces.

Timur

>Hi,
>
>I'm trying to use DTN to do some multi-hop networking with the dtlsr router
and I'm running into a problem with what I >think may be the config. I have
three nodes. Node A just has an ethernet connection. Node B is connected to
A over >ethernet and also has a wireless card in ad-hoc mode using which it
connects to node C. I cannot seem to detect any >discoveries over the
wireless from node B to C. Is there anything I need to add to have dtn work
across multiple >interfaces? The wireless network is also on a different
subnet. Would that make a difference?
>
>Thank you,
>Timur

------=_Part_34006_17606343.1186530057591
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<span class="gmail_quote">Never mind. I realized that I have to specify addresses for the interfaces.<br><br>Timur<br><br></span><div><span class="e" id="q_1144298d0717aed3_0"><span class="gmail_quote"></span>&gt;Hi,<br>&gt;
<br>&gt;I&#39;m trying to use DTN to do some multi-hop networking with the dtlsr router and I&#39;m running into a problem with what I &gt;think may be the config. I have three nodes. Node A just has an ethernet connection. Node B is connected to A over &gt;ethernet and also has a wireless card in ad-hoc mode using which it connects to node C. I cannot seem to detect any &gt;discoveries over the wireless from node B to C. Is there anything I need to add to have dtn work across multiple &gt;interfaces? The wireless network is also on a different subnet. Would that make a difference?
<br>&gt;<br>&gt;Thank you,<br><span>&gt;Timur<br>
</span>
</span></div>

------=_Part_34006_17606343.1186530057591--

Date: Tue, 7 Aug 2007 19:11:25 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] dtn on a three node multi-hop
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_33962_27565197.1186528285077
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I'm trying to use DTN to do some multi-hop networking with the dtlsr router
and I'm running into a problem with what I think may be the config. I have
three nodes. Node A just has an ethernet connection. Node B is connected to
A over ethernet and also has a wireless card in ad-hoc mode using which it
connects to node C. I cannot seem to detect any discoveries over the
wireless from node B to C. Is there anything I need to add to have dtn work
across multiple interfaces? The wireless network is also on a different
subnet. Would that make a difference?

Thank you,
Timur

------=_Part_33962_27565197.1186528285077
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<span class="gmail_quote"></span>Hi,<br><br>I&#39;m trying to use DTN to do some multi-hop networking with the dtlsr router and I&#39;m running into a problem with what I think may be the config. I have three nodes. Node A just has an ethernet connection. Node B is connected to A over ethernet and also has a wireless card in ad-hoc mode using which it connects to node C. I cannot seem to detect any discoveries over the wireless from node B to C. Is there anything I need to add to have dtn work across multiple interfaces? The wireless network is also on a different subnet. Would that make a difference?
<br><br>Thank you,<br><span class="sg">Timur<br>
</span>

------=_Part_33962_27565197.1186528285077--

Cc: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Tue, 7 Aug 2007 11:47:00 -0700
To: [email-masked]
Subject: [dtn-users] Re: DTN2 Compilation Problem
Sender: [email-masked]
Reply-To: [email-masked]

I just tried this test, and to me it looks like the configure script  
propagated the --with-tcl argument to oasys properly. Can you send me  
the output from your failed configure invocation and the contents of  
the generated config.log so I can help see what's going on?

Also, make sure you passed an absolute path to --with-tcl if you want  
it to work properly.

-m

On Aug 2, 2007, at 10:21 AM, [email-masked] wrote:

> There's a problem when compiling the DTN2 code.  If you specify a  
> different
> Tcl library location for compiling DTN2, it won't propagate the  
> change to
> Oasys (which will them fail as it can't find the library).  I  
> haven't tested
> to see if this is fixed by the warning to cache things found in ./ 
> configure (I
> suspect it is), but a note somewhere might be useful.
>
> Doing a ./configure on Oasys with the proper location seemed to fix  
> the
> problem.
>
> Jim Wyllie

Date: Thu, 2 Aug 2007 15:44:04 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] tcp neighbor discovery
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_19175_10627104.1186083844800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Never mind actually. I realized that I needed to configure discovery and
it's working now. Thanks for all the tips.

Timur

On 8/2/07, Timur Alperovich <[email-masked]> wrote:
>
> Mike,
>
> Thanks for the help. I did not see dtlsr listed in the list of routers in
> the config file and that's why I was a little confused and tried to use
> linkstate. I ran into another issue now, which I hope is not a big deal
> either. I tried using the dtlsr router by simply setting the route type to
> dtlsr, but I'm not sure what else, if anything, I need to add for nodes to
> discover their neighbors. Is there any chance you could send me a sample
> config file?
>
> Thank you,
> Timur
>
> On 7/30/07, Michael Demmer <[email-masked]> wrote:
> >
> > Oh... you want the "dtlsr" router, not the "linkstate" router. That
> > latter one is very old (and should probably just be dropped from the
> > repository).
> >
> > -mike
> >
>

------=_Part_19175_10627104.1186083844800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Never mind actually. I realized that I needed to configure discovery and it&#39;s working now. Thanks for all the tips.<br><br>Timur<br><br><div><span class="gmail_quote">On 8/2/07, <b class="gmail_sendername">Timur Alperovich
</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mike,<br><br>Thanks for the help. I did not see dtlsr listed in the list of routers in the config file and that&#39;s why I was a little confused and tried to use linkstate. I ran into another issue now, which I hope is not a big deal either. I tried using the dtlsr router by simply setting the route type to dtlsr, but I&#39;m not sure what else, if anything, I need to add for nodes to discover their neighbors. Is there any chance you could send me a sample config file?
<br><br>Thank you,<br><span class="sg">Timur<br><br></span><div><span class="q"><span class="gmail_quote">On 7/30/07, <b class="gmail_sendername">Michael Demmer</b> &lt;<a href="mailto:[email-masked]" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
[email-masked]</a>&gt; wrote:</span></span><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>Oh... you want the &quot;dtlsr&quot; router, not the &quot;linkstate&quot; router. That latter one is very old (and should probably just be dropped from the repository).</div><div><br></div><div>-mike</div>
</div></blockquote></span></div>
</blockquote></div><br>

------=_Part_19175_10627104.1186083844800--

Date: Thu, 2 Aug 2007 12:36:54 -0400
From: "Timur Alperovich" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] tcp neighbor discovery
Sender: [email-masked]
Reply-To: [email-masked]

------=_Part_18534_7071407.1186072614355
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Mike,

Thanks for the help. I did not see dtlsr listed in the list of routers in
the config file and that's why I was a little confused and tried to use
linkstate. I ran into another issue now, which I hope is not a big deal
either. I tried using the dtlsr router by simply setting the route type to
dtlsr, but I'm not sure what else, if anything, I need to add for nodes to
discover their neighbors. Is there any chance you could send me a sample
config file?

Thank you,
Timur

On 7/30/07, Michael Demmer <[email-masked]> wrote:
>
> Oh... you want the "dtlsr" router, not the "linkstate" router. That latter
> one is very old (and should probably just be dropped from the repository).
>
> -mike
>

------=_Part_18534_7071407.1186072614355
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Mike,<br><br>Thanks for the help. I did not see dtlsr listed in the list of routers in the config file and that&#39;s why I was a little confused and tried to use linkstate. I ran into another issue now, which I hope is not a big deal either. I tried using the dtlsr router by simply setting the route type to dtlsr, but I&#39;m not sure what else, if anything, I need to add for nodes to discover their neighbors. Is there any chance you could send me a sample config file?
<br><br>Thank you,<br>Timur<br><br><div><span class="gmail_quote">On 7/30/07, <b class="gmail_sendername">Michael Demmer</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div>Oh... you want the &quot;dtlsr&quot; router, not the &quot;linkstate&quot; router. That latter one is very old (and should probably just be dropped from the repository).</div><div><br></div><div>-mike</div>
</div></blockquote></div>

------=_Part_18534_7071407.1186072614355--