Subject: Re: [dtn-users] Packet sniffing
From: Jeff Allen <[email-masked]>
To: [email-masked]
Date: Fri, 27 May 2005 11:36:57 +0200
List-Id: discussion/answers list for users of the dtn reference implementation <dtn-users.mailman.dtnrg.org>

Another way to look at it is that the DTN2 implementation IS the spec
right now, and you will have to read the code to understand what's
going out on the wire. In January, I added some stuff to the protocol
to deal with graceful shutdowns and magic numbers. As there was no
place to document the changes at the time, I didn't do so.

 -jra

Date: Thu, 26 May 2005 08:23:40 -0500
From: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

I updated this morning, and everything compiles now.  Thanks again for
your help with this.

           jw

On 5/25/05, Michael Demmer <[email-masked]> wrote:
> 
> > Awesome.  Thanks for your help with this.
> 
> Actually, since then I've fixed the problems with 3.4 so if you
> update, it should be all set.
> 
> -m
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Wed, 25 May 2005 18:50:40 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

> Awesome.  Thanks for your help with this.

Actually, since then I've fixed the problems with 3.4 so if you
update, it should be all set.

-m

Date: Wed, 25 May 2005 20:16:17 -0500
From: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

Awesome.  Thanks for your help with this.

           jw

On 5/25/05, Michael Demmer <[email-masked]> wrote:
> 
> Ah -- I haven't tried building with gcc 3.4 so that's most likely what
> the issue is. I can try to work it out once I get the basic berkeley
> db support working.
> 
> -m
> 
> 
> > Any other useful stuff I can send?  Here's `uname -a` and `gcc -v`
> >
> >              thanks for your time,
> >                jw
> >
> > $ uname -a
> > Linux dtnbox 2.6.10-1.766_FC3 #1 Wed Feb 9 23:06:42 EST 2005 i686 i686
> > i386 GNU/Linux
> >
> > $ gcc -v
> > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > --disable-checking --with-system-zlib --enable-__cxa_atexit
> > --disable-libunwind-exceptions --enable-java-awt=gtk
> > --host=i386-redhat-linux
> > Thread model: posix
> > gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
> >
> >
> > On 5/25/05, Michael Demmer <[email-masked]> wrote:
> > >
> > > The durable storage stuff in oasys is in the middle of some very heavy
> > > surgery and rework, but does at least compile for me and I'm in the
> > > midst of getting the berkeley db part to work.
> > >
> > > Can you post specifics about your configuration, including GCC version
> > > and OS version?
> > >
> > > -m
> > > _______________________________________________
> > > 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
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Wed, 25 May 2005 10:23:10 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

Ah -- I haven't tried building with gcc 3.4 so that's most likely what
the issue is. I can try to work it out once I get the basic berkeley
db support working.

-m

> Any other useful stuff I can send?  Here's `uname -a` and `gcc -v` 
> 
>              thanks for your time,
>                jw
> 
> $ uname -a
> Linux dtnbox 2.6.10-1.766_FC3 #1 Wed Feb 9 23:06:42 EST 2005 i686 i686
> i386 GNU/Linux
> 
> $ gcc -v
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
> 
> 
> On 5/25/05, Michael Demmer <[email-masked]> wrote:
> > 
> > The durable storage stuff in oasys is in the middle of some very heavy
> > surgery and rework, but does at least compile for me and I'm in the
> > midst of getting the berkeley db part to work.
> > 
> > Can you post specifics about your configuration, including GCC version
> > and OS version?
> > 
> > -m
> > _______________________________________________
> > 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

Date: Wed, 25 May 2005 11:03:23 -0500
From: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

Any other useful stuff I can send?  Here's `uname -a` and `gcc -v` 

             thanks for your time,
               jw

$ uname -a
Linux dtnbox 2.6.10-1.766_FC3 #1 Wed Feb 9 23:06:42 EST 2005 i686 i686
i386 GNU/Linux

$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

On 5/25/05, Michael Demmer <[email-masked]> wrote:
> 
> The durable storage stuff in oasys is in the middle of some very heavy
> surgery and rework, but does at least compile for me and I'm in the
> midst of getting the berkeley db part to work.
> 
> Can you post specifics about your configuration, including GCC version
> and OS version?
> 
> -m
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Wed, 25 May 2005 08:28:28 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

The durable storage stuff in oasys is in the middle of some very heavy
surgery and rework, but does at least compile for me and I'm in the
midst of getting the berkeley db part to work.

Can you post specifics about your configuration, including GCC version
and OS version?

-m

Date: Wed, 25 May 2005 08:45:25 -0500
From: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: [dtn-users] CVS problems
Sender: [email-masked]
Reply-To: [email-masked]

Hi,

I ran `cvs up -Pd` and noticed that something's going on with
oasys/storage/Durable* ... now I'm unable to compile.  I get the
following error ...

<noisy compiler output>
[/src/DTN2]$ ./configure -C && make
... <snip> ...
make -w -C oasys
make[1]: Entering directory `/src/DTN2/oasys'
g++ -I.   -g -fno-inline  -MMD -MP -MT "storage/DurableStore.o
storage/DurableStore.E storage/DurableStore.po" -Wall -Werror  -c
storage/DurableStore.cc -o storage/DurableStore.o
In file included from storage/DurableStore.h:45,
                 from storage/DurableStore.cc:1:
storage/../serialize/TypeCollection.h: In member function `int
oasys::TypeCollection<_Collection>::new_object(u_int32_t, _Type**)':
storage/../serialize/TypeCollection.h:156: error: invalid use of
undefined type `struct oasys::TypeCollectionHelper'
storage/../serialize/TypeCollection.h:49: error: forward declaration
of `struct oasys::TypeCollectionHelper'
storage/../serialize/TypeCollection.h: In member function `const char*
oasys::TypeCollection<_Collection>::type_name(u_int32_t)':
storage/../serialize/TypeCollection.h:173: error: invalid use of
undefined type `struct oasys::TypeCollectionHelper'
storage/../serialize/TypeCollection.h:49: error: forward declaration
of `struct oasys::TypeCollectionHelper'
In file included from storage/DurableStore.h:183,
                 from storage/DurableStore.cc:1:
storage/DurableStore.tcc: In member function `int
oasys::DurableStore::get_table(oasys::SingleTypeDurableTable<_DataType>**,
std::string, int, oasys::DurableObjectCache*)':
storage/DurableStore.tcc:22: error: missing template arguments before '(' token
storage/DurableStore.tcc:25: error: `db_name' undeclared (first use
this function)
storage/DurableStore.tcc:25: error: (Each undeclared identifier is
reported only once for each function it appears in.)
storage/DurableStore.tcc: In member function `int
oasys::DurableStore::get_table(oasys::MultiTypeDurableTable<_BaseType,
_Collection>**, std::string, int, oasys::DurableObjectCache*)':
storage/DurableStore.tcc:62: error: `typecode' undeclared (first use
this function)
storage/DurableStore.tcc:68: error: `protoypes' undeclared (first use
this function)
storage/DurableStore.tcc:68: error: missing template arguments before '(' token
storage/../debug/Log.h:369: error: too few arguments to function `int
oasys::__logf(oasys::log_level_t, const char*, const char*, ...)'
storage/DurableStore.tcc:76: error: at this point in file
storage/DurableStore.tcc:82: error: `db_name' undeclared (first use
this function)
make[1]: *** [storage/DurableStore.o] Error 1
make[1]: Leaving directory `/src/DTN2/oasys'
make: *** [oasys] Error 2
</noisy compiler output>

Have I misconfigured?  Or is there something amiss in CVS?

    Thanks for your time,
     jw

Date: Tue, 24 May 2005 10:14:14 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Packet sniffing
Sender: [email-masked]
Reply-To: [email-masked]

> I am having some problems trying to understand the protocol, I am
> sniffing the network when I send a file from 1 computer to another
> and looking into the tcp packets to the data of them I am not able
> to recognize the headers of the internet draft of Bundle protocol
> Specification September 2004 I am following. Here is the sequence I
> got without the TCP headers and in a first packet that arrives from
> sender to receiver..

The TCP convergence layer adds a small preamble to every bundle
transmission. Specifically, a one-byte message identification code
(0x01 == BUNDLE_DATA) and then the following 12 byte preamble:

    struct BundleDataHeader {
        u_int32_t bundle_id;		///< bundle identifier at sender
        u_int32_t bundle_length;	///< length of the bundle + headers
        u_int16_t header_length;	///< length of the bundle header
        u_int16_t pad;			///< unused
    } __attribute__((packed));

So in your dump below, the primary bundle header actually starts at
byte 14 with value 0x04, i.e. the "current" version of the bundle
protocol. 

> hexadecimal                                         ASCII translation
>   01 00 00 00 00 00 00 0d  7a 00 87 13 44 04 02 08 ........z...D...
>   00 02 01 01 03 4e 0a c7  bd 42 93 1e 77 00 00 00 .....N...B..w...
>   00 05 04 08 69 6e 74 65  72 6e 65 74 32 68 6f 73 ....internet2hos
>   74 3a 2f 2f 74 65 73 74  31 2f 64 74 6e 63 70 2f t://test1/dtncp/
>   73 65 6e 64 3a 2f 68 6f  6d 65 2f 69 73 69 64 72 send:/home/isidr
>   6f 2f 44 54 4e 32 2f 64  74 6e 2e 63 6f 6e 66 22 o/DTN2/dtn.conf"
>   68 6f 73 74 3a 2f 2f 74  65 73 74 30 2f 64 74 6e host://test0/dtn
>   63 70 2f 72 65 63 76 3a  2f 2f 64 74 6e 2e 63 6f cp/recv://dtn.co
>   6e 66 0c 68 6f 73 74 3a  2f 2f 74 65 73 74 31 00 nf.host://test1.
>   00 00 0c f3 

Note that since there is no current Internet draft for the bundle
protocol, the actual version number is basically arbitrary. When a new
draft is released (likely with some pretty substantial protocol
changes), this will change accordingly.

I also plan to release an Internet draft describing the TCP
convergence layer protocol as well, sometime in the coming months,
which will document the framing protocol used, which of course may
also change.

-m

Date: Tue, 24 May 2005 14:53:43 +0200
From: Isidro Nistal Garrido <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Packet sniffing
Sender: [email-masked]
Reply-To: [email-masked]

Hi!

        I am having some problems trying to understand the protocol, I am
sniffing the network when I send a file from 1 computer to another and looking
into the tcp packets to the data of them I am not able to recognize the headers
of the internet draft of Bundle protocol Specification September 2004 I am
following. Here is the sequence I got without the TCP headers and in a first
packet that arrives from sender to receiver..

hexadecimal                                         ASCII translation
  01 00 00 00 00 00 00 0d  7a 00 87 13 44 04 02 08 ........z...D...
  00 02 01 01 03 4e 0a c7  bd 42 93 1e 77 00 00 00 .....N...B..w...
  00 05 04 08 69 6e 74 65  72 6e 65 74 32 68 6f 73 ....internet2hos
  74 3a 2f 2f 74 65 73 74  31 2f 64 74 6e 63 70 2f t://test1/dtncp/
  73 65 6e 64 3a 2f 68 6f  6d 65 2f 69 73 69 64 72 send:/home/isidr
  6f 2f 44 54 4e 32 2f 64  74 6e 2e 63 6f 6e 66 22 o/DTN2/dtn.conf"
  68 6f 73 74 3a 2f 2f 74  65 73 74 30 2f 64 74 6e host://test0/dtn
  63 70 2f 72 65 63 76 3a  2f 2f 64 74 6e 2e 63 6f cp/recv://dtn.co
  6e 66 0c 68 6f 73 74 3a  2f 2f 74 65 73 74 31 00 nf.host://test1.
  00 00 0c f3 

So, this should be the primary bundle header, 01 the version and is not so....
from here I don't know how to continue.
Is that the draft is followed to do the reference implementation or I am not
interpreting ok the packet?

Isidro Nistal Garrido
Spanish Exchange Student in Luleå
Tfn: +46 730 583 165

Date: Fri, 20 May 2005 10:15:48 -0700
From: Melissa Ho <[email-masked]>
To: Michael Demmer <[email-masked]>
Subject: Re: [dtn-users] questions regarding DTN2
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

However, it should be possible to create a new router class (as a
subclass of the BundleRouter) to take the source endpoint (or possibly
even the ingress link) into account.

Melissa

On 5/20/05, Michael Demmer <[email-masked]> wrote:
> 
> > i wanted to put bundles on a perticular link based on from where
> > they are coming.  so i just wanted to know whether route command is
> > having that functionality built into it.
> 
> no -- the current implementation of the router only considers the
> destination endpoint, not which link (or source endpoint) the bundle
> arrived on.
> 
> -m
> 
> 
> 
> 
> 
>

Date: Fri, 20 May 2005 08:30:46 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-users] questions regarding DTN2
Sender: [email-masked]
Reply-To: [email-masked]

> i wanted to put bundles on a perticular link based on from where
> they are coming.  so i just wanted to know whether route command is
> having that functionality built into it.

no -- the current implementation of the router only considers the
destination endpoint, not which link (or source endpoint) the bundle
arrived on.

-m

Date: Fri, 20 May 2005 11:23:50 -0400
From: JAy Deshpande <[email-masked]>
To: [email-masked]
Cc: DTN users Group <[email-masked]>
Subject: Re: [dtn-users] questions regarding DTN2
Sender: [email-masked]
Reply-To: [email-masked]

--M9NhX3UHpAaciwkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

hi,

> > 1. is there a way to do ingress/egress  routining with 'route add' comm=
and
> >    that we write in dtn.conf.
>=20
> What do you mean?
i wanted to put bundles on a perticular link based on from where they are c=
oming.
so i just wanted to know whether route command is having that functionality=
 built into
it.

thanx.
JAy
=20

--M9NhX3UHpAaciwkO
Content-Type: application/pgp-signature
Content-Disposition: inline

--M9NhX3UHpAaciwkO--

Date: Fri, 20 May 2005 03:31:11 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked], JAy Deshpande <[email-masked]>
Subject: Re: [dtn-users] questions regarding DTN2
Sender: [email-masked]
Reply-To: [email-masked]

> 1. is there a way to do ingress/egress  routining with 'route add' command
>    that we write in dtn.conf.

What do you mean?

> 
> 2. with -e options, the sender application can ask for end-end ack.
>    my question is that does this ack get interpreted by the sender
>    daemon ( i do'nt konw what the spec says) or is it been supposed to be

Read the spec.  The ack is sent to the reply to address specified in
the bundle. dtnsend will default the replyto to the sender address if
it isn't explicitly specified as an argument

>    forwarded to the sender application. (e.g. the dtnsend)
>    i thought that the ack would be of use to the daemon which actually would
>    store the state info for that session/bundle, rather than the application.

The end-to-end ack is for the benefit of the application sending the
bundle, not the daemon. daemon-to-daemon acks are usually in the
context of custody transfer or handled in the convergence layers.

Melissa

Date: Fri, 20 May 2005 06:25:37 -0400
From: JAy Deshpande <[email-masked]>
To: DTN users Group <[email-masked]>
Subject: [dtn-users] questions regarding DTN2
Sender: [email-masked]
Reply-To: [email-masked]

--GvXjxJ+pjyke8COw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi ,
i am a student working with DTN reference implementation as part=20
of our Course. I have couple of questions.
1. is there a way to do ingress/egress  routining with 'route add' command=
=20
   that we write in dtn.conf.
  =20
2. with -e options, the sender application can ask for end-end ack.
   my question is that does this ack get interpreted by the sender=20
   daemon ( i do'nt konw what the spec says) or is it been supposed to be=
=20
   forwarded to the sender application. (e.g. the dtnsend)=20
   i thought that the ack would be of use to the daemon which actually woul=
d=20
   store the state info for that session/bundle, rather than the applicatio=
n.=20
   please correct me if i am wrong.
 =20
thanx in advance for your help.

JAy

--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature
Content-Disposition: inline

--GvXjxJ+pjyke8COw--

Date: Mon, 16 May 2005 11:09:10 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Custody transfers implementation
Sender: [email-masked]
Reply-To: [email-masked]

Actually I think the dtncpd application should be able to recieve
bundles as files.

Melissa

On 5/16/05, Michael Demmer <[email-masked]> wrote:
> 
> >        I am a student from Lule? university in Sweden and I am working with the
> > DTN2 in my master thesis. We would like to validate a ns-2 simulation of the DTN
> > protocol with the reference implementation. The point is that we would need
> > custody transfer to validate it and we are thinking on implementing ourselves
> > this feature, my question is if there is anything done in this subject or if is
> > there anybody working on that feature.
> 
> There is no implementation (yet) of the custody transfer features of
> the DTN specification. I hope to get that in there sometime this
> summer but we'll see...
> 
> > I have another question about DTN2, when I send large files from one
> > node to another the dtn daemon gives me this error:
> 
> Most likely the problem is that you're trying to receive the bundle
> in-memory and your payload exceeds the maximum size.
> 
> Unfortunately, the dtnrecv application does not (yet) support the
> option to receive payloads as files, although the API does. Following
> the example of the dtnsend application, you can set the
> DTN_PAYLOAD_FILE flag instead of DTN_PAYLOAD_MEM when calling
> dtn_recv. That will put the bundle into a temporary file, and set the
> payload.dtn_bunchde_payload_t_u.filename fields to be the file
> location.
> 
> -m
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Mon, 16 May 2005 11:01:37 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Custody transfers implementation
Sender: [email-masked]
Reply-To: [email-masked]

>        I am a student from Lule? university in Sweden and I am working with the
> DTN2 in my master thesis. We would like to validate a ns-2 simulation of the DTN
> protocol with the reference implementation. The point is that we would need
> custody transfer to validate it and we are thinking on implementing ourselves
> this feature, my question is if there is anything done in this subject or if is
> there anybody working on that feature.

There is no implementation (yet) of the custody transfer features of
the DTN specification. I hope to get that in there sometime this
summer but we'll see...

> I have another question about DTN2, when I send large files from one
> node to another the dtn daemon gives me this error:

Most likely the problem is that you're trying to receive the bundle
in-memory and your payload exceeds the maximum size. 

Unfortunately, the dtnrecv application does not (yet) support the
option to receive payloads as files, although the API does. Following
the example of the dtnsend application, you can set the
DTN_PAYLOAD_FILE flag instead of DTN_PAYLOAD_MEM when calling
dtn_recv. That will put the bundle into a temporary file, and set the
payload.dtn_bunchde_payload_t_u.filename fields to be the file
location.

-m

Date: Mon, 16 May 2005 13:13:13 +0200
From: Isidro Nistal Garrido <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Custody transfers implementation
Sender: [email-masked]
Reply-To: [email-masked]

Sorry about last mail I sent it without all the information.
Hi!

       I am a student from Luleå university in Sweden and I am working with the
DTN2 in my master thesis. We would like to validate a ns-2 simulation of the DTN
protocol with the reference implementation. The point is that we would need
custody transfer to validate it and we are thinking on implementing ourselves
this feature, my question is if there is anything done in this subject or if is
there anybody working on that feature.

       I have another question about DTN2,
when I send large files from one node to another the dtn daemon gives me this error:

dtn% [1116241871.300113 /route info] BUNDLE_RECEIVED id:0 (11244756 of 11244756
bytes)

[1116241897.598712 /registration info] adding registration
10/bundles://internet/host://d26-207.sm.luth.se/aa5

[1116241897.600716 /registration/10 info] enqueue bundle id 0 for delivery to
bundles://internet/host://d26-207.sm.luth.se/aa5

[1116241897.860577 /apisrv error] internal error in xdr: xdr_dtn_bundle_payload_t

[1116241901.489238 /cl/tcp/conn/10.10.0.2:46419 info] connection idle for 31182
milliseconds, closing.

        I have tried to look for xdr_dtn_bundle_payload_t but I don't really
know how does it work or what is failing.

I think that's all right now but I am sure I will come back to you later... see
you soon and thanks a lot in advance.. 

I
Isidro Nistal Garrido
Spanish Exchange Student in Luleå
Tfn: +46 730 583 165

Date: Mon, 16 May 2005 11:40:20 +0200
From: Isidro Nistal Garrido <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Custody transfers implementation
Sender: [email-masked]
Reply-To: [email-masked]

Hi!

       I am a student from Luleå university in Sweden and I am working with the
DTN2 in my master thesis. We would like to validate a ns-2 simulation of the DTN
protocol with the reference implementation. The point is that we would need
custody transfer to validate it and we are thinking on implementing ourselves
this feature, my question is if there is anything done in this subject or if is
there anybody working on that feature.

       I have some questions about DTN2 too
when 

Isidro Nistal Garrido
Spanish Exchange Student in Luleå
Tfn: +46 730 583 165

Date: Mon, 2 May 2005 12:44:39 -0500
From: Jeff Wilson <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-users] Fwd: overriding ConvergenceLayer "del_interface"
Sender: [email-masked]
Reply-To: [email-masked]

If I'd just waited two more minutes before sending ...

I kept digging, and I found the del() function in InterfaceTable ... I
added the following at line 125 (right after "iface=*iter"):

cl->del_interface(iface);

Now my /cl/tcp message shows up and the
TCPConvergenceLayer::del_interface() actions fire as expected ...

        regards,
          jw

---------- Forwarded message ----------
From: Jeff Wilson <[email-masked]>
Date: May 2, 2005 12:37 PM
Subject: overriding ConvergenceLayer "del_interface"
To: [email-masked]

Experimenting with TCPConvergenceLayer, I added the line

        log_info("del_interace");

just before "Listener* listener = (Listener*)iface->cl_info();"
(around line 225).  When I run dtnd, I expect to see that message pop
up after I enter the command,

        interface del tcp host://0.0.0.0:5000/

but it never shows.  Instead I get

       [1115054924.809688 /interface info] removing interface tcp
host://0.0.0.0:5000/

Why didn't I get a message from "/cl/tcp" about removing that
interface?  Is that a bug?  Or is there something going on there, that
I don't understand ...

       thanks for your time,
        jw

Date: Mon, 2 May 2005 12:37:05 -0500
From: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: [dtn-users] overriding ConvergenceLayer "del_interface"
Sender: [email-masked]
Reply-To: [email-masked]

Experimenting with TCPConvergenceLayer, I added the line

        log_info("del_interace");

just before "Listener* listener = (Listener*)iface->cl_info();"
(around line 225).  When I run dtnd, I expect to see that message pop
up after I enter the command,

        interface del tcp host://0.0.0.0:5000/

but it never shows.  Instead I get 

       [1115054924.809688 /interface info] removing interface tcp
host://0.0.0.0:5000/

Why didn't I get a message from "/cl/tcp" about removing that
interface?  Is that a bug?  Or is there something going on there, that
I don't understand ...

       thanks for your time,
        jw