Subject: Re: [dtn-users] configure (on ubuntu) question
From: "Darragh O' Keeffe" <[email-masked]>
To: Darren Long <[email-masked]>
Cc: dtn-users mailing list <[email-masked]>
Date: Thu, 31 Jul 2008 20:12:35 +0100
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>

Yup this is exactly what I had to do as well. Only appears to be an  
issue with gcc-4.2.

Darragh

On 31 Jul 2008, at 19:18, Darren Long <[email-masked]> wrote:

> Hi all,
>
> Actually this problem seems to be related to the sue of the -Wno-long-
> double option being passed to gcc by the oasys configure script on
> Ubuntu Hardy Heron.
>
> The tweak I make to get past this is on line 3967 of the configure
> script, where I remove the "-Wno-long-double" being added to CPPFLAGS.
>
> it seems that the configure script does check that gcc supports -Wno-
> long-double but only on Mac OS X.  I assume this is related to
> compiler versions and that configure needs updating to test gcc on
> other platforms too.
>
> Darren
> On 31 Jul 2008, at 15:53, John Ronan wrote:
>
>>
>> On 31 Jul 2008, at 14:58, Alex McMahon wrote:
>>
>>> Hi John,
>>>
>>> Removing the following lines from oasys's configure worked for me.
>>>
>>>
>>> if test "${ac_cv_search_pow+set}" = set; then
>>> break
>>> fi
>>> done
>>> if test "${ac_cv_search_pow+set}" = set; then
>>> :
>>> else
>>> ac_cv_search_pow=no
>>> fi
>> Hi,
>>
>> I had to comment out a bit more but it seemed to work, thank you.
>>
>> --
>> John Ronan <[email-masked]>, +353-51-302938
>> Telecommunications Software &  Systems Group,  http://www.tssg.org
>>
>>
>>
>> _______________________________________________
>> 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: dtn-users mailing list <[email-masked]>
Date: Thu, 31 Jul 2008 19:18:29 +0100
Subject: Re: [dtn-users] configure (on ubuntu) question

Hi all,

Actually this problem seems to be related to the sue of the -Wno-long- 
double option being passed to gcc by the oasys configure script on  
Ubuntu Hardy Heron.

The tweak I make to get past this is on line 3967 of the configure  
script, where I remove the "-Wno-long-double" being added to CPPFLAGS.

it seems that the configure script does check that gcc supports -Wno- 
long-double but only on Mac OS X.  I assume this is related to  
compiler versions and that configure needs updating to test gcc on  
other platforms too.

Darren
On 31 Jul 2008, at 15:53, John Ronan wrote:

>
> On 31 Jul 2008, at 14:58, Alex McMahon wrote:
>
>> Hi John,
>>
>> Removing the following lines from oasys's configure worked for me.
>>
>>
>>  if test "${ac_cv_search_pow+set}" = set; then
>>  break
>> fi
>> done
>> if test "${ac_cv_search_pow+set}" = set; then
>>  :
>> else
>>  ac_cv_search_pow=no
>> fi
> Hi,
>
> I had to comment out a bit more but it seemed to work, thank you.
>
> --
> John Ronan <[email-masked]>, +353-51-302938
> Telecommunications Software &  Systems Group,  http://www.tssg.org
>
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: John Ronan <[email-masked]>
Date: Thu, 31 Jul 2008 15:53:07 +0100
To: dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-users] configure (on ubuntu) question

On 31 Jul 2008, at 14:58, Alex McMahon wrote:

> Hi John,
>
> Removing the following lines from oasys's configure worked for me.
>
>
>   if test "${ac_cv_search_pow+set}" = set; then
>   break
> fi
> done
> if test "${ac_cv_search_pow+set}" = set; then
>   :
> else
>   ac_cv_search_pow=no
> fi
Hi,

I had to comment out a bit more but it seemed to work, thank you.

--
John Ronan <[email-masked]>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

Date: Thu, 31 Jul 2008 15:18:14 +0100
From: "Alex McMahon" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] test - don't reply

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

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

<div dir="ltr"><br></div>

------=_Part_43980_4537360.1217513894444--

Date: Thu, 31 Jul 2008 14:58:54 +0100
From: "Alex McMahon" <[email-masked]>
To: "John Ronan" <[email-masked]>
Cc: dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-users] configure (on ubuntu) question

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

Hi John,

Removing the following lines from oasys's configure worked for me.

  if test "${ac_cv_search_pow+set}" = set; then
  break
fi
done
if test "${ac_cv_search_pow+set}" = set; then
  :
else
  ac_cv_search_pow=no
fi

Regards

Alex McMahon

On Thu, Jul 31, 2008 at 2:34 PM, John Ronan <[email-masked]> wrote:

> Hi,
>
> I'm trying to build the latest version from mercurial on ubuntu 8.04.1
>
> checking for library containing pow... no
> configure: error: can't find required library function (pow)
>
> looking at the config.log I see
> configure:6888: checking for library containing powconfigure:6929:
> gcc -o conftest   -Wno-long-double  conftest.c  >&5conftest.c:48:
> warning: conflicting types for built-in function 'pow'cc1: error:
> unrecognized command line option "-Wno-long-double"configure:6935: $?
> = 1
>
> I guess its a compiler version issue.  Given that I really don't
> understand how the autoconfigure stuff hangs together, Any ideas how
> I could fix it?
>
> Regards
> John
>
>
> --
> John Ronan <[email-masked]>, +353-51-302938
> Telecommunications Software &  Systems Group,  http://www.tssg.org
>
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>

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

<div dir="ltr">Hi John,<br><br>Removing the following lines from oasys&#39;s configure worked for me.<br><br><br>&nbsp; if test &quot;${ac_cv_search_pow+set}&quot; = set; then<br>&nbsp; break<br>fi<br>done<br>if test &quot;${ac_cv_search_pow+set}&quot; = set; then<br>

&nbsp; :<br>else<br>&nbsp; ac_cv_search_pow=no<br>fi<br><br><br>Regards<br><br>Alex McMahon<br><br><div class="gmail_quote">On Thu, Jul 31, 2008 at 2:34 PM, John Ronan <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;">Hi,<br>
<br>
I&#39;m trying to build the latest version from mercurial on ubuntu 8.04.1<br>
<br>
checking for library containing pow... no<br>
configure: error: can&#39;t find required library function (pow)<br>
<br>
looking at the config.log I see<br>
configure:6888: checking for library containing powconfigure:6929:<br>
gcc -o conftest &nbsp; -Wno-long-double &nbsp;conftest.c &nbsp;&gt;&amp;5conftest.c:48:<br>
warning: conflicting types for built-in function &#39;pow&#39;cc1: error:<br>
unrecognized command line option &quot;-Wno-long-double&quot;configure:6935: $?<br>
= 1<br>
<br>
I guess its a compiler version issue. &nbsp;Given that I really don&#39;t<br>
understand how the autoconfigure stuff hangs together, Any ideas how<br>
I could fix it?<br>
<br>
Regards<br>
John<br>
<br>
<br>
--<br>
John Ronan &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, +353-51-302938<br>
Telecommunications Software &amp; &nbsp;Systems Group, &nbsp;<a href="http://www.tssg.org" target="_blank">http://www.tssg.org</a><br>
<br>
<br>
<br>
_______________________________________________<br>
dtn-users mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="http://maillists.intel-research.net/mailman/listinfo/dtn-users" target="_blank">http://maillists.intel-research.net/mailman/listinfo/dtn-users</a><br>
</blockquote></div><br></div>

------=_Part_43614_27867899.1217512734366--

To: dtn-users mailing list <[email-masked]>
From: John Ronan <[email-masked]>
Date: Thu, 31 Jul 2008 14:34:03 +0100
Subject: [dtn-users] configure (on ubuntu) question

Hi,

I'm trying to build the latest version from mercurial on ubuntu 8.04.1

checking for library containing pow... no
configure: error: can't find required library function (pow)

looking at the config.log I see
configure:6888: checking for library containing powconfigure:6929:  
gcc -o conftest   -Wno-long-double  conftest.c  >&5conftest.c:48:  
warning: conflicting types for built-in function 'pow'cc1: error:  
unrecognized command line option "-Wno-long-double"configure:6935: $?  
= 1

I guess its a compiler version issue.  Given that I really don't  
understand how the autoconfigure stuff hangs together, Any ideas how  
I could fix it?

Regards
John

--
John Ronan <[email-masked]>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

From: Michael Demmer <[email-masked]>
To: Gautam Thaker <[email-masked]>
Date: Fri, 25 Jul 2008 11:11:37 -0700
Cc: [email-masked]
Subject: Re: [dtn-users] DTN behavior under link failure cases....

If you're not using custody transfer then UDP is a bad idea since it  
won't ever retransmit if the bundle transmission gets lost.

Also you should be able to run the 'bundle list' command on either  
node to see where the bundles are. Running 'bundle info' on any one  
will show you the forwarding log and the set of bundle queues where it  
might be stuck.

In terms of the debugging output, you can selectively turn on and off  
debug targets by creating a ~/.dtndebug file containing entries like:

/dtn/cl debug
/dtn/bundle debug
+*/refs info

The + lines enable glob-like matching of the pattern rules so you can  
selectively disable things like all the refcount debugging which tends  
to overwhelm the debug noisiness.

-mike

On Jul 25, 2008, at 8:10 AM, Gautam Thaker wrote:

> In order to learn  a bit more regarding my non-working test case  
> described below, I switched to using UDP rather than
> TCP for DTN links. Further, based on a suggestion from a reader I am  
> using "min_retry_interval=1 max_retry_interval=2".
> (Yes, i wish to be reasonably aggressive in recovering once a link  
> comes back.)
>
> I further simplified the test to just 2 nodes, A->B.
>
> My link entry on node A is:
>
> link add link_udp 192.168.0.3:4556 ONDEMAND udp min_retry_interval=1  
> max_retry_interval=2
>
> The IP addresses of the link A->B ends are
>
> A(192.168.0.2) --> B(192.168.0.3)
>
> I do "ifconfig down/up" on machine A. After I bring the interface  
> back up i can "ping" in both directions (A->B and
> B->A) w/o any errors. Yet, "dtnsend" never resumes the bundle  
> transfers that were stopped by "ifconfig down". Actual
> "dtnsend" command is:
>
> dtnsend -D  -w -n 100 -z 1000 -s dtn://a.dtn/stag3 -d dtn://b.dtn/ 
> dest -t f -p /tmp/file.4
>
> Further, if I ^C the dtnsend command and merely reissue it the  
> bundle transfers resume w/o any problems.
>
> It seems to me this behavior is a bug of some type. I tried to run  
> the dtn daemons in "debug" mode, but so much output
> is produced that I can't exactly tell where things are hanging up.
>
> It seems to me that once the interface is back up and pings are  
> getting thru in both direction dtnsend and dtn daemon
> should recover.
>
> Gautam
>
>
> Gautam Thaker wrote:
>> I am trying to better understand how DTN daemons work when links  
>> are failing and coming back in some slow, periodic
>> manner. My test environment is this:
>>
>> A->B->C->D
>>
>> I am trying to send 4 byte file bundles from node A to node D.  
>> Everything work well of course when none of the 3 links
>> involved fail.
>>
>> I then run scripts on nodes A, B, and C so that their outgoing  
>> links (A's link to B, B's link to C and C's link to D)
>> go up/down using the "/sbin/ifconfig ethX up/down" command. The  
>> "down phase is 30 seconds, and the up phase is 30
>> seconds. I am using TCP links to connect the DTN daemons.
>>
>> No bundles get thru at all. Is it documented someplace as to just  
>> how things should behave in a test such as this?
>> Namely, what might be the minimum "up cycle" length for the daemon  
>> to be able to successfully hand the bundle to the
>> next person downstream? (I realize that if the up/down cycle  
>> happens too rapidly bundles may not get thru, but 30
>> seconds of up time should be enough to keep things moving.)
>>
>> Gautam
>> _______________________________________________
>> 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

Date: Fri, 25 Jul 2008 11:10:44 -0400
From: Gautam Thaker <[email-masked]>
To: [email-masked]
Organization: Lockheed Martin -- Advanced Technology Laboratories
Subject: Re: [dtn-users] DTN behavior under link failure cases....

In order to learn  a bit more regarding my non-working test case described below, I switched to using UDP rather than 
TCP for DTN links. Further, based on a suggestion from a reader I am using "min_retry_interval=1 max_retry_interval=2". 
(Yes, i wish to be reasonably aggressive in recovering once a link comes back.)

I further simplified the test to just 2 nodes, A->B.

My link entry on node A is:

link add link_udp 192.168.0.3:4556 ONDEMAND udp min_retry_interval=1 max_retry_interval=2

The IP addresses of the link A->B ends are

A(192.168.0.2) --> B(192.168.0.3)

I do "ifconfig down/up" on machine A. After I bring the interface back up i can "ping" in both directions (A->B and 
B->A) w/o any errors. Yet, "dtnsend" never resumes the bundle transfers that were stopped by "ifconfig down". Actual 
"dtnsend" command is:

dtnsend -D  -w -n 100 -z 1000 -s dtn://a.dtn/stag3 -d dtn://b.dtn/dest -t f -p /tmp/file.4

Further, if I ^C the dtnsend command and merely reissue it the bundle transfers resume w/o any problems.

It seems to me this behavior is a bug of some type. I tried to run the dtn daemons in "debug" mode, but so much output 
is produced that I can't exactly tell where things are hanging up.

It seems to me that once the interface is back up and pings are getting thru in both direction dtnsend and dtn daemon 
should recover.

Gautam

Gautam Thaker wrote:
> I am trying to better understand how DTN daemons work when links are failing and coming back in some slow, periodic 
> manner. My test environment is this:
> 
> A->B->C->D
> 
> I am trying to send 4 byte file bundles from node A to node D. Everything work well of course when none of the 3 links 
> involved fail.
> 
> I then run scripts on nodes A, B, and C so that their outgoing links (A's link to B, B's link to C and C's link to D) 
> go up/down using the "/sbin/ifconfig ethX up/down" command. The "down phase is 30 seconds, and the up phase is 30 
> seconds. I am using TCP links to connect the DTN daemons.
> 
> No bundles get thru at all. Is it documented someplace as to just how things should behave in a test such as this? 
> Namely, what might be the minimum "up cycle" length for the daemon to be able to successfully hand the bundle to the 
> next person downstream? (I realize that if the up/down cycle happens too rapidly bundles may not get thru, but 30 
> seconds of up time should be enough to keep things moving.)
> 
> Gautam
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Fri, 18 Jul 2008 15:47:19 -0400
From: Gautam Thaker <[email-masked]>
To: [email-masked]
Organization: Lockheed Martin -- Advanced Technology Laboratories
Subject: [dtn-users] DTN behavior under link failure cases....

I am trying to better understand how DTN daemons work when links are failing and coming back in some slow, periodic 
manner. My test environment is this:

A->B->C->D

I am trying to send 4 byte file bundles from node A to node D. Everything work well of course when none of the 3 links 
involved fail.

I then run scripts on nodes A, B, and C so that their outgoing links (A's link to B, B's link to C and C's link to D) 
go up/down using the "/sbin/ifconfig ethX up/down" command. The "down phase is 30 seconds, and the up phase is 30 
seconds. I am using TCP links to connect the DTN daemons.

No bundles get thru at all. Is it documented someplace as to just how things should behave in a test such as this? 
Namely, what might be the minimum "up cycle" length for the daemon to be able to successfully hand the bundle to the 
next person downstream? (I realize that if the up/down cycle happens too rapidly bundles may not get thru, but 30 
seconds of up time should be enough to keep things moving.)

Gautam