Subject: Re: [dtn-users] Should I Expect A Failure?
From: "Ricardo Martins" <[email-masked]>
To: "Andy Scott" <[email-masked]>
Cc: [email-masked]
Date: Fri, 28 Nov 2008 23:05:39 +0000
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>

Hi,

This and other issues are already fixed in the latest revisions of
DTN's mercurial repository.

Regards,
Ricardo Martins

2008/11/28 Andy Scott <[email-masked]>:
> Hi All
>
> Just downloaded the source (plus required other packages) for v2.6.0
> to Ubuntu and I am seeing a build error in SequenceID.cc in the
> include of oasys/util/SafeRange.h
>
>  size_t is not defined which is the root problem.
>
> Made the 1-line fix to get it past this issue and it builds no problems.
>
> I have now "downloaded" the bleeding edge stuff to try out - which I
> guess has this issue well and truly resolved as it seems to be
> building OK as I type this.
>
> My question is: is the error I encountered known or is it indicative
> of a bust install of G++ &c?
>
> (I am also searching the posting archive - but my connection is slow
> and my find kung fu weak)
>
> Thanks for any replies and look forward to getting into this stuff
> some more it looks so cool.
>
> Andy
> --
> Brain upgrade required: a working hypothalamus
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>

Date: Fri, 28 Nov 2008 20:31:23 +0000
From: "Andy Scott" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Should I Expect A Failure?

Hi All

Just downloaded the source (plus required other packages) for v2.6.0
to Ubuntu and I am seeing a build error in SequenceID.cc in the
include of oasys/util/SafeRange.h

 size_t is not defined which is the root problem.

Made the 1-line fix to get it past this issue and it builds no problems.

I have now "downloaded" the bleeding edge stuff to try out - which I
guess has this issue well and truly resolved as it seems to be
building OK as I type this.

My question is: is the error I encountered known or is it indicative
of a bust install of G++ &c?

(I am also searching the posting archive - but my connection is slow
and my find kung fu weak)

Thanks for any replies and look forward to getting into this stuff
some more it looks so cool.

Andy
-- 
Brain upgrade required: a working hypothalamus

From: Darren Long <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Fri, 28 Nov 2008 17:24:42 +0000
Subject: Re: [dtn-users] Various questions about the DTN reference implementation

On 28 Nov 2008, at 16:23, Michael Demmer wrote:

> 3) Is it possible to use multiple routing systems at once with DTN2?  
> For
> instance, consider a large group of devices in an ad-hoc network,  
> but with
> one or more of their number connected to fixed WANs. It would make  
> sense to
> use something like LSR to route within the ad-hoc network, but the  
> 'boundary
> nodes' would need to have LSR *and* possibly some static or name- 
> lookup-based
> routing system for the WAN at the same time. Glancing through the  
> sources
> gave the strong impression that only one routing approach could be  
> used at a
> time.
>
> Unfortunately not at this time. This was something we've considered  
> for a while but never got around to implementing properly.

I'm pretty sure it is possible (or at least was possible)  to add  
static routes when using DTLSR.

Darren

Date: Fri, 28 Nov 2008 08:23:25 -0800
From: "Michael Demmer" <[email-masked]>
Sender: [email-masked]
To: "Peter TB Brett" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] Various questions about the DTN reference implementation

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

>
> Hi all,
>
> I'm just getting started with the DTN2 impl., and have a few questions
> arising
> from reading the documentation. I'm more than happy to collate any answers
> and wikify them for someone to add to dtnrg.org.
>
> 1) I note that the implementation supports a number of different endpoint
> schema, but I couldn't find any documentation as to the purpose of each.

Unfortunately that's because none exists. Most of my work has been with the
standard 'dtn:' scheme though.

> 2) It would be useful to be able to run multiple (3-10) agents on a single
> system in order to test DTN applications in an automated fashion in a
> controlled environment. I note that this is entirely possible (just by
> setting different ports to listen on for each agent), but was wondering if
> anyone was willing to share tips or even management scripts for setting up
> and managing a set of dtnd instances.

We've written a tcl based infrastructure that does a bunch of this. The
basic model is that you write a tcl script that defines your test and then
can interact with running daemons. It also has a framework for writing a
topology that can either be implemented by running a bunch of daemons on one
host (listening on diff't ports) or using a set of test machines.

You can get the base infrastructure here:
hg clone http://dtn.sourceforge.net/hg/test-utils

DTN-specific test utilities are in DTN2/test-utils and example test scripts
are in DTN2/test.

You need to clone the test-utils repository in the same directory as DTN2.

Then as an example, cd into DTN2 and run:

test-utils/run-dtn.tcl test/send-one-bundle.tcl

That should get you going with one functional example.

3) Is it possible to use multiple routing systems at once with DTN2? For
> instance, consider a large group of devices in an ad-hoc network, but with
> one or more of their number connected to fixed WANs. It would make sense to
> use something like LSR to route within the ad-hoc network, but the
> 'boundary
> nodes' would need to have LSR *and* possibly some static or
> name-lookup-based
> routing system for the WAN at the same time. Glancing through the sources
> gave the strong impression that only one routing approach could be used at
> a
> time.

Unfortunately not at this time. This was something we've considered for a
while but never got around to implementing properly.

> 4) Does anyone have any example code for a simple external convergence
> layer
> that they would be willing to share, please?

I don't.

5) Would the maintainers be willing to apply a patch for libdtnapi which
> adds
> API for DTN applications to specify the dtnd address/port other than by
> environment variable?

Since I'm no longer a maintainer, I can't say specifically, but my guess
would be that's no problem as long as it remains backwards-compatible.

-m

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

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
I&#39;m just getting started with the DTN2 impl., and have a few questions arising<br>
from reading the documentation. I&#39;m more than happy to collate any answers<br>
and wikify them for someone to add to <a href="http://dtnrg.org/" target="_blank">dtnrg.org</a>.<br>
<br>
1) I note that the implementation supports a number of different endpoint<br>
schema, but I couldn&#39;t find any documentation as to the purpose of each.</blockquote><div><br>Unfortunately that&#39;s because none exists. Most of my work has been with the standard &#39;dtn:&#39; scheme though. <br>

</div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2) It would be useful to be able to run multiple (3-10) agents on a single<br>

system in order to test DTN applications in an automated fashion in a<br>
controlled environment. I note that this is entirely possible (just by<br>
setting different ports to listen on for each agent), but was wondering if<br>
anyone was willing to share tips or even management scripts for setting up<br>
and managing a set of dtnd instances.</blockquote><div><br>We&#39;ve
written a tcl based infrastructure that does a bunch of this. The basic
model is that you write a tcl script that defines your test and then
can interact with running daemons. It also has a framework for writing
a topology that can either be implemented by running a bunch of daemons
on one host (listening on diff&#39;t ports) or using a set of test machines.<br>
<br>You can get the base infrastructure here:<br>hg clone <a href="http://dtn.sourceforge.net/hg/test-utils" target="_blank">http://dtn.sourceforge.net/hg/test-utils</a><br><br>DTN-specific test utilities are in DTN2/test-utils and example test scripts are in DTN2/test.<br>

<br>You need to clone the test-utils repository in the same directory as DTN2.<br><br>Then as an example, cd into DTN2 and run:<br><br>test-utils/run-dtn.tcl test/send-one-bundle.tcl<br><br>That should get you going with one functional example.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) Is it possible to use multiple routing systems at once with DTN2? For<br>
instance, consider a large group of devices in an ad-hoc network, but with<br>
one or more of their number connected to fixed WANs. It would make sense to<br>
use something like LSR to route within the ad-hoc network, but the &#39;boundary<br>
nodes&#39; would need to have LSR *and* possibly some static or name-lookup-based<br>
routing system for the WAN at the same time. Glancing through the sources<br>
gave the strong impression that only one routing approach could be used at a<br>
time.</blockquote><div><br>Unfortunately not at this time. This was something we&#39;ve considered for a while but never got around to implementing properly.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

4) Does anyone have any example code for a simple external convergence layer<br>
that they would be willing to share, please?</blockquote><div><br>I don&#39;t.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

5) Would the maintainers be willing to apply a patch for libdtnapi which adds<br>
API for DTN applications to specify the dtnd address/port other than by<br>
environment variable?</blockquote><div><br>Since
I&#39;m no longer a maintainer, I can&#39;t say specifically, but my guess
would be that&#39;s no problem as long as it remains backwards-compatible.<br><br>-m <br></div>
<br>

------=_Part_64730_27869525.1227889405034--

From: Peter TB Brett <[email-masked]>
Organization: Integral Informatics Ltd
To: [email-masked]
Date: Thu, 27 Nov 2008 11:41:47 +0000
Subject: [dtn-users] Various questions about the DTN reference implementation

--nextPart1417671.9uZFBVeFHs
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all,

I'm just getting started with the DTN2 impl., and have a few questions aris=
ing=20
from reading the documentation. I'm more than happy to collate any answers=
=20
and wikify them for someone to add to dtnrg.org.

1) I note that the implementation supports a number of different endpoint=20
schema, but I couldn't find any documentation as to the purpose of each.

2) It would be useful to be able to run multiple (3-10) agents on a single=
=20
system in order to test DTN applications in an automated fashion in a=20
controlled environment. I note that this is entirely possible (just by=20
setting different ports to listen on for each agent), but was wondering if=
=20
anyone was willing to share tips or even management scripts for setting up=
=20
and managing a set of dtnd instances.

3) Is it possible to use multiple routing systems at once with DTN2? For=20
instance, consider a large group of devices in an ad-hoc network, but with=
=20
one or more of their number connected to fixed WANs. It would make sense to=
=20
use something like LSR to route within the ad-hoc network, but the 'boundar=
y=20
nodes' would need to have LSR *and* possibly some static or name-lookup-bas=
ed=20
routing system for the WAN at the same time. Glancing through the sources=20
gave the strong impression that only one routing approach could be used at =
a=20
time.

4) Does anyone have any example code for a simple external convergence laye=
r=20
that they would be willing to share, please?

5) Would the maintainers be willing to apply a patch for libdtnapi which ad=
ds=20
API for DTN applications to specify the dtnd address/port other than by=20
environment variable?

I'm sure there will be other questions later. I'm perfectly willing to=20
take, "You dummy! This is all clearly documented at <URL>!" as an answer. ;)

                                         Peter

=2D-=20
Peter Brett

Cambridge University Engineering Department

--nextPart1417671.9uZFBVeFHs
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1417671.9uZFBVeFHs--

From: "Burleigh, Scott C" <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Sat, 22 Nov 2008 12:07:30 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] ION and DTN2

Right, you'll need an "a scheme" line in your bprc file for "dtn", and you'll want to run dtnadmin at startup to configure your routes -- for now, ION only supports static routing for "dtn" endpoints.  (Actually, you can omit the "ipn" scheme altogether if you're only going to be talking to "dtn" endpoints.)

The guys at Ohio U. can give you a lot better help on your make problem than I could.

Scott

> -----Original Message-----
> From: Darren Long [mailto:[email-masked]]
> Sent: Saturday, November 22, 2008 11:35 AM
> To: Burleigh, Scott C
> Cc: dtn-users mailing list
> Subject: Re: [dtn-users] ION and DTN2
>
> Thanks Scott,  I'd pretty much drawn the same conclusion myself just
> now after watching them trying to talk TCP.
>
> I guess I just need to add a an induct and outducts for udpcli/udpclo,
> and a section in the for dtnadmin for the schema and some routes.  I'm
> a bit unsure about adding contacts to the ipnadmin section, and wonder
> if using dtn schema addresses will work as well as ipn ones.
>
> I guess I'll find out though.  Oh, I'm also having a problem getting
> it to run on my OSX 10.5 system, make test fails with shared memory
> problems.  it seems to think its not a MACOSX machine.
>
> Darren
>
> On 22 Nov 2008, at 19:02, Burleigh, Scott C wrote:
>
> > Hi, Darren.  ION and DTN2 are indeed interoperable (or at least they
> > were as of the November 2007 IETF), but not via the TCP-CL.  ION
> > does have a TCP convergence-layer adapter implemented, but it's much
> > simpler than the DTN2 TCP-CL because it doesn't try to support
> > reactive fragmentation; support for the standard TCP-CL has been
> > implemented, but it's not part of the ION distribution yet.  To get
> > ION and DTN2 interoperating you currently have to use the UDP
> > convergence layer support built into both implementations.
> >
> > In the ION distribution there should be a "configs" directory
> > containing some sample ION configuration files.  They'd need to be
> > tweaked for what you want to do, though, as none of them use the raw
> > UDP convergence layer.
> >
> > I don't know much about the DTN2 apps, but if there's something that
> > just prints text messages that arrive in bundles destined for
> > whatever endpoint it opens then it should be able to receive and
> > print what bpsource sends.  Alternatively, maybe you could open
> > bpsink on a given endpoint and use a DTN2 bundle source app to send
> > text to it?
> >
> > Scott
> >
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:dtn-
> >> users-
> >>> [email-masked]] On Behalf Of Darren Long
> >>> Sent: Saturday, November 22, 2008 10:22 AM
> >>> To: dtn-users mailing list
> >>> Subject: [dtn-users] ION and DTN2
> >>>
> >>> Hi all,
> >>>
> >>> I've just started dabbling with ION and have been going through the
> >>> tutorials.
> >>>
> >>> I note that it is (or at least was) shown to be interoperable with
> >>> DTN2 with the TCP-CL, so I wondered if anyone has any tips  or some
> >> rc
> >>> file extracts for setting up an ION to DTN2 gateway using TCP-CL
> >>> assuming an on-demand or always on link into a dtnd and handling
> the
> >>> mix of ipn and dtn schemas.
> >>>
> >>> I also suspect that the apps in the two implementations won't talk,
> >>> having just tried to use bpsource to send to a dtn:// EID, so I
> >>> suspect my best bet is to route between two DTN2 based sub-nets
> over
> >>> an IPN  sub-net, with a pair of gateways.
> >>>
> >>> Cheers,
> >>>
> >>> Darren
> >>> _______________________________________________
> >>> dtn-users mailing list
> >>> [email-masked]
> >>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
> >
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: Darren Long <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Date: Sat, 22 Nov 2008 19:35:28 +0000
Cc: dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-users] ION and DTN2

Thanks Scott,  I'd pretty much drawn the same conclusion myself just  
now after watching them trying to talk TCP.

I guess I just need to add a an induct and outducts for udpcli/udpclo,  
and a section in the for dtnadmin for the schema and some routes.  I'm  
a bit unsure about adding contacts to the ipnadmin section, and wonder  
if using dtn schema addresses will work as well as ipn ones.

I guess I'll find out though.  Oh, I'm also having a problem getting  
it to run on my OSX 10.5 system, make test fails with shared memory  
problems.  it seems to think its not a MACOSX machine.

Darren

On 22 Nov 2008, at 19:02, Burleigh, Scott C wrote:

> Hi, Darren.  ION and DTN2 are indeed interoperable (or at least they  
> were as of the November 2007 IETF), but not via the TCP-CL.  ION  
> does have a TCP convergence-layer adapter implemented, but it's much  
> simpler than the DTN2 TCP-CL because it doesn't try to support  
> reactive fragmentation; support for the standard TCP-CL has been  
> implemented, but it's not part of the ION distribution yet.  To get  
> ION and DTN2 interoperating you currently have to use the UDP  
> convergence layer support built into both implementations.
>
> In the ION distribution there should be a "configs" directory  
> containing some sample ION configuration files.  They'd need to be  
> tweaked for what you want to do, though, as none of them use the raw  
> UDP convergence layer.
>
> I don't know much about the DTN2 apps, but if there's something that  
> just prints text messages that arrive in bundles destined for  
> whatever endpoint it opens then it should be able to receive and  
> print what bpsource sends.  Alternatively, maybe you could open  
> bpsink on a given endpoint and use a DTN2 bundle source app to send  
> text to it?
>
> Scott
>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>> users-
>>> [email-masked]] On Behalf Of Darren Long
>>> Sent: Saturday, November 22, 2008 10:22 AM
>>> To: dtn-users mailing list
>>> Subject: [dtn-users] ION and DTN2
>>>
>>> Hi all,
>>>
>>> I've just started dabbling with ION and have been going through the
>>> tutorials.
>>>
>>> I note that it is (or at least was) shown to be interoperable with
>>> DTN2 with the TCP-CL, so I wondered if anyone has any tips  or some
>> rc
>>> file extracts for setting up an ION to DTN2 gateway using TCP-CL
>>> assuming an on-demand or always on link into a dtnd and handling the
>>> mix of ipn and dtn schemas.
>>>
>>> I also suspect that the apps in the two implementations won't talk,
>>> having just tried to use bpsource to send to a dtn:// EID, so I
>>> suspect my best bet is to route between two DTN2 based sub-nets over
>>> an IPN  sub-net, with a pair of gateways.
>>>
>>> Cheers,
>>>
>>> Darren
>>> _______________________________________________
>>> dtn-users mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: "Burleigh, Scott C" <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Sat, 22 Nov 2008 11:02:50 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] ION and DTN2

Hi, Darren.  ION and DTN2 are indeed interoperable (or at least they were as of the November 2007 IETF), but not via the TCP-CL.  ION does have a TCP convergence-layer adapter implemented, but it's much simpler than the DTN2 TCP-CL because it doesn't try to support reactive fragmentation; support for the standard TCP-CL has been implemented, but it's not part of the ION distribution yet.  To get ION and DTN2 interoperating you currently have to use the UDP convergence layer support built into both implementations.

In the ION distribution there should be a "configs" directory containing some sample ION configuration files.  They'd need to be tweaked for what you want to do, though, as none of them use the raw UDP convergence layer.

I don't know much about the DTN2 apps, but if there's something that just prints text messages that arrive in bundles destined for whatever endpoint it opens then it should be able to receive and print what bpsource sends.  Alternatively, maybe you could open bpsink on a given endpoint and use a DTN2 bundle source app to send text to it?

Scott

> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-
> users-
> > [email-masked]] On Behalf Of Darren Long
> > Sent: Saturday, November 22, 2008 10:22 AM
> > To: dtn-users mailing list
> > Subject: [dtn-users] ION and DTN2
> >
> > Hi all,
> >
> > I've just started dabbling with ION and have been going through the
> > tutorials.
> >
> > I note that it is (or at least was) shown to be interoperable with
> > DTN2 with the TCP-CL, so I wondered if anyone has any tips  or some
> rc
> > file extracts for setting up an ION to DTN2 gateway using TCP-CL
> > assuming an on-demand or always on link into a dtnd and handling the
> > mix of ipn and dtn schemas.
> >
> > I also suspect that the apps in the two implementations won't talk,
> > having just tried to use bpsource to send to a dtn:// EID, so I
> > suspect my best bet is to route between two DTN2 based sub-nets over
> > an IPN  sub-net, with a pair of gateways.
> >
> > Cheers,
> >
> > Darren
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: Darren Long <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Sat, 22 Nov 2008 18:22:28 +0000
Subject: [dtn-users] ION and DTN2

Hi all,

I've just started dabbling with ION and have been going through the  
tutorials.

I note that it is (or at least was) shown to be interoperable with  
DTN2 with the TCP-CL, so I wondered if anyone has any tips  or some rc  
file extracts for setting up an ION to DTN2 gateway using TCP-CL  
assuming an on-demand or always on link into a dtnd and handling the  
mix of ipn and dtn schemas.

I also suspect that the apps in the two implementations won't talk,  
having just tried to use bpsource to send to a dtn:// EID, so I  
suspect my best bet is to route between two DTN2 based sub-nets over  
an IPN  sub-net, with a pair of gateways.

Cheers,

Darren 

Date: Thu, 20 Nov 2008 21:06:22 +0000
From: "Ricardo Martins" <[email-masked]>
To: "Christopher Small" <[email-masked]>
Cc: dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-users] getting dtn2 to build on Ubuntu 8.10 (really gcc 4.3.2)

Hi,

Usually something like "gcc -dumpversion | cut -f1-2 -d" does the
trick to get the relevant version of gcc (or g++).
I've sent you the dump files of 9 gcc versions as requested.

Regards,
Ricardo Martins

2008/11/18 Christopher Small <[email-masked]>:
> DTN2 does not build out-of-the-box on a stock Ubuntu 8.10 machine. I've
> got some candidate fixes, and to see if I've done the right thing it
> would be helpful to get a small amount of data from a large variety of
> machines.
>
> If you would be so kind as to email me (and not the entire list) the
> output of "gcc -v" and "g++ -v" on your machine (Mac, Linux, BSD,
> Cygwin, ...) I would be very grateful.
>
> running the following should do the job, if you have mail configured on
> your machine.
>
> $ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1) | mail [email-masked]
>
> Otherwise running the following, followed by a cut-and-paste into a mail
> composition window, should work.
>
> $ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1)
>
> Thanks.
>
> - Chris
>
> --
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research                           617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>

Date: Tue, 18 Nov 2008 17:13:50 -0500
From: Christopher Small <[email-masked]>
To: dtn-users mailing list <[email-masked]>
OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB
Subject: [dtn-users] getting dtn2 to build on Ubuntu 8.10 (really gcc 4.3.2)

DTN2 does not build out-of-the-box on a stock Ubuntu 8.10 machine. I've
got some candidate fixes, and to see if I've done the right thing it
would be helpful to get a small amount of data from a large variety of
machines.

If you would be so kind as to email me (and not the entire list) the
output of "gcc -v" and "g++ -v" on your machine (Mac, Linux, BSD,
Cygwin, ...) I would be very grateful.

running the following should do the job, if you have mail configured on
your machine.

$ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1) | mail [email-masked]

Otherwise running the following, followed by a cut-and-paste into a mail
composition window, should work.

$ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1)

Thanks.

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Date: Mon, 17 Nov 2008 11:02:08 -0800
From: "Michael Demmer" <[email-masked]>
Sender: [email-masked]
To: "Kurtis Heimerl" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] [dtn-interest] Bundle Protocol question

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

Are you sure you're correctly decoding the flags part of the block?

Briefly, each block should be a 1 byte typecode, then a flags SDNV, then if
there are any EID references in the block, the vector of EIDs (but there
shouldn't be in the paylod) then the block length SDNV, then the block data.

In the DTN2 reference code, this is constructed in
BlockProcessor::generate_preamble -- is there something there that you're
not understanding?
-m

On Sun, Nov 16, 2008 at 11:29 PM, Kurtis Heimerl <[email-masked]
> wrote:

> Hello again DTN-interest! I've made great strides on the python DTN
> implementation, and can send and receive smaller bundles over the
> TCPCL.
>
> I've begun work on allowing for larger files. For small files, the
> implementation was allowed to strip off the type, flags and length
> fields from the Bundle Payload block and assume the rest is payload.
> However, as the payload gets larger, this fails.
>
> I need a field that indicates the length of the payload, but it turns
> out that the block length field of the Bundle payload block isn't
> anything obviously correct. It seems to return 8 if the bundle is
> small and 4096 if large. It doesn't depend on the length of the
> payload, that much I'm certain about. This means either I'm
> incorrectly decoding this variable, which I find unlikely due to the
> correctness of the rest of the fields, or it's not what I thought it
> was. Where am I supposed to get this length?
>
> Also, are any of the DTN implementations more readable than the
> reference of symbian implementations? It's hard to parse those, so a
> simpler version might lead me to unblocking myself more often.
>
> Thanks!
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

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

Are you sure you&#39;re correctly decoding the flags part of the block?<br><br>Briefly, each block should be a 1 byte typecode, then a flags SDNV, then if there are any EID references in the block, the vector of EIDs (but there shouldn&#39;t be in the paylod) then the block length SDNV, then the block data.<br>
<br>In the DTN2 reference code, this is constructed in BlockProcessor::generate_preamble -- is there something there that you&#39;re not understanding? <br>-m <br><br><div class="gmail_quote">On Sun, Nov 16, 2008 at 11:29 PM, Kurtis Heimerl <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello again DTN-interest! I&#39;ve made great strides on the python DTN<br>
implementation, and can send and receive smaller bundles over the<br>
TCPCL.<br>
<br>
I&#39;ve begun work on allowing for larger files. For small files, the<br>
implementation was allowed to strip off the type, flags and length<br>
fields from the Bundle Payload block and assume the rest is payload.<br>
However, as the payload gets larger, this fails.<br>
<br>
I need a field that indicates the length of the payload, but it turns<br>
out that the block length field of the Bundle payload block isn&#39;t<br>
anything obviously correct. It seems to return 8 if the bundle is<br>
small and 4096 if large. It doesn&#39;t depend on the length of the<br>
payload, that much I&#39;m certain about. This means either I&#39;m<br>
incorrectly decoding this variable, which I find unlikely due to the<br>
correctness of the rest of the fields, or it&#39;s not what I thought it<br>
was. Where am I supposed to get this length?<br>
<br>
Also, are any of the DTN implementations more readable than the<br>
reference of symbian implementations? It&#39;s hard to parse those, so a<br>
simpler version might lead me to unblocking myself more often.<br>
<br>
Thanks!<br>
_______________________________________________<br>
dtn-interest mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest" target="_blank">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>
</blockquote></div><br>

------=_Part_46660_4477137.1226948528789--

Date: Thu, 13 Nov 2008 15:06:12 +0200
From: "Shengye Lu" <[email-masked]>
To: "DTN Users" <[email-masked]>
Subject: [dtn-users] about encoding mechanism of DTN Reference implementation

Hi,

I am doing packet eavesdropping test for DTN application which is
based on DTN 2.4.
As we know,  DTN application API is on IPC client side, while DTNd
sits on IPC server side. I use Wireshark to capture packets between
application API  and DTNd.
Obviously, if I use Wireshark to capture packets among DTNds,
Wireshark can't decode the packets, since Wireshark does not recognize
BP. But my testing indicates: Wireshark can partly decode packets
between application API  and DTNd.

I want to know: does Application API use the same encoding mechanism
as DTNd?  What encoding mechanism does DTN application API use?

Cheers,
-- 
Shengye

From: Elwyn Davies <[email-masked]>
To: Lloyd Wood <[email-masked]>
Organization: Folly Consulting
Date: Thu, 13 Nov 2008 11:34:16 +0000
Cc: DTN interest <[email-masked]>, [email-masked]
Subject: Re: [dtn-users] [Fwd: Re: Oasys 1.3.0 does not compile on Cygwin]

Hi, Lloyd.

On Wed, 2008-11-12 at 21:45 +0000, Lloyd Wood wrote:
> Elwyn,
> 
> Previous list discussion of Cygwin stalled at the d_type problem.  
> Appears you've found a simple workaround and found that d_type use is  
> not essential to the dtn code.
Right!  Cheap hack.
> 
> My take is that you're already over the hard part for getting the dtn  
> code to run, at least - but though cygwin can be convenient, it's  
> rarely preferable for development, and not good for networking work  
> (no multicast, no IPv6) or anything that stresses the filesystem  
> (slow, weirdness in mapping unix behaviour to windows, odd piping  
> behaviour too.)
The original intention was just to get it up and running to  provide me
with a couple of extra testing nodes 'for free'.  Well, TANSTAAFL!!!

Anyway after a deal of head scratching I now have runnable executables.
Whether they do what I need is the next question.  I have sent a message
to the users list documenting what I had to do. And it has provided me
with a chance to run around the code a little.

I'll discuss getting some patches in with Michael (possibly in
Minneapolis).
> 
> If you're familiar with Cygwin's weirdnesses, fine -- if not, you'll  
> be wondering if the behaviour you see is due to the program, or to  
> running the program on cygwin.
Thanks for the warning!  At the moment I only want very simple
behaviour, so I'll see if it can provide.  I don't intend to do any
development on Cygwin anyway. I have Linux for that!

Cheers,
Elwyn 
> 
> cheers,
> 
> L.
> 
> On 12 Nov 2008, at 21:13, Folly Consulting wrote:
> 
> > Stephen Farrell suggested the attached message might be usefully  
> > seen on
> > the users list.
> >
> > Just to continue.  Having got oasys to compile I tried DTN 2.6.0.  It
> > appears it has a similar number of minor problems, plus a problem with
> > getting the linkage right between the xdr routines and the C++.  the
> > applib is currently refusing to link.
> >
> > However in the light of Michael's comments below, it is not clear
> > whether there is any point in continuing.  Maybe some sort of caveat
> > ought to be added to the buiklding instructions or in the wiki - the
> > manual currently implies that it can be built for Cygwin and there are
> > clearly significant problems to sort out.. which may be intractable.
> >
> > Regards,
> > Elwyn Davies
> >
> > -------- Original Message --------
> > Subject: 	Re: Oasys 1.3.0 does not compile on Cygwin
> > Date: 	Wed, 12 Nov 2008 11:38:01 -0800
> > From: 	Michael Demmer <[email-masked]>
> > To: 	Elwyn Davies <[email-masked]>
> > CC: 	Delay Tolerant Networking Interest List
> > <[email-masked]>
> > References: 	<[email-masked]>
> >
> >
> >
> > Yes. There have been cygwin incompatibilities for some time. From what
> > I remember, getting things to compile in cygwin is a bit of a pain but
> > not fundamentally a challenge, however there was something more
> > fundamental in the threading and IO model that caused things to break
> > in cygwin. That may have been fixed with a newer version of cygwin,
> > but I haven't tried for some time.
> >
> > Also, I began an effort to port the code to use the Apache Portable
> > Runtime (APR) which would mean that the system could run natively on
> > either UNIX or Windows platforms. That work is currently checked in
> > under the apr-port branch.
> >
> > -mike
> >
> > On Wed, Nov 12, 2008 at 6:34 AM, Elwyn Davies  
> > <[email-masked]> wrote:
> >> Hi.
> >>
> >> I have been trying to compile DTN2 v2.6.0 and Oasys v1.3.0 on  
> >> Windows XP
> >> SP2/Cygwin (version 1.5.25-15)
> >>
> >> There are 4 problems (so far):
> >> io/FileUtils.cc:  rm_all_from_dir function does not compile because  
> >> the
> >> 'dirent structure does not contain 'd_type' on Cygwin (line 133).   
> >> This
> >> field is only used when the 'recursive' flag is set - this isn't  
> >> used in
> >> dtn, so commenting out the test for recursive delete  provides a  
> >> workaround.
> >>
> >> io/TTY.h:  Lines 36-39:  cfgetispeed and  cfgetospeed are defined as
> >> preprocessor macros in sys/termios.h rather than global functions.
> >> Consequently both the declarations and the functions that use them in
> >> FileUtils.cc do not compile.  AFAIK these functions are not used.  I
> >> commented out the functions and the declarations to allow it to  
> >> compile.
> >>
> >> io/TTY.h (Line 40) and ioTTY.cc(lines 96-101): There is no function
> >> cfmakeraw in Cygwin.  hence the wrapper will not compile.  In order  
> >> to
> >> support
> >> the standard DTN code, we need to define TTY::cfmakeraw() as a No- 
> >> op in
> >> oasys for cygwin.
> >>
> >> Makefile:  'make install' fails.The shell script executed for the  
> >> target
> >> 'installlibs' (lines 305-419) is not good 'bash' code.   The   
> >> '[' (test)
> >> commends fail because the equality operator is '==' rather than '='  
> >> and
> >> the $DESTDIR argument needs to be enclosed in double quotes to  
> >> cater for
> >> the empty string case (as is the default).  Also the SHLIB_EXT  
> >> variable
> >> doesn't seem to be defined.  the following fragment works (if  
> >> SHLIB_EXT
> >> := a is added):
> >>
> >> installlib: installdirs
> >>    [ "$(DESTDIR)" == . ] || \
> >>    [ x$(SHLIBS) == x ] || \
> >>    for lib in lib/liboasys-$(OASYS_VERSION).$(SHLIB_EXT) \
> >>               lib/liboasyscompat-$(OASYS_VERSION).$(SHLIB_EXT) ; do \
> >>        ($(INSTALL_PROGRAM) $$lib $(DESTDIR)$(libdir)) ; \
> >>    done
> >>
> >>    [ "$(DESTDIR)" == . ] || \
> >>    for lib in liboasys liboasyscompat ; do \
> >>          (cd $(DESTDIR)$(libdir) && rm -f $$lib.$(SHLIB_EXT) && \
> >>           ln -s $$lib-$(OASYS_VERSION).$(SHLIB_EXT) $$lib.$ 
> >> (SHLIB_EXT)) \
> >>    done
> >>
> >>
> >> There are problems with DTN as well.. I will report these separately.
> >>
> >> Regards,
> >> Elwyn
> >>
> >
> >
> >
> > -- 
> > --------------------------------------------------------------------------
> > Folly Consulting Ltd, 60 The Butts, Soham, Ely, Cambridgeshire, CB7  
> > 5AW
> > Company number 6238664: Registered in the UK
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-users
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 

From: Elwyn Davies <[email-masked]>
To: DTN Users <[email-masked]>
Organization: Folly Consulting
Date: Thu, 13 Nov 2008 11:24:50 +0000
Subject: [dtn-users] Problems compiling DTN 2.6.0 on Cygwin (and fixes)

In addition to the problems reported with oasys v1.3.0, there are also
problems with compiling DTN v2.6.0 on Windows XP SP2/Cygwin 1.5.25-15.

util/SafeRange.h:  This header uses size_t.  This should probably pull
in the stddef.h file supplied with the compiler for the environment
automatically.  For example this does happen on Gentoo Linux 2.6.25/gcc
4.1.2.  However it does not seem to happen on Cygwin which uses a
'special' version of gcc 3.4.4.  Adding two lines to the file before the
start of the template fixes the problem:
#define __need_size_t
#include <stddef.h>
There is no need to specify additional include directories.  stddef.h is
buried in the compiler directories
- /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/stddef.h on my Linux
build and /usr/libgcc/i686-pc-cygwin/3.4.4/include/stddef.h on Cygwin.

servlib/routing/ExternalRouter.cc:  This file does not compile because
the Cygwin header netinet/in.h doesn't contain a definition of
INADDR_ALLRTRS_GROUP.  Adding the requisite #define after including
netinet/in.h solves the problem:
#ifdef __CYGWIN__
#define INADDR_ALLRTRS_GROUP ((inaddr_t) 0xE0000002)  /* 224.0.0.2 */
#endif

conv_layers/SerialConvergence.cc:  There aren't any actual problems in
this file - they are masked by fixing up the Oasys TTY.h/TTY.cc to
provide a no-op cfmakeraw function - Windows doesn't have the concept of
raw/cooked serial lines.  (TTY.* are also fixed up to deal with some
other issues with Cygwin termios definitions but they aren't relevant to
DTN.)

Applib is the source of most of the grief in sorting out Cygwin. The
basic cause of the problems is that the XDR library routines used to
marshal/unmarshal the basic types in the code that is created by rpcgen
have archaic Kernigan and Ritchie (K&R) style definitions
in /usr/include/rpc/xdr.h (definitions of xdr_<typename> routines).
Mostly this is not a problem.  Almost all the calls to these routines
are made in C code in dtn_types_xdr.c, where they do not cause any
problems. However applib/APIServer.cc contains one call to xdr_u_int
(line 1604).  This call has two parameters (as it should) but is seen by
g++ as conflicting with the K&R definition which implies no parameters.

The fix is to define a C function xdr_u_int_ with a proper prototype and
a macro  which maps xdr_u_int -> xdr_u_int_ in APIServer.cc.  This
involves providing the prototype and macro definitions in
oasys/compat/rpc.h and the declaration of the function should go in
oasys/compat/rpc_compat.c - this is just a wrapper that calls the
standard xdr_u_int.

I also believe that applib/sdnv-c.c needs to include
oasys/oasys-config.h to keep one of the other header files in
bundling/SDNV.cc happy.

Finally  there are a couple of Makefile problems.  
1. The calls to the xdr_<type> functions are all in functions that are
parcelled up into libdtnapi libraries which appear in the (static)
linker commands *after* the -lrpc argument that pulls in the
implementations from librpc.a.  This causes the link commands to fail
because librpc.a is  not rescanned (the dynamic linking case on Linux
doesn't seem to  suffer from this problem - not sure how it differs).
This can be fixed by modifying the library lists in the Makefile to
include a final -lrpc.
2. The linker gets upset about the xerces-c library.  It complains that
it needs to have the --enable-auto-import flag supplied in order to
correctly pull in all the routines it needs (if I read the error
messages rightly).  Fixed this by specifying 
EXTRA_LDFLAGS = -Xlinker --enable-auto-import
3. Finally one of the static libraries was not being made with ar but
with g++.
4. Installation doesn't work (don't think it remembers .exe suffices but
it was getting a little late...).

Proper fixing of the Makefile will require a little more investigation.

Having worked all this through, I now have a set of usable executables.
I haven't yet tested them much (dtnd.exe fires up and complains it can't
find the configuration script - not surprising as I haven't made it yet
- but that is as far as I have got).  And I only wanted it to do a
couple of simple tests...

I think most of fixes could go into the main code line without problem.
I may need some assistance with fixing up the Makefile parts.
 
Regards,
Elwyn

From: Lloyd Wood <[email-masked]>
To: Folly Consulting <[email-masked]>
Date: Wed, 12 Nov 2008 21:45:42 +0000
Cc: DTN interest <[email-masked]>, [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-users] [Fwd: Re: Oasys 1.3.0 does not compile on Cygwin]

Elwyn,

Previous list discussion of Cygwin stalled at the d_type problem.  
Appears you've found a simple workaround and found that d_type use is  
not essential to the dtn code.

My take is that you're already over the hard part for getting the dtn  
code to run, at least - but though cygwin can be convenient, it's  
rarely preferable for development, and not good for networking work  
(no multicast, no IPv6) or anything that stresses the filesystem  
(slow, weirdness in mapping unix behaviour to windows, odd piping  
behaviour too.)

If you're familiar with Cygwin's weirdnesses, fine -- if not, you'll  
be wondering if the behaviour you see is due to the program, or to  
running the program on cygwin.

cheers,

L.

On 12 Nov 2008, at 21:13, Folly Consulting wrote:

> Stephen Farrell suggested the attached message might be usefully  
> seen on
> the users list.
>
> Just to continue.  Having got oasys to compile I tried DTN 2.6.0.  It
> appears it has a similar number of minor problems, plus a problem with
> getting the linkage right between the xdr routines and the C++.  the
> applib is currently refusing to link.
>
> However in the light of Michael's comments below, it is not clear
> whether there is any point in continuing.  Maybe some sort of caveat
> ought to be added to the buiklding instructions or in the wiki - the
> manual currently implies that it can be built for Cygwin and there are
> clearly significant problems to sort out.. which may be intractable.
>
> Regards,
> Elwyn Davies
>
> -------- Original Message --------
> Subject: 	Re: Oasys 1.3.0 does not compile on Cygwin
> Date: 	Wed, 12 Nov 2008 11:38:01 -0800
> From: 	Michael Demmer <[email-masked]>
> To: 	Elwyn Davies <[email-masked]>
> CC: 	Delay Tolerant Networking Interest List
> <[email-masked]>
> References: 	<[email-masked]>
>
>
>
> Yes. There have been cygwin incompatibilities for some time. From what
> I remember, getting things to compile in cygwin is a bit of a pain but
> not fundamentally a challenge, however there was something more
> fundamental in the threading and IO model that caused things to break
> in cygwin. That may have been fixed with a newer version of cygwin,
> but I haven't tried for some time.
>
> Also, I began an effort to port the code to use the Apache Portable
> Runtime (APR) which would mean that the system could run natively on
> either UNIX or Windows platforms. That work is currently checked in
> under the apr-port branch.
>
> -mike
>
> On Wed, Nov 12, 2008 at 6:34 AM, Elwyn Davies  
> <[email-masked]> wrote:
>> Hi.
>>
>> I have been trying to compile DTN2 v2.6.0 and Oasys v1.3.0 on  
>> Windows XP
>> SP2/Cygwin (version 1.5.25-15)
>>
>> There are 4 problems (so far):
>> io/FileUtils.cc:  rm_all_from_dir function does not compile because  
>> the
>> 'dirent structure does not contain 'd_type' on Cygwin (line 133).   
>> This
>> field is only used when the 'recursive' flag is set - this isn't  
>> used in
>> dtn, so commenting out the test for recursive delete  provides a  
>> workaround.
>>
>> io/TTY.h:  Lines 36-39:  cfgetispeed and  cfgetospeed are defined as
>> preprocessor macros in sys/termios.h rather than global functions.
>> Consequently both the declarations and the functions that use them in
>> FileUtils.cc do not compile.  AFAIK these functions are not used.  I
>> commented out the functions and the declarations to allow it to  
>> compile.
>>
>> io/TTY.h (Line 40) and ioTTY.cc(lines 96-101): There is no function
>> cfmakeraw in Cygwin.  hence the wrapper will not compile.  In order  
>> to
>> support
>> the standard DTN code, we need to define TTY::cfmakeraw() as a No- 
>> op in
>> oasys for cygwin.
>>
>> Makefile:  'make install' fails.The shell script executed for the  
>> target
>> 'installlibs' (lines 305-419) is not good 'bash' code.   The   
>> '[' (test)
>> commends fail because the equality operator is '==' rather than '='  
>> and
>> the $DESTDIR argument needs to be enclosed in double quotes to  
>> cater for
>> the empty string case (as is the default).  Also the SHLIB_EXT  
>> variable
>> doesn't seem to be defined.  the following fragment works (if  
>> SHLIB_EXT
>> := a is added):
>>
>> installlib: installdirs
>>    [ "$(DESTDIR)" == . ] || \
>>    [ x$(SHLIBS) == x ] || \
>>    for lib in lib/liboasys-$(OASYS_VERSION).$(SHLIB_EXT) \
>>               lib/liboasyscompat-$(OASYS_VERSION).$(SHLIB_EXT) ; do \
>>        ($(INSTALL_PROGRAM) $$lib $(DESTDIR)$(libdir)) ; \
>>    done
>>
>>    [ "$(DESTDIR)" == . ] || \
>>    for lib in liboasys liboasyscompat ; do \
>>          (cd $(DESTDIR)$(libdir) && rm -f $$lib.$(SHLIB_EXT) && \
>>           ln -s $$lib-$(OASYS_VERSION).$(SHLIB_EXT) $$lib.$ 
>> (SHLIB_EXT)) \
>>    done
>>
>>
>> There are problems with DTN as well.. I will report these separately.
>>
>> Regards,
>> Elwyn
>>
>
>
>
> -- 
> --------------------------------------------------------------------------
> Folly Consulting Ltd, 60 The Butts, Soham, Ely, Cambridgeshire, CB7  
> 5AW
> Company number 6238664: Registered in the UK
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Wed, 12 Nov 2008 21:13:07 +0000
From: Folly Consulting <[email-masked]>
Organization: Folly Consulting Ltd
To: [email-masked]
Subject: [dtn-users] [Fwd: Re: Oasys 1.3.0 does not compile on Cygwin]

Stephen Farrell suggested the attached message might be usefully seen on
the users list.

Just to continue.  Having got oasys to compile I tried DTN 2.6.0.  It
appears it has a similar number of minor problems, plus a problem with
getting the linkage right between the xdr routines and the C++.  the
applib is currently refusing to link.

However in the light of Michael's comments below, it is not clear
whether there is any point in continuing.  Maybe some sort of caveat
ought to be added to the buiklding instructions or in the wiki - the
manual currently implies that it can be built for Cygwin and there are
clearly significant problems to sort out.. which may be intractable.

Regards,
Elwyn Davies

-------- Original Message --------
Subject: 	Re: Oasys 1.3.0 does not compile on Cygwin
Date: 	Wed, 12 Nov 2008 11:38:01 -0800
From: 	Michael Demmer <[email-masked]>
To: 	Elwyn Davies <[email-masked]>
CC: 	Delay Tolerant Networking Interest List
<[email-masked]>
References: 	<[email-masked]>

Yes. There have been cygwin incompatibilities for some time. From what
I remember, getting things to compile in cygwin is a bit of a pain but
not fundamentally a challenge, however there was something more
fundamental in the threading and IO model that caused things to break
in cygwin. That may have been fixed with a newer version of cygwin,
but I haven't tried for some time.

Also, I began an effort to port the code to use the Apache Portable
Runtime (APR) which would mean that the system could run natively on
either UNIX or Windows platforms. That work is currently checked in
under the apr-port branch.

-mike

On Wed, Nov 12, 2008 at 6:34 AM, Elwyn Davies <[email-masked]> wrote:
> Hi.
>
> I have been trying to compile DTN2 v2.6.0 and Oasys v1.3.0 on Windows XP
> SP2/Cygwin (version 1.5.25-15)
>
> There are 4 problems (so far):
> io/FileUtils.cc:  rm_all_from_dir function does not compile because the
> 'dirent structure does not contain 'd_type' on Cygwin (line 133).  This
> field is only used when the 'recursive' flag is set - this isn't used in
> dtn, so commenting out the test for recursive delete  provides a workaround.
>
> io/TTY.h:  Lines 36-39:  cfgetispeed and  cfgetospeed are defined as
> preprocessor macros in sys/termios.h rather than global functions.
> Consequently both the declarations and the functions that use them in
> FileUtils.cc do not compile.  AFAIK these functions are not used.  I
> commented out the functions and the declarations to allow it to compile.
>
> io/TTY.h (Line 40) and ioTTY.cc(lines 96-101): There is no function
> cfmakeraw in Cygwin.  hence the wrapper will not compile.  In order to
> support
> the standard DTN code, we need to define TTY::cfmakeraw() as a No-op in
> oasys for cygwin.
>
> Makefile:  'make install' fails.The shell script executed for the target
> 'installlibs' (lines 305-419) is not good 'bash' code.   The  '[' (test)
> commends fail because the equality operator is '==' rather than '=' and
> the $DESTDIR argument needs to be enclosed in double quotes to cater for
> the empty string case (as is the default).  Also the SHLIB_EXT variable
> doesn't seem to be defined.  the following fragment works (if SHLIB_EXT
> := a is added):
>
> installlib: installdirs
>     [ "$(DESTDIR)" == . ] || \
>     [ x$(SHLIBS) == x ] || \
>     for lib in lib/liboasys-$(OASYS_VERSION).$(SHLIB_EXT) \
>                lib/liboasyscompat-$(OASYS_VERSION).$(SHLIB_EXT) ; do \
>         ($(INSTALL_PROGRAM) $$lib $(DESTDIR)$(libdir)) ; \
>     done
>
>     [ "$(DESTDIR)" == . ] || \
>     for lib in liboasys liboasyscompat ; do \
>           (cd $(DESTDIR)$(libdir) && rm -f $$lib.$(SHLIB_EXT) && \
>            ln -s $$lib-$(OASYS_VERSION).$(SHLIB_EXT) $$lib.$(SHLIB_EXT)) \
>     done
>
>
> There are problems with DTN as well.. I will report these separately.
>
> Regards,
> Elwyn
>

-- 
--------------------------------------------------------------------------
Folly Consulting Ltd, 60 The Butts, Soham, Ely, Cambridgeshire, CB7 5AW
Company number 6238664: Registered in the UK

Date: Wed, 12 Nov 2008 02:01:56 +0000 (GMT)
From: tsafack landry <[email-masked]>
To: [email-masked]
Subject: [dtn-users] ok

--0-1773422795-1226455316=:82248
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[email-masked]=[email-masked]=0A=0A=0A=0A      
--0-1773422795-1226455316=:82248
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><div>[email-masked]<br>[email-masked]<br></div></div><br>=
=0A=0A=0A=0A      </body></html>
--0-1773422795-1226455316=:82248--