From rsehgal@kent.edu Tue Feb 5 15:27:52 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6B21F8881 for ; Tue, 5 Feb 2013 15:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WExsqPmzIeF for ; Tue, 5 Feb 2013 15:27:52 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id E654921F8880 for ; Tue, 5 Feb 2013 15:27:51 -0800 (PST) Received: from mail65-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Feb 2013 23:27:50 +0000 Received: from mail65-ch1 (localhost [127.0.0.1]) by mail65-ch1-R.bigfish.com (Postfix) with ESMTP id 4506A14037C for ; Tue, 5 Feb 2013 23:27:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.165; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0810HT003.namprd08.prod.outlook.com; RD:none; EFVD:NLI Received: from mail65-ch1 (localhost.localdomain [127.0.0.1]) by mail65-ch1 (MessageSwitch) id 1360106869151718_27563; Tue, 5 Feb 2013 23:27:49 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail65-ch1.bigfish.com (Postfix) with ESMTP id 18B192402DA for ; Tue, 5 Feb 2013 23:27:49 +0000 (UTC) Received: from BLUPRD0810HT003.namprd08.prod.outlook.com (157.56.232.165) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Feb 2013 23:27:46 +0000 Received: from BLUPRD0810MB353.namprd08.prod.outlook.com ([169.254.3.28]) by BLUPRD0810HT003.namprd08.prod.outlook.com ([10.255.125.38]) with mapi id 14.16.0263.000; Tue, 5 Feb 2013 23:27:45 +0000 From: "SEHGAL, RAHUL" To: "dtn-users@irtf.org" Thread-Topic: Running dtnsim Thread-Index: Ac4D+GctUU9qaezqQuijBK+NuuG7GQ== Date: Tue, 5 Feb 2013 23:27:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.123.39.4] Content-Type: multipart/alternative; boundary="_000_DBCC98EE66509443B1890B7D4F822D0331ADCF75BLUPRD0810MB353_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BLUPRD0810HT003.namprd08.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BLUPRD0810HT003.namprd08.prod.outlook.com X-OriginatorOrg: kent.edu Subject: [dtn-users] Running dtnsim X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 02:38:21 -0000 --_000_DBCC98EE66509443B1890B7D4F822D0331ADCF75BLUPRD0810MB353_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm trying to run dtn2 simulator (dtnsim) to test DTLSR algorithm. Current configuration file for dtlsr uses liner topology of 5 nodes (this file was included in DTN2 download folder). If I want to change the topology to non linear topology, how i can do that? Also, I would like to know how queuing delay is simulated in DTN2 simulation. Is there a parameter that I have to set for queuing delays or can I include it in configuration file? Generally, how I control delays in DTN2? Any help will be appreciated. Thanks, Rahul --_000_DBCC98EE66509443B1890B7D4F822D0331ADCF75BLUPRD0810MB353_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I'm trying to run dtn2 simulator (dtnsim) to test DTLSR algorithm. Current<= br> configuration file for dtlsr uses liner topology of 5 nodes (this file was<= br> included in DTN2 download folder). If I want to change the topology to
non linear topology, how i can do that?

Also, I would like to know how queuing delay is simulated in DTN2
simulation. Is there a parameter that I have to set for queuing delays or can I include it in configuration file? Generally, how I control delays in<= br> DTN2?

Any help will be appreciated.

Thanks,
Rahul
 
--_000_DBCC98EE66509443B1890B7D4F822D0331ADCF75BLUPRD0810MB353_-- From SRS0+86cny=L5==rsehgal@cs.kent.edu Tue Feb 5 14:59:55 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB721F85FD for ; Tue, 5 Feb 2013 14:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck+lt9Af9fKl for ; Tue, 5 Feb 2013 14:59:55 -0800 (PST) Received: from mscan2.vs.cs.kent.edu (mscan2.vs.cs.kent.edu [131.123.37.141]) by ietfa.amsl.com (Postfix) with ESMTP id 077A521F85E2 for ; Tue, 5 Feb 2013 14:59:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mscan2.vs.cs.kent.edu (8.14.4/8.14.4) with ESMTP id r15MxqX7011448 for ; Tue, 5 Feb 2013 17:59:52 -0500 Received: from mscan2.vs.cs.kent.edu ([127.0.0.1]) by localhost (mscan2.cs.kent.edu [127.0.0.1]) (amavisd-maia, port 10024) with LMTP id 10574-03 for ; Tue, 5 Feb 2013 17:59:51 -0500 (EST) Received: from webmail.cs.kent.edu (pc5.cs.kent.edu [131.123.35.16]) by mscan2.vs.cs.kent.edu (8.14.4/8.14.4) with ESMTP id r15MxnB1011439 for ; Tue, 5 Feb 2013 17:59:49 -0500 Received: from 131.123.39.4 (SquirrelMail authenticated user rsehgal) by webmail.cs.kent.edu with HTTP; Tue, 5 Feb 2013 18:04:12 -0500 Message-ID: <2b1ca1dfabf84dd1b26a806f35d09778.squirrel@webmail.cs.kent.edu> Date: Tue, 5 Feb 2013 18:04:12 -0500 From: rsehgal@cs.kent.edu To: dtn-users@irtf.org User-Agent: SquirrelMail/1.4.22-2.el6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mscan2.vs.cs.kent.edu [131.123.37.141]); Tue, 05 Feb 2013 17:59:50 -0500 (EST) X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Wed, 06 Feb 2013 09:06:37 -0800 Subject: [dtn-users] Running dtnsim X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 23:12:59 -0000 Hi, I'm trying to run dtn2 simulator (dtnsim) to test DTLSR algorithm. Current configuration file for dtlsr uses liner topology of 5 nodes (this file was included in DTN2 downloaded folder). If I want to change the topology to non linear topology, how i can do that? Also, I would like to know how queuing delay is simulated in DTN2 simulation. Is there a parameter that I have to set for queuing delays or can I include it in configuration file? Generally, how I control delays in DTN2? Any help will be appreciated. Thanks, Rahul From ssireskin@gmail.com Thu Feb 7 05:40:08 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C694321F8645 for ; Thu, 7 Feb 2013 05:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOXdAsKjLCx7 for ; Thu, 7 Feb 2013 05:40:08 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id 72CA821F860A for ; Thu, 7 Feb 2013 05:40:04 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so1571931vby.19 for ; Thu, 07 Feb 2013 05:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=/iQKtIMPdVKdpPocqQwJ6GFTaQ8jlr9jIuqP1oWP/rs=; b=AbxtSD48ZQ/z9VjD18EyTpucSnlMln7TaIjewvFQItLJGQvXeqXh60tjSw4Ri1Gf1V wIyuDPGYhKDbvufsjzQPsmktuwrfTCF2l9ot5ZfOrThP8WszIlGff0XHnSYFBQpS1DhO lWhDbM+BvZLl2cUOQS/1rX0klfrLfveGX5gUcuZ0gxz9hzX8p4m7VtozlBRnkdAlS2pV m+rrRza9Q+Ub+yv7M89Y8KJo9+a55CJGhJJFb7cc3bKipGrpMP+H6/+UL4zMVuTBYsZv emVAh8UzdmZNgCo6FG9z4HDYJ6TBxlbpduyb2cs7PEMWHYoOkQYEgW9MoH7kUObt+NbT KF5A== MIME-Version: 1.0 X-Received: by 10.58.234.234 with SMTP id uh10mr1609973vec.37.1360244403912; Thu, 07 Feb 2013 05:40:03 -0800 (PST) Received: by 10.58.179.77 with HTTP; Thu, 7 Feb 2013 05:40:03 -0800 (PST) Date: Thu, 7 Feb 2013 16:40:03 +0300 Message-ID: From: "ssireskin@gmail.com" To: dtn-users@irtf.org Content-Type: multipart/alternative; boundary=047d7b6d96fc80c02104d52294c0 Subject: [dtn-users] Is dtntunnel in UDP mode unidirectional? X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:40:08 -0000 --047d7b6d96fc80c02104d52294c0 Content-Type: text/plain; charset=ISO-8859-1 Hello dtn users, During my experiments with sending data with nc through dtntunnel, I have found out that dtntunnel doesn't send data from the nc server to the nc client while working in UDP mode. Is my observation correct, or I have misconfigured my system? -- Best regards, Sergey Sireskin --047d7b6d96fc80c02104d52294c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello dtn users,

During my experiments with sending data with nc thr= ough dtntunnel, I have found out that dtntunnel doesn't send data from = the nc server to the nc client while working in UDP mode.
Is my observat= ion correct, or I have misconfigured my system?

--
Best regards,
Sergey Sireskin

--047d7b6d96fc80c02104d52294c0-- From zollerd@gmail.com Thu Feb 7 18:26:43 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64421F8472 for ; Thu, 7 Feb 2013 18:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CviFhDJkanz4 for ; Thu, 7 Feb 2013 18:26:42 -0800 (PST) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id BEEF321F841F for ; Thu, 7 Feb 2013 18:26:42 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id j1so3510364oag.7 for ; Thu, 07 Feb 2013 18:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=c8DfFfocdNUOKa5EMVslXLTaBuyP5O5hQmtX0VnkE+c=; b=B6PAUT15if3lvZzfN6ByGBWO003UqMMxGb8XT2NGdUqTGThQEFJ23FoRn3CZ9GRVGT GM70PW2ZBvimaGJjvcauIQAkpVTWvtIED2kDkqf33augBh/1I7qbThk1hBM8HwSb9G6J OsNsj0WM7Qe0rJFbzDx9Rz2mYBbG43I+pHfSbAiiu1N56Bql1CWfePbfu1rxBbsyFH1Y RSgObvUxb1fp+5kgE64f6bsgNzGaCQxRs4FaOQvYUD2j544rNeXrJ2bE4eKwwaWygdGp VAjFyZjUKTDMQpV3UV961WoWTTfx0/fTNIpS8nuqwrWZ/Nxz1bWW6olcq5i0QMlPLwnw /VkA== MIME-Version: 1.0 X-Received: by 10.182.227.33 with SMTP id rx1mr2886123obc.69.1360290402084; Thu, 07 Feb 2013 18:26:42 -0800 (PST) Received: by 10.182.111.132 with HTTP; Thu, 7 Feb 2013 18:26:41 -0800 (PST) Date: Thu, 7 Feb 2013 20:26:41 -0600 Message-ID: From: David Zoller To: ssireskin@gmail.com Content-Type: multipart/alternative; boundary=f46d0444741f3525ed04d52d4af4 Cc: dtn-users@irtf.org Subject: [dtn-users] (no subject) X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 02:26:43 -0000 --f46d0444741f3525ed04d52d4af4 Content-Type: text/plain; charset=ISO-8859-1 Hi Sergey, Looks like you are pushing the dtntunnel envelope again:) I've been using the UDP tunnel as a unidirectional transmitter for a good while but never tried the return path. I experimented this evening and looked at the code a bit. It is definitely only unidirectional at the moment and would take a decent amount of coding to make it bidirectional. Sorry, no quick fix, DZ PS. I haven't forgotten the TCPTunnel patch and I'll try to get that done this weekend with my home-hobbyist hat on. I was waiting for my other updates to get approved for export but I think they got lost on someone's desk. Those are now 3 patches behind so I'll have to play catch up again once they do get approved. ---------------------------------------------------- *From:* dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] *On Behalf Of *ssireskin@gmail.com *Sent:* Thursday, February 07, 2013 7:40 AM *To:* dtn-users@irtf.org *Subject:* [dtn-users] Is dtntunnel in UDP mode unidirectional? Hello dtn users, During my experiments with sending data with nc through dtntunnel, I have found out that dtntunnel doesn't send data from the nc server to the nc client while working in UDP mode. Is my observation correct, or I have misconfigured my system? -- Best regards, Sergey Sireskin --f46d0444741f3525ed04d52d4af4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Sergey,

Looks like you are pushing th= e dtntunnel envelope again:)


I've been using the UDP tunne= l as a unidirectional transmitter for a good while but never tried the retu= rn path. I experimented this evening and looked at the code a bit. It is de= finitely only unidirectional at the moment and would take a decent amount o= f coding to make it bidirectional.=A0


Sorry, no quick fix,

DZ


PS. I haven= 9;t forgotten the TCPTunnel patch and I'll try to get that done this we= ekend with my home-hobbyist hat on. I was waiting for my other updates to g= et approved for export but I think they got lost on someone's desk. Tho= se are now 3 patches behind so I'll have to play catch up again once th= ey do get approved.


---------------------------------= -------------------


From: dtn-use= rs-bounces@irtf.org [mailto:dtn-users-bounces@irt= f.org] On Behalf Of ssire= skin@gmail.com
Sent: Thursday, February 07, 2013 7:40 AM
To: dtn-users@irtf.org
Subject: [dtn-users] Is dtntunnel in UDP mode unidirectional?=

=A0

Hello dtn users,

During my experiments with sending data with nc through dtntunnel, I have f= ound out that dtntunnel doesn't send data from the nc server to the nc clien= t while working in UDP mode.
Is my observation correct, or I have misconfigured my system?

--
Best regards,
Sergey Sireskin

--f46d0444741f3525ed04d52d4af4-- From sire@mail.ru Thu Feb 7 23:24:07 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64F421F89AA for ; Thu, 7 Feb 2013 23:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.858 X-Spam-Level: *** X-Spam-Status: No, score=3.858 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FROM_EXCESS_BASE64=1.456, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjGbgIZZ2-cY for ; Thu, 7 Feb 2013 23:24:07 -0800 (PST) Received: from smtp2.mail.ru (smtp2.mail.ru [94.100.176.130]) by ietfa.amsl.com (Postfix) with ESMTP id A4ACC21F89A4 for ; Thu, 7 Feb 2013 23:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Type:MIME-Version:Date:Subject:Cc:From:To; bh=nMiaX38vhtyna7dOmaF/wJgymkGg04suJkuyLxHQfss=; b=cYHBLp6JIADZ14QnRWQdoQiPRxLtNxz2bhWvDiLtK/xWo18iO2TXhcixst/GonYnEzrIxbySZWA55DTmh2Gv9jYTyUkVIq/6ZyK2+6R7qkA5ubyhtARu3RzXdstlyhg/; Received: from [83.149.9.205] (port=25529 helo=[10.217.57.158]) by smtp2.mail.ru with esmtpa (envelope-from ) id 1U3iJY-0005QE-Oi; Fri, 08 Feb 2013 11:24:05 +0400 To: "=?utf-8?B?RGF2aWQgWm9sbGVy?=" , "=?utf-8?B?0KHQtdGA0LPQtdC5INCh0YvRgNC10YHQutC40L0=?=" From: "=?utf-8?B?c2lyZUBtYWlsLnJ1?=" Date: Fri, 08 Feb 2013 11:24:16 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1360308256376" Message-Id: X-Spam: Not detected X-Mras: Ok Cc: =?utf-8?B?ZHRuLXVzZXJzQGlydGYub3Jn?= Subject: [dtn-users] =?utf-8?b?0J3QkDogKNCR0LXQtyDRgtC10LzRiyk=?= X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 07:24:07 -0000 ------=_Part_0_1360308256376 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgRGF2aWQsCgpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEknbSB0cnlpbmcgdG8gbWFrZSBkdG50 dW5uZWwgdHJhbnNwYXJlbnQgZm9yIHRoZSBlbmRwb2ludHMgYnkgc3Vic3RpdHV0aW5nIG9yaWdp bmFsIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIGFuZCBwb3J0cy4gV2l0aCBteSBt b2RpZmljYXRpb25zIG9uZSBpbnN0YW5jZSBvZiBkdG50dW5uZWwgY2FuIGhhbmRsZSB0cmFmZmlj IGZvciBtdWx0aXBsZSBob3N0cy4gV2hlbiBJIHN0YXJ0ZWQgdG8gdGhlIHNhbWUgZm9yIFVEUCBJ IHN1ZGRlbmx5IGRpc2NvdmVyZWQgdGhhdCBpdCBpcyB1bmlkaXJlY3Rpb25hbC4KClJlZ2FyZHMs ClNlcmdleQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQrQntGCOiAiRGF2aWQgWm9sbGVyIiA8 em9sbGVyZEBnbWFpbC5jb20+CtCa0L7QvNGDOiA8c3NpcmVza2luQGdtYWlsLmNvbT4K0JrQvtC/ 0LjRjzogPGR0bi11c2Vyc0BpcnRmLm9yZz4K0KLQtdC80LA6IArQlNCw0YLQsDog0L/Rgiwg0YTQ tdCyIDgsIDIwMTMgMDY6MjYKSGkgU2VyZ2V5LExvb2tzIGxpa2UgeW91IGFyZSBwdXNoaW5nIHRo ZSBkdG50dW5uZWwgZW52ZWxvcGUgYWdhaW46KQoKSSd2ZSBiZWVuIHVzaW5nIHRoZSBVRFAgdHVu bmVsIGFzIGEgdW5pZGlyZWN0aW9uYWwgdHJhbnNtaXR0ZXIgZm9yIGEgZ29vZCB3aGlsZSBidXQg bmV2ZXIgdHJpZWQgdGhlIHJldHVybiBwYXRoLiBJIGV4cGVyaW1lbnRlZCB0aGlzIGV2ZW5pbmcg YW5kIGxvb2tlZCBhdCB0aGUgY29kZSBhIGJpdC4gSXQgaXMgZGVmaW5pdGVseSBvbmx5IHVuaWRp cmVjdGlvbmFsIGF0IHRoZSBtb21lbnQgYW5kIHdvdWxkIHRha2UgYSBkZWNlbnQgYW1vdW50IG9m IGNvZGluZyB0byBtYWtlIGl0IGJpZGlyZWN0aW9uYWwuwqAKClNvcnJ5LCBubyBxdWljayBmaXgs CkRaCgpQUy4gSSBoYXZlbid0IGZvcmdvdHRlbiB0aGUgVENQVHVubmVsIHBhdGNoIGFuZCBJJ2xs IHRyeSB0byBnZXQgdGhhdCBkb25lIHRoaXMgd2Vla2VuZCB3aXRoIG15IGhvbWUtaG9iYnlpc3Qg aGF0IG9uLiBJIHdhcyB3YWl0aW5nIGZvciBteSBvdGhlciB1cGRhdGVzIHRvIGdldCBhcHByb3Zl ZCBmb3IgZXhwb3J0IGJ1dCBJIHRoaW5rIHRoZXkgZ290IGxvc3Qgb24gc29tZW9uZSdzIGRlc2su IFRob3NlIGFyZSBub3cgMyBwYXRjaGVzIGJlaGluZCBzbyBJJ2xsIGhhdmUgdG8gcGxheSBjYXRj aCB1cCBhZ2FpbiBvbmNlIHRoZXkgZG8gZ2V0IGFwcHJvdmVkLgoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKCgpGcm9tOiBkdG4tdXNlcnMtYm91 bmNlc0BpcnRmLm9yZwpbbWFpbHRvOmR0bi11c2Vycy1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhh bGYgT2Ygc3NpcmVza2luQGdtYWlsLmNvbQoKU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA3LCAy MDEzIDc6NDAgQU0KClRvOiBkdG4tdXNlcnNAaXJ0Zi5vcmcKClN1YmplY3Q6IFtkdG4tdXNlcnNd IElzIGR0bnR1bm5lbCBpbiBVRFAgbW9kZSB1bmlkaXJlY3Rpb25hbD8KCsKgCgpIZWxsbwpkdG4g dXNlcnMsCgoKCkR1cmluZyBteSBleHBlcmltZW50cyB3aXRoIHNlbmRpbmcgZGF0YSB3aXRoIG5j IHRocm91Z2ggZHRudHVubmVsLCBJIGhhdmUgZm91bmQKb3V0IHRoYXQgZHRudHVubmVsIGRvZXNu J3Qgc2VuZCBkYXRhIGZyb20gdGhlIG5jIHNlcnZlciB0byB0aGUgbmMgY2xpZW50IHdoaWxlCndv cmtpbmcgaW4gVURQIG1vZGUuCgpJcyBteSBvYnNlcnZhdGlvbiBjb3JyZWN0LCBvciBJIGhhdmUg bWlzY29uZmlndXJlZCBteSBzeXN0ZW0/CgoKLS0gCgpCZXN0IHJlZ2FyZHMsCgpTZXJnZXkgU2ly ZXNraW4= ------=_Part_0_1360308256376 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPkhpIERhdmlkLDxicj48YnI+VGhhbmtz IGZvciB5b3VyIHJlcGx5LiBJJiMzOTttIHRyeWluZyB0byBtYWtlIGR0bnR1bm5lbCB0cmFuc3Bh cmVudCBmb3IgdGhlIGVuZHBvaW50cyBieSBzdWJzdGl0dXRpbmcgb3JpZ2luYWwgc291cmNlIGFu ZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgYW5kIHBvcnRzLiBXaXRoIG15IG1vZGlmaWNhdGlvbnMg b25lIGluc3RhbmNlIG9mIGR0bnR1bm5lbCBjYW4gaGFuZGxlIHRyYWZmaWMgZm9yIG11bHRpcGxl IGhvc3RzLiBXaGVuIEkgc3RhcnRlZCB0byB0aGUgc2FtZSBmb3IgVURQIEkgc3VkZGVubHkgZGlz Y292ZXJlZCB0aGF0IGl0IGlzIHVuaWRpcmVjdGlvbmFsLjxicj48YnI+UmVnYXJkcyw8YnI+U2Vy Z2V5PGJyPjxicj48ZGl2IGlkPSJodGNfaGVhZGVyIiBzdHlsZT0iIj4tLS0tLSBSZXBseSBtZXNz YWdlIC0tLS0tPGJyPtCe0YI6ICZxdW90O0RhdmlkIFpvbGxlciZxdW90OyAmbHQ7em9sbGVyZEBn bWFpbC5jb20mZ3Q7PGJyPtCa0L7QvNGDOiAmbHQ7c3NpcmVza2luQGdtYWlsLmNvbSZndDs8YnI+ 0JrQvtC/0LjRjzogJmx0O2R0bi11c2Vyc0BpcnRmLm9yZyZndDs8YnI+0KLQtdC80LA6IDxicj7Q lNCw0YLQsDog0L/Rgiwg0YTQtdCyIDgsIDIwMTMgMDY6MjY8YnI+PGJyPjwvZGl2Pjwvc3Bhbj48 YnI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxZjQ5N2QiPkhpIFNlcmdleSw8L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5Mb29rcyBsaWtlIHlvdSBhcmUg cHVzaGluZyB0aGUgZHRudHVubmVsIGVudmVsb3BlIGFnYWluOik8L3NwYW4+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+ PGJyPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkkmIzM5O3ZlIGJlZW4gdXNpbmcgdGhlIFVEUCB0dW5uZWwg YXMgYSB1bmlkaXJlY3Rpb25hbCB0cmFuc21pdHRlciBmb3IgYSBnb29kIHdoaWxlIGJ1dCBuZXZl ciB0cmllZCB0aGUgcmV0dXJuIHBhdGguIEkgZXhwZXJpbWVudGVkIHRoaXMgZXZlbmluZyBhbmQg bG9va2VkIGF0IHRoZSBjb2RlIGEgYml0LiBJdCBpcyBkZWZpbml0ZWx5IG9ubHkgdW5pZGlyZWN0 aW9uYWwgYXQgdGhlIG1vbWVudCBhbmQgd291bGQgdGFrZSBhIGRlY2VudCBhbW91bnQgb2YgY29k aW5nIHRvIG1ha2UgaXQgYmlkaXJlY3Rpb25hbC7CoDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48YnI+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFmNDk3ZCI+U29ycnksIG5vIHF1aWNrIGZpeCw8L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+RFo8 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMWY0OTdkIj48YnI+Cjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlBTLiBJIGhhdmVuJiMzOTt0 IGZvcmdvdHRlbiB0aGUgVENQVHVubmVsIHBhdGNoIGFuZCBJJiMzOTtsbCB0cnkgdG8gZ2V0IHRo YXQgZG9uZSB0aGlzIHdlZWtlbmQgd2l0aCBteSBob21lLWhvYmJ5aXN0IGhhdCBvbi4gSSB3YXMg d2FpdGluZyBmb3IgbXkgb3RoZXIgdXBkYXRlcyB0byBnZXQgYXBwcm92ZWQgZm9yIGV4cG9ydCBi dXQgSSB0aGluayB0aGV5IGdvdCBsb3N0IG9uIHNvbWVvbmUmIzM5O3MgZGVzay4gVGhvc2UgYXJl IG5vdyAzIHBhdGNoZXMgYmVoaW5kIHNvIEkmIzM5O2xsIGhhdmUgdG8gcGxheSBjYXRjaCB1cCBh Z2FpbiBvbmNlIHRoZXkgZG8gZ2V0IGFwcHJvdmVkLjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48YnI+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFmNDk3ZCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48YnI+PC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g PGEgaHJlZj0ibWFpbHRvOmR0bi11c2Vycy1ib3VuY2VzQGlydGYub3JnIj5kdG4tdXNlcnMtYm91 bmNlc0BpcnRmLm9yZzwvYT4KW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHRuLXVzZXJzLWJvdW5j ZXNAaXJ0Zi5vcmciPmR0bi11c2Vycy1ib3VuY2VzQGlydGYub3JnPC9hPl0gPGI+T24gQmVoYWxm IE9mIDwvYj48YSBocmVmPSJtYWlsdG86c3NpcmVza2luQGdtYWlsLmNvbSI+c3NpcmVza2luQGdt YWlsLmNvbTwvYT48YnI+CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMDcsIDIwMTMg Nzo0MCBBTTxicj4KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZHRuLXVzZXJzQGlydGYub3Jn Ij5kdG4tdXNlcnNAaXJ0Zi5vcmc8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4gW2R0bi11c2Vyc10g SXMgZHRudHVubmVsIGluIFVEUCBtb2RlIHVuaWRpcmVjdGlvbmFsPzwvc3Bhbj48L3A+Cgo8cCBj bGFzcz0iTXNvTm9ybWFsIj7CoDwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SGVsbG8KZHRuIHVzZXJzLDxicj4KPGJyPgpEdXJpbmcgbXkgZXhw ZXJpbWVudHMgd2l0aCBzZW5kaW5nIGRhdGEgd2l0aCBuYyB0aHJvdWdoIGR0bnR1bm5lbCwgSSBo YXZlIGZvdW5kCm91dCB0aGF0IGR0bnR1bm5lbCBkb2VzbiYjMzk7dCBzZW5kIGRhdGEgZnJvbSB0 aGUgbmMgc2VydmVyIHRvIHRoZSBuYyBjbGllbnQgd2hpbGUKd29ya2luZyBpbiBVRFAgbW9kZS48 YnI+CklzIG15IG9ic2VydmF0aW9uIGNvcnJlY3QsIG9yIEkgaGF2ZSBtaXNjb25maWd1cmVkIG15 IHN5c3RlbT88YnIgY2xlYXI9ImFsbCI+Cjxicj4KLS0gPGJyPgpCZXN0IHJlZ2FyZHMsPGJyPgpT ZXJnZXkgU2lyZXNraW48L3A+Cgo= ------=_Part_0_1360308256376-- From ssireskin@gmail.com Thu Feb 7 23:43:16 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C4521F8971 for ; Thu, 7 Feb 2013 23:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh+GGmT0Yyu5 for ; Thu, 7 Feb 2013 23:43:15 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1C21F895B for ; Thu, 7 Feb 2013 23:43:12 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so2187957vbi.4 for ; Thu, 07 Feb 2013 23:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VI3AWTZhz40/MHHy4lI3YOX4fpey5KoTzdtcwnKv3GE=; b=tcyuoxpMPnaTgQts5J1tbJM/nNLOOsCA74BWYDs7PfGkEoyH1aui+G3shdn1kc0PTi vec8OAhSdWBzMquFAQmaCVI0JKmnYRbqDZveIXVjWBfILyIlUklUwk7zIQ/3ZjkMGX3W TmstJsDTQ7zagHY46OVGQRIBWFxkDpTjBaVeBvy4jU0nmO3s2wXkUGvd+tOqu2KKgXap WkUYNNozCJjulCEssTxkOWI5Jt48MjfQ6RQjVlmxSGD9QXodTlh/tXhtkJUW4RZfzZeS UT2pUrqV/LfG4JSFxKdlW6XoCnIOwod7VINg0uNr5Tr4xDv0hpQYrJ0qeEhkxwo0CvoC K6+Q== MIME-Version: 1.0 X-Received: by 10.59.13.197 with SMTP id fa5mr5450489ved.47.1360309392160; Thu, 07 Feb 2013 23:43:12 -0800 (PST) Received: by 10.58.179.77 with HTTP; Thu, 7 Feb 2013 23:43:12 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Feb 2013 10:43:12 +0300 Message-ID: From: "ssireskin@gmail.com" To: David Zoller Content-Type: multipart/alternative; boundary=089e0118499c1ab8ee04d531b670 Cc: dtn-users@irtf.org Subject: Re: [dtn-users] (no subject) X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 07:43:16 -0000 --089e0118499c1ab8ee04d531b670 Content-Type: text/plain; charset=ISO-8859-1 Hi David, Thanks for your reply. I'm trying to make dtntunnel transparent for the endpoints by substituting original source and destination addresses and ports. With my modifications one instance of dtntunnel can handle traffic for multiple hosts. When I started to do the same for UDP I suddenly discovered that it is unidirectional. Regards, Sergey 2013/2/8 David Zoller > Hi Sergey, > > Looks like you are pushing the dtntunnel envelope again:) > > > I've been using the UDP tunnel as a unidirectional transmitter for a good > while but never tried the return path. I experimented this evening and > looked at the code a bit. It is definitely only unidirectional at the > moment and would take a decent amount of coding to make it bidirectional. > > > Sorry, no quick fix, > > DZ > > > PS. I haven't forgotten the TCPTunnel patch and I'll try to get that done > this weekend with my home-hobbyist hat on. I was waiting for my other > updates to get approved for export but I think they got lost on someone's > desk. Those are now 3 patches behind so I'll have to play catch up again > once they do get approved. > > > ---------------------------------------------------- > > > *From:* dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] *On > Behalf Of *ssireskin@gmail.com > *Sent:* Thursday, February 07, 2013 7:40 AM > *To:* dtn-users@irtf.org > *Subject:* [dtn-users] Is dtntunnel in UDP mode unidirectional? > > > > Hello dtn users, > > During my experiments with sending data with nc through dtntunnel, I have > found out that dtntunnel doesn't send data from the nc server to the nc > client while working in UDP mode. > Is my observation correct, or I have misconfigured my system? > > -- > Best regards, > Sergey Sireskin > -- Best regards, Sergey Sireskin --089e0118499c1ab8ee04d531b670 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi David,

Thanks for your=20 reply. I'm trying to make dtntunnel transparent for the endpoints by=20 substituting original source and destination addresses and ports. With=20 my modifications one instance of dtntunnel can handle traffic for=20 multiple hosts. When I started to do the same for UDP I suddenly discovered that it is unidirectional.

Regards,
Sergey


2013/2/8 David Zoller <zollerd@gmail.com>

Hi Sergey,

Looks like you are pushin= g the dtntunnel envelope again:)


I've been using the UDP tunne= l as a unidirectional transmitter for a good while but never tried the retu= rn path. I experimented this evening and looked at the code a bit. It is de= finitely only unidirectional at the moment and would take a decent amount o= f coding to make it bidirectional.=A0


Sorry, no quick fix,

DZ


PS. I haven= 9;t forgotten the TCPTunnel patch and I'll try to get that done this we= ekend with my home-hobbyist hat on. I was waiting for my other updates to g= et approved for export but I think they got lost on someone's desk. Tho= se are now 3 patches behind so I'll have to play catch up again once th= ey do get approved.


---------------------------------= -------------------


From: dtn-users-bounces@irtf.org [mailto:dtn= -users-bounces@irtf.org] On Behalf Of ssireskin@gmail.com
Sent: Thursday, February 07, 2013 7:40 AM
To: dtn-user= s@irtf.org
Subject: [dtn-users] Is dtntunnel in UDP mode unidirectional?=

=A0

Hello dtn users,

During my experiments with sending data with nc through dtntunnel, I have f= ound out that dtntunnel doesn't send data from the nc server to the nc clien= t while working in UDP mode.
Is my observation correct, or I have misconfigured my system?

--
Best regards,
Sergey Sireskin




--
Best regards,
Sergey= Sireskin

--089e0118499c1ab8ee04d531b670-- From bmpt@ua.pt Mon Feb 11 09:58:18 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD5921F879B for ; Mon, 11 Feb 2013 09:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlcTN9JAjtm9 for ; Mon, 11 Feb 2013 09:58:17 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 79B5E21F86D4 for ; Mon, 11 Feb 2013 09:58:17 -0800 (PST) Received: from mail74-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 17:58:16 +0000 Received: from mail74-ch1 (localhost [127.0.0.1]) by mail74-ch1-R.bigfish.com (Postfix) with ESMTP id 4B61B140353 for ; Mon, 11 Feb 2013 17:58:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0210HT003.eurprd02.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -7 X-BigFish: VS-7(zz11efRc85fhzz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ah1082kzzz2fh87h2a8h668h839hd25h1288h12a5h12bdh137ah13eah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh34h1155h) Received-SPF: pass (mail74-ch1: domain of ua.pt designates 157.56.253.181 as permitted sender) client-ip=157.56.253.181; envelope-from=bmpt@ua.pt; helo=DBXPRD0210HT003.eurprd02.prod.outlook.com ; .outlook.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail74-ch1 (localhost.localdomain [127.0.0.1]) by mail74-ch1 (MessageSwitch) id 1360605494576067_25376; Mon, 11 Feb 2013 17:58:14 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail74-ch1.bigfish.com (Postfix) with ESMTP id 835A3320057 for ; Mon, 11 Feb 2013 17:58:14 +0000 (UTC) Received: from DBXPRD0210HT003.eurprd02.prod.outlook.com (157.56.253.181) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Feb 2013 17:58:13 +0000 Received: from DBXPRD0210MB358.eurprd02.prod.outlook.com ([169.254.6.73]) by DBXPRD0210HT003.eurprd02.prod.outlook.com ([10.255.78.166]) with mapi id 14.16.0263.000; Mon, 11 Feb 2013 17:58:01 +0000 From: Bruno Tavares To: "dtn-users@irtf.org" Thread-Topic: Prophet routing protocol problem Thread-Index: Ac4IYzr5qFJTD+nMTe6Dn1YJvqai5wAHgYhC Date: Mon, 11 Feb 2013 17:58:00 +0000 Message-ID: <90494CFA1222DC45A1855F79747890D81155375E@DBXPRD0210MB358.eurprd02.prod.outlook.com> References: <90494CFA1222DC45A1855F79747890D8115534F7@DBXPRD0210MB358.eurprd02.prod.outlook.com> In-Reply-To: <90494CFA1222DC45A1855F79747890D8115534F7@DBXPRD0210MB358.eurprd02.prod.outlook.com> Accept-Language: pt-PT, en-US Content-Language: pt-PT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [193.137.168.40] Content-Type: multipart/mixed; boundary="_003_90494CFA1222DC45A1855F79747890D81155375EDBXPRD0210MB358_" MIME-Version: 1.0 X-OriginatorOrg: ua.pt X-Mailman-Approved-At: Mon, 11 Feb 2013 09:59:22 -0800 Subject: [dtn-users] Prophet routing protocol problem X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 17:58:18 -0000 --_003_90494CFA1222DC45A1855F79747890D81155375EDBXPRD0210MB358_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I'm a student from Portugal and I'm using DTN2 to develop my thesys. I'm having problems with the Prophet routing protocol. I'm using two nodes = and when the two DTN servers are on the following error appears on one side= : dtn% ASSERTION FAILED (e->link_ !=3D NULL) at routing/ProphetRouter.cc:190 STACK TRACE: 0x816b0b1 0x80ffc11 0x8093a88 0x80ff396 0x8084797 0x808472c 0x= 8085924 0x8190a1d 0x81908f6 0xb7401d4c Aborted (core dumped) On the other node I get this (but in this node the server do not go down ad= versely with what happens on the other node): [1360589387.922953 /dtn/storage/bundles error] update(44): bundle doesn't e= xist in table [1360589387.922982 /dtn/bundle/actions critical] error updating bundle 44 i= n data store!! [1360589387.923005 /dtn/storage/bundles error] update(44): bundle doesn't e= xist in table [1360589387.923025 /dtn/bundle/actions critical] error updating bundle 44 i= n data store!! [1360589387.923092 /dtn/cl/udp/sender/0xb41051d0 error] send_bundle: error = sending bundle (wrote -1/122): Connection refused [1360589389.930819 /dtn/storage/bundles error] update(45): bundle doesn't e= xist in table [1360589389.930849 /dtn/bundle/actions critical] error updating bundle 45 i= n data store!! [1360589389.930871 /dtn/storage/bundles error] update(45): bundle doesn't e= xist in table [1360589389.930885 /dtn/bundle/actions critical] error updating bundle 45 i= n data store!! [1360589389.931061 /dtn/storage/bundles error] update(45): bundle doesn't e= xist in table [1360589389.931076 /dtn/bundle/actions critical] error updating bundle 45 i= n data store!! I will attach the configuration files of the two nodes that I'm using I would be very thankfull if someone could help me solve this problem. Regards, Bruno Tavares --_003_90494CFA1222DC45A1855F79747890D81155375EDBXPRD0210MB358_ Content-Type: application/octet-stream; name="Node1.conf" Content-Description: Node1.conf Content-Disposition: attachment; filename="Node1.conf"; size=6442; creation-date="Mon, 11 Feb 2013 14:28:32 GMT"; modification-date="Mon, 11 Feb 2013 14:28:32 GMT" Content-Transfer-Encoding: base64 IwojIGR0bi5jb25mCiMKIyBEZWZhdWx0IGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgSW50ZXJuZXQt Y29ubmVjdGVkIERUTiBub2Rlcy4gVGhlCiMgZGFlbW9uIHVzZXMgYSB0Y2wgaW50ZXJwcmV0ZXIg dG8gcGFyc2UgdGhpcyBmaWxlLCB0aHVzIGFueSBzdGFuZGFyZAojIHRjbCBjb21tYW5kcyBhcmUg dmFsaWQsIGFuZCBhbGwgc2V0dGluZ3MgYXJlIGdldC9zZXQgdXNpbmcgYSBzaW5nbGUKIyAnc2V0 JyBmdW5jdGlvbnMgYXM6IDxtb2R1bGU+IHNldCA8dmFyPiA8dmFsPz4KIwoKbG9nIC9kdG5kIGlu Zm8gImR0bmQgcGFyc2luZyBjb25maWd1cmF0aW9uLi4uIgoKIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIwojCiMgRGFlbW9uIENvbnNvbGUgQ29uZmlndXJhdGlvbgojCiMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCiMKIyBjb25zb2xlIHNldCBz dGRpbyBbIHRydWUgfCBmYWxzZSBdCiMKIyBJZiBzZXQgdG8gZmFsc2UsIGRpc2FibGUgdGhlIGlu dGVyYWN0aXZlIGNvbnNvbGUgb24gc3RkaW4vc3Rkb3V0LgojIFRoZSBkZWZhdWx0IGlzIHNldCB0 byB0cnVlICh1bmxlc3MgdGhlIGR0bmQgcHJvY2VzcyBpcyBydW4gYXMgYQojIGRhZW1vbikuCiMK IyBjb25zb2xlIHNldCBzdGRpbyBmYWxzZQoKIwojIGNvbnNvbGUgc2V0IGFkZHIgPHBvcnQ+CiMg Y29uc29sZSBzZXQgcG9ydCA8cG9ydD4KIwojIFNldHRpbmdzIGZvciB0aGUgc29ja2V0IGJhc2Vk IGNvbnNvbGUgcHJvdG9jb2wuCiMgKHRoaXMgaW50ZXJwcmV0cyB1c2VyIGNvbW1hbmRzKQojCmNv bnNvbGUgc2V0IGFkZHIgMTI3LjAuMC4xCmNvbnNvbGUgc2V0IHBvcnQgNTA1MAoKIwojIGNvbnNv bGUgc2V0IHByb21wdCA8cHJvbXB0PgojCiMgU2V0IHRoZSBwcm9tcHQgc3RyaW5nLiAgSGVscHMg aWYgcnVubmluZyBtdWx0aXBsZSBkdG5kJ3MKIwpzZXQgc2hvcnRob3N0bmFtZSBbbGluZGV4IFtz cGxpdCBbaW5mbyBob3N0bmFtZV0gLl0gMF0KY29uc29sZSBzZXQgcHJvbXB0ICIkc2hvcnRob3N0 bmFtZSBkdG4lICIKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIwoj IEFQSSBDb25maWd1cmF0aW9uCiMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIwoKI2FwaSBzZXQgbG9jYWxfcG9ydCA1MDEwCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjCiMKIyBTdG9yYWdlIENvbmZpZ3VyYXRpb24KIwojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgojCiMgc3RvcmFnZSBzZXQgdHlwZSBbIGJlcmtl bGV5ZGIgfCBleHRlcm5hbCB8IG1lbW9yeWRiIF0KIwojIFNldCB0aGUgc3RvcmFnZSBzeXN0ZW0g dG8gYmUgdXNlZAojCnN0b3JhZ2Ugc2V0IHR5cGUgYmVya2VsZXlkYgoKIyB0aGUgZm9sbG93aW5n IGFyZSBmb3IgdXNlIHdpdGggZXh0ZXJuYWwgZGF0YSBzdG9yZXMKIwojIFRoZSBzZXJ2ZXIgcG9y dCB0byBjb25uZWN0IHRvIChvbiBsb2NhbGhvc3QpCiMgTm90ZSB0aGF0IDYyMzQ1IGhhcyBubyBz cGVjaWFsIHNpZ25pZmljYW5jZSAtLSBjaG9zZW4gcmFuZG9tbHkKc3RvcmFnZSBzZXQgc2VydmVy X3BvcnQgNjIzNDUKCiMgVGhlIGV4dGVybmFsIGRhdGEgc3RvcmUgc2NoZW1hIGxvY2F0aW9uLCB3 aGljaCBjYW4gYmUKIyBmb3VuZCBpbiBkdG4yL29hc3lzL3N0b3JhZ2UvRFMueHNkLgpzdG9yYWdl IHNldCBzY2hlbWEgL2V0Yy9EUy54c2QKCgojCiMgRG8gYSBydW50aW1lIGNoZWNrIGZvciB0aGUg c3RhbmRhcmQgbG9jYXRpb25zIGZvciB0aGUgcGVyc2lzdGVudAojIHN0b3JhZ2UgZGlyZWN0b3J5 CiMKc2V0IGRiZGlyICIiCmZvcmVhY2ggZGlyIHsvdmFyL2R0biAvdmFyL3RtcC9kdG59IHsKICAg IGlmIHtbZmlsZSBpc2RpcmVjdG9yeSAkZGlyXX0gewogICAgICAgIHNldCBkYmRpciAkZGlyCiAg ICAgICAgYnJlYWsKICAgIH0KfQoKaWYgeyRkYmRpciA9PSAiIn0gewogICAgcHV0cyBzdGRlcnIg Ik11c3QgY3JlYXRlIC92YXIvZHRuIG9yIC92YXIvdG1wL2R0biBzdG9yYWdlIGRpcmVjdG9yeSIK ICAgIGV4aXQgMQp9CgojCiMgc3RvcmFnZSBzZXQgcGF5bG9hZGRpciA8ZGlyPgojCiMgU2V0IHRo ZSBkaXJlY3RvcnkgdG8gYmUgdXNlZCBmb3IgYnVuZGxlIHBheWxvYWQgZmlsZXMKIwpzdG9yYWdl IHNldCBwYXlsb2FkZGlyIC9ob21lL2JydW5vL0Rlc2t0b3AvZHRuL2J1bmRsZXMKCiMKIyBzdG9y YWdlIHNldCBkYm5hbWUgPGRiPgojCiMgU2V0IHRoZSBkYXRhYmFzZSBuYW1lIChhcHBlbmRlZCB3 aXRoIC5kYiBhcyB0aGUgZmlsZW5hbWUgaW4gYmVya2VsZXkKIyBkYiwgdXNlZCBhcy1pcyBmb3Ig U1FMIHZhcmlhbnRzCiMKc3RvcmFnZSBzZXQgZGJuYW1lICAgICBEVE4KCiMKIyBzdG9yYWdlIHNl dCBkYmRpciAgICA8ZGlyPgojCiMKIyBXaGVuIHVzaW5nIGJlcmtlbGV5IGRiLCBzZXQgdGhlIGRp cmVjdG9yeSB0byBiZSB1c2VkIGZvciB0aGUKIyBkYXRhYmFzZSBmaWxlcyBhbmQgdGhlIG5hbWUg b2YgdGhlIGZpbGVzIGFuZCBlcnJvciBsb2cuCiMKc3RvcmFnZSBzZXQgZGJkaXIgICAgICAvaG9t ZS9icnVuby9EZXNrdG9wL2R0bi9kYgoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIwojCiMgUm91dGluZyBjb25maWd1cmF0aW9uCiMKIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIwoKIwojIFNldCB0aGUgYWxnb3JpdGhtIHVzZWQgZm9yIGR0biBy b3V0aW5nLgojCiMgcm91dGUgc2V0IHR5cGUgW3N0YXRpYyB8IGZsb29kIHwgbmVpZ2hib3Job29k IHwgbGlua3N0YXRlIHwgZXh0ZXJuYWxdCiMKcm91dGUgc2V0IHR5cGUgcHJvcGhldAojCiMgcm91 dGUgbG9jYWxfZWlkIDxlaWQ+CiMKIyBTZXQgdGhlIGxvY2FsIGFkbWluaXN0cmF0aXZlIGlkIG9m IHRoaXMgbm9kZS4gVGhlIGRlZmF1bHQganVzdCB1c2VzCiMgdGhlIGludGVybmV0IGhvc3RuYW1l IHBsdXMgdGhlIGFwcGVuZGVkIHN0cmluZyAiLmR0biIgdG8gbWFrZSBpdAojIGNsZWFyIHRoYXQg dGhlIGhvc3RuYW1lIGlzbid0IHJlYWxseSB1c2VkIGZvciBETlMgbG9va3Vwcy4KIwpyb3V0ZSBs b2NhbF9laWQgImR0bjovL2JydW5vLmR0biIKCiMKIyBFeHRlcm5hbCByb3V0ZXIgc3BlY2lmaWMg b3B0aW9ucwojCiMgcm91dGUgc2V0IHNlcnZlcl9wb3J0IDgwMDEKIyByb3V0ZSBzZXQgaGVsbG9f aW50ZXJ2YWwgMzAKIyByb3V0ZSBzZXQgc2NoZW1hICIvZXRjL3JvdXRlci54c2QiCgojIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMKIyBUQ1AgY29udmVyZ2VuY2UgbGF5 ZXIgY29uZmlndXJhdGlvbgojCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMKCiMKIyBpbnRlcmZhY2UgYWRkIFtuYW1lXSBbQ0xdCiMKIyBBZGQgYW4gaW5wdXQgaW50ZXJm YWNlIHRvIGxpc3RlbiBvbiBhZGRyOnBvcnQgZm9yIGluY29taW5nIGJ1bmRsZXMKIyBmcm9tIG90 aGVyIHRjcCAvIHVkcCBjb252ZXJnZW5jZSBsYXllcnMKIwojIEZvciBJUC1iYXNlZCBpbnRlcmZh Y2VzLCBpbnRlcmZhY2VzIGxpc3RlbiBvbiBJTkFERFJfQU5ZIHBvcnQgNDU1NgojIGJ5IGRlZmF1 bHQuIFRoZXNlIGNhbiBiZSBvdmVycmlkZGVuIGJ5IHVzaW5nIHRoZSBsb2NhbF9hZGRyIGFuZC9v cgojIGxvY2FsX3BvcnQgYXJndW1lbnRzLgojaW50ZXJmYWNlIGFkZCB0Y3AwIHRjcCBsb2NhbF9h ZGRyPTE5Mi4xNjguODAuMjIyIGxvY2FsX3BvcnQ9NDU1NgoKCmludGVyZmFjZSBhZGQgdWRwMCB1 ZHAgbG9jYWxfYWRkcj0xOTIuMTY4LjgwLjIyMiBsb2NhbF9wb3J0PTQ1NTYKCgojCiMgbGluayBh ZGQgPG5hbWU+IDxuZXh0aG9wPiA8dHlwZT4gPGNsYXllcj4gPGFyZ3MuLi4+CiMKIyBBZGQgYSBs aW5rIHRvIGEgcGVlciBub2RlLgojIAojIEZvciBJUC1iYXNlZCBsaW5rcyAodGNwIG9yIHVkcCks IHRoZSBuZXh0aG9wIHNob3VsZCBjb250YWluIGEgRE5TCiMgaG9zdG5hbWUgb3IgSVAgYWRkcmVz cywgZm9sbG93ZWQgb3B0aW9uYWxseSBieSBhIDogYW5kIGEgcG9ydC4gSWYKIyB0aGUgcG9ydCBp cyBub3Qgc3BlY2lmaWVkLCB0aGUgZGVmYXVsdCBvZiA0NTU2IGlzIHVzZWQuCiMKIyBlLmcuICBs aW5rIGFkZCBsaW5rMSBkdG4uZHRucmcub3JnIE9OREVNQU5EIHRjcAojICAgICAgIGxpbmsgYWRk IGxpbmsyIGR0bjIuZHRucmcub3JnOjEwMDAwIE9OREVNQU5EIHRjcAoKI2xpbmsgYWRkIGxpbmtf dGNwMiAxOTIuMTY4LjgwLjIyMjo0NTU2IE9OREVNQU5EIHRjcAoKIwojIHJvdXRlIGFkZCA8ZGVz dD4gPGxpbmt8cGVlcj4KIwojIEFkZCBhIHJvdXRlIHRvIHRoZSBnaXZlbiBidW5kbGUgZW5kcG9p bnQgaWQgcGF0dGVybiA8ZGVzdD4gdXNpbmcgdGhlCiMgc3BlY2lmaWVkIGxpbmsgbmFtZSBvciBw ZWVyIGVuZHBvaW50LgojCiMgZS5nLiByb3V0ZSBhZGQgZHRuOi8vaG9zdC5kb21haW4vKiB0Y3Aw Cgojcm91dGUgYWRkIGR0bjovL2JydW5vLmR0bi8qIGxpbmtfdGNwMgoKIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojCiMgU2VydmljZSBkaXNjb3ZlcnkKIwojIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgojCiMgZGlzY292ZXJ5IGFkZCA8bmFt ZT4gPGFmPiA8b3B0cy4uLj4KIyBkaXNjb3ZlcnkgYW5ub3VuY2UgPGNsX25hbWU+IDxkaXNjb3Zl cnlfbmFtZT4gPGNsX3R5cGU+IDxvcHRzLi4uPgojCiMgQWRkIGEgbG9jYWwgbmVpZ2hib3Job29k IGRpc2NvdmVyeSBtb2R1bGUKIwojIGUuZy4gZGlzY292ZXJ5IGFkZCBkaXNjb3ZlcnlfYm9uam91 ciBib25qb3VyCgpkaXNjb3ZlcnkgYWRkIHVkcDBkIGlwIHBvcnQ9OTU1NiAKZGlzY292ZXJ5IGFu bm91bmNlIHVkcDAgdWRwMGQgdWRwIGludGVydmFsPTEgY2xfYWRkcj0xOTIuMTY4LjgwLjIyMiBj bF9wb3J0PTQ1NTYKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIwoj IFBhcmFtZXRlciBUdW5pbmcKIwojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCgojCiMgU2V0IHRoZSBzaXplIHRocmVzaG9sZCBmb3IgdGhlIGRhZW1vbiBzbyBhbnkgYnVu ZGxlcyBzbWFsbGVyIHRoYW4gdGhpcwojIHNpemUgbWFpbnRhaW4gYSBzaGFkb3cgY29weSBpbiBt ZW1vcnkgdG8gbWluaW1pemUgZGlzayBhY2Nlc3Nlcy4gCiMKIyBwYXJhbSBzZXQgcGF5bG9hZF9t ZW1fdGhyZXNob2xkIDE2Mzg0CgojCiMgVGVzdCBvcHRpb24gdG8ga2VlcCBhbGwgYnVuZGxlIGZp bGVzIGluIHRoZSBmaWxlc3lzdGVtLCBldmVuIGFmdGVyIHRoZQojIGJ1bmRsZSBpcyBubyBsb25n ZXIgcHJlc2VudCBhdCB0aGUgZGFlbW9uLgojCiMgcGFyYW0gc2V0IHBheWxvYWRfdGVzdF9ub19y ZW1vdmUgdHJ1ZQoKIwojIFNldCB0aGUgc2l6ZSBmb3Igd2hpY2ggdGhlIHRjcCBjb252ZXJnZW5j ZSBsYXllciBzZW5kcyBwYXJ0aWFsIHJlY2VwdGlvbgojIGFja25vd2xlZGdlbWVudHMuIFVzZWQg d2l0aCByZWFjdGl2ZSBmcmFnbWVudGF0aW9uCiMKIyBwYXJhbSBzZXQgdGNwY2xfcGFydGlhbF9h Y2tfbGVuIDQwOTYKCiMKIyBTZXQgaWYgYnVuZGxlcyBhcmUgYXV0b21hdGljYWxseSBkZWxldGVk IGFmdGVyIHRyYW5zbWlzc2lvbgojCiMgcGFyYW0gc2V0IGVhcmx5X2RlbGV0aW9uIHRydWUKCiMg KG90aGVycyBleGlzdCBidXQgYXJlIG5vdCBmdWxseSByZXByZXNlbnRlZCBoZXJlKQoKCiMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIwojIEV4dGVuc2lvbiBCbG9jayBD b25maWd1cmF0aW9uCiMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoK IwojIEF0dGFjaCBhbiBBZ2UgRXh0ZW5zaW9uIEJsb2NrIHRvIG91dGdvaW5nIGJ1bmRsZXMKIwoj IGJsb2NrIHNldCBhZ2Vfb3V0Ym91bmRfZW5hYmxlZCBmYWxzZQoKIwojIFByb2Nlc3MgdGhlIEFn ZSBFeHRlbnNpb24gQmxvY2sgb24gaW5jb21pbmcgYnVuZGxlcwojCiMgYmxvY2sgc2V0IGFnZV9p bmJvdW5kX3Byb2Nlc3NpbmcgdHJ1ZQoKIwojIFplcm8gb3V0IHRoZSBDcmVhdGlvbiBUaW1lc3Rh bXAgVGltZSBvbiBidW5kbGVzCiMKIyBibG9jayBzZXQgYWdlX3plcm9fY3JlYXRpb25fdHNfdGlt ZSBmYWxzZQoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojCiMgQlBR IGNhY2hpbmcgY29udHJvbAojCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMKCiMKIyBUdXJuIG9uIGNhY2hpbmcgb2YgcGFzc2luZyBidW5kbGVzIHdpdGggQlBRIGJsb2Nr cwojCiMgYnBxIGVuYWJsZQojCgoKbG9nIC9kdG5kIGluZm8gImR0bmQgY29uZmlndXJhdGlvbiBw YXJzaW5nIGNvbXBsZXRlIgoKIyMgZW1hY3Mgc2V0dGluZ3MgdG8gdXNlIHRjbC1tb2RlIGJ5IGRl ZmF1bHQKIyMgTG9jYWwgVmFyaWFibGVzOiAqKioKIyMgbW9kZTp0Y2wgKioqCiMjIEVuZDogKioq Cg== --_003_90494CFA1222DC45A1855F79747890D81155375EDBXPRD0210MB358_ Content-Type: application/octet-stream; name="node2.conf" Content-Description: node2.conf Content-Disposition: attachment; filename="node2.conf"; size=6453; creation-date="Mon, 11 Feb 2013 14:28:43 GMT"; modification-date="Mon, 11 Feb 2013 14:28:43 GMT" Content-Transfer-Encoding: base64 IwojIGR0bi5jb25mCiMKIyBEZWZhdWx0IGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgSW50ZXJuZXQt Y29ubmVjdGVkIERUTiBub2Rlcy4gVGhlCiMgZGFlbW9uIHVzZXMgYSB0Y2wgaW50ZXJwcmV0ZXIg dG8gcGFyc2UgdGhpcyBmaWxlLCB0aHVzIGFueSBzdGFuZGFyZAojIHRjbCBjb21tYW5kcyBhcmUg dmFsaWQsIGFuZCBhbGwgc2V0dGluZ3MgYXJlIGdldC9zZXQgdXNpbmcgYSBzaW5nbGUKIyAnc2V0 JyBmdW5jdGlvbnMgYXM6IDxtb2R1bGU+IHNldCA8dmFyPiA8dmFsPz4KIwoKbG9nIC9kdG5kIGlu Zm8gImR0bmQgcGFyc2luZyBjb25maWd1cmF0aW9uLi4uIgoKIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIwojCiMgRGFlbW9uIENvbnNvbGUgQ29uZmlndXJhdGlvbgojCiMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCiMKIyBjb25zb2xlIHNldCBz dGRpbyBbIHRydWUgfCBmYWxzZSBdCiMKIyBJZiBzZXQgdG8gZmFsc2UsIGRpc2FibGUgdGhlIGlu dGVyYWN0aXZlIGNvbnNvbGUgb24gc3RkaW4vc3Rkb3V0LgojIFRoZSBkZWZhdWx0IGlzIHNldCB0 byB0cnVlICh1bmxlc3MgdGhlIGR0bmQgcHJvY2VzcyBpcyBydW4gYXMgYQojIGRhZW1vbikuCiMK IyBjb25zb2xlIHNldCBzdGRpbyBmYWxzZQoKIwojIGNvbnNvbGUgc2V0IGFkZHIgPHBvcnQ+CiMg Y29uc29sZSBzZXQgcG9ydCA8cG9ydD4KIwojIFNldHRpbmdzIGZvciB0aGUgc29ja2V0IGJhc2Vk IGNvbnNvbGUgcHJvdG9jb2wuCiMgKHRoaXMgaW50ZXJwcmV0cyB1c2VyIGNvbW1hbmRzKQojCmNv bnNvbGUgc2V0IGFkZHIgMTI3LjAuMC4xCmNvbnNvbGUgc2V0IHBvcnQgNTA1MAoKIwojIGNvbnNv bGUgc2V0IHByb21wdCA8cHJvbXB0PgojCiMgU2V0IHRoZSBwcm9tcHQgc3RyaW5nLiAgSGVscHMg aWYgcnVubmluZyBtdWx0aXBsZSBkdG5kJ3MKIwpzZXQgc2hvcnRob3N0bmFtZSBbbGluZGV4IFtz cGxpdCBbaW5mbyBob3N0bmFtZV0gLl0gMF0KY29uc29sZSBzZXQgcHJvbXB0ICIkc2hvcnRob3N0 bmFtZSBkdG4lICIKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIwoj IEFQSSBDb25maWd1cmF0aW9uCiMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIwoKI2FwaSBzZXQgbG9jYWxfcG9ydCA1MDEwCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjCiMKIyBTdG9yYWdlIENvbmZpZ3VyYXRpb24KIwojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgojCiMgc3RvcmFnZSBzZXQgdHlwZSBbIGJlcmtl bGV5ZGIgfCBleHRlcm5hbCB8IG1lbW9yeWRiIF0KIwojIFNldCB0aGUgc3RvcmFnZSBzeXN0ZW0g dG8gYmUgdXNlZAojCnN0b3JhZ2Ugc2V0IHR5cGUgYmVya2VsZXlkYgoKIyB0aGUgZm9sbG93aW5n IGFyZSBmb3IgdXNlIHdpdGggZXh0ZXJuYWwgZGF0YSBzdG9yZXMKIwojIFRoZSBzZXJ2ZXIgcG9y dCB0byBjb25uZWN0IHRvIChvbiBsb2NhbGhvc3QpCiMgTm90ZSB0aGF0IDYyMzQ1IGhhcyBubyBz cGVjaWFsIHNpZ25pZmljYW5jZSAtLSBjaG9zZW4gcmFuZG9tbHkKc3RvcmFnZSBzZXQgc2VydmVy X3BvcnQgNjIzNDUKCiMgVGhlIGV4dGVybmFsIGRhdGEgc3RvcmUgc2NoZW1hIGxvY2F0aW9uLCB3 aGljaCBjYW4gYmUKIyBmb3VuZCBpbiBkdG4yL29hc3lzL3N0b3JhZ2UvRFMueHNkLgpzdG9yYWdl IHNldCBzY2hlbWEgL2V0Yy9EUy54c2QKCgojCiMgRG8gYSBydW50aW1lIGNoZWNrIGZvciB0aGUg c3RhbmRhcmQgbG9jYXRpb25zIGZvciB0aGUgcGVyc2lzdGVudAojIHN0b3JhZ2UgZGlyZWN0b3J5 CiMKc2V0IGRiZGlyICIiCmZvcmVhY2ggZGlyIHsvdmFyL2R0biAvdmFyL3RtcC9kdG59IHsKICAg IGlmIHtbZmlsZSBpc2RpcmVjdG9yeSAkZGlyXX0gewogICAgICAgIHNldCBkYmRpciAkZGlyCiAg ICAgICAgYnJlYWsKICAgIH0KfQoKaWYgeyRkYmRpciA9PSAiIn0gewogICAgcHV0cyBzdGRlcnIg Ik11c3QgY3JlYXRlIC92YXIvZHRuIG9yIC92YXIvdG1wL2R0biBzdG9yYWdlIGRpcmVjdG9yeSIK ICAgIGV4aXQgMQp9CgojCiMgc3RvcmFnZSBzZXQgcGF5bG9hZGRpciA8ZGlyPgojCiMgU2V0IHRo ZSBkaXJlY3RvcnkgdG8gYmUgdXNlZCBmb3IgYnVuZGxlIHBheWxvYWQgZmlsZXMKIwpzdG9yYWdl IHNldCBwYXlsb2FkZGlyIC9ob21lL2RlZmF1bHQvRGVza3RvcC9kdG4vYnVuZGxlcwoKIwojIHN0 b3JhZ2Ugc2V0IGRibmFtZSA8ZGI+CiMKIyBTZXQgdGhlIGRhdGFiYXNlIG5hbWUgKGFwcGVuZGVk IHdpdGggLmRiIGFzIHRoZSBmaWxlbmFtZSBpbiBiZXJrZWxleQojIGRiLCB1c2VkIGFzLWlzIGZv ciBTUUwgdmFyaWFudHMKIwpzdG9yYWdlIHNldCBkYm5hbWUgICAgIERUTgoKIwojIHN0b3JhZ2Ug c2V0IGRiZGlyICAgIDxkaXI+CiMKIwojIFdoZW4gdXNpbmcgYmVya2VsZXkgZGIsIHNldCB0aGUg ZGlyZWN0b3J5IHRvIGJlIHVzZWQgZm9yIHRoZQojIGRhdGFiYXNlIGZpbGVzIGFuZCB0aGUgbmFt ZSBvZiB0aGUgZmlsZXMgYW5kIGVycm9yIGxvZy4KIwpzdG9yYWdlIHNldCBkYmRpciAgICAgIC9o b21lL2RlZmF1bHQvRGVza3RvcC9kdG4vZGIKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMKIwojIFJvdXRpbmcgY29uZmlndXJhdGlvbgojCiMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCiMKIyBTZXQgdGhlIGFsZ29yaXRobSB1c2VkIGZvciBk dG4gcm91dGluZy4KIwojIHJvdXRlIHNldCB0eXBlIFtzdGF0aWMgfCBmbG9vZCB8IG5laWdoYm9y aG9vZCB8IGxpbmtzdGF0ZSB8IGV4dGVybmFsXQojCnJvdXRlIHNldCB0eXBlIHByb3BoZXQKIwoj IHJvdXRlIGxvY2FsX2VpZCA8ZWlkPgojCiMgU2V0IHRoZSBsb2NhbCBhZG1pbmlzdHJhdGl2ZSBp ZCBvZiB0aGlzIG5vZGUuIFRoZSBkZWZhdWx0IGp1c3QgdXNlcwojIHRoZSBpbnRlcm5ldCBob3N0 bmFtZSBwbHVzIHRoZSBhcHBlbmRlZCBzdHJpbmcgIi5kdG4iIHRvIG1ha2UgaXQKIyBjbGVhciB0 aGF0IHRoZSBob3N0bmFtZSBpc24ndCByZWFsbHkgdXNlZCBmb3IgRE5TIGxvb2t1cHMuCiMKcm91 dGUgbG9jYWxfZWlkICJkdG46Ly9kZWZhdWx0LTEwMTVwZW0uZHRuIgoKIwojIEV4dGVybmFsIHJv dXRlciBzcGVjaWZpYyBvcHRpb25zCiMKIyByb3V0ZSBzZXQgc2VydmVyX3BvcnQgODAwMQojIHJv dXRlIHNldCBoZWxsb19pbnRlcnZhbCAzMAojIHJvdXRlIHNldCBzY2hlbWEgIi9ldGMvcm91dGVy LnhzZCIKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIwojIFRDUCBj b252ZXJnZW5jZSBsYXllciBjb25maWd1cmF0aW9uCiMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIwoKIwojIGludGVyZmFjZSBhZGQgW25hbWVdIFtDTF0KIwojIEFkZCBh biBpbnB1dCBpbnRlcmZhY2UgdG8gbGlzdGVuIG9uIGFkZHI6cG9ydCBmb3IgaW5jb21pbmcgYnVu ZGxlcwojIGZyb20gb3RoZXIgdGNwIC8gdWRwIGNvbnZlcmdlbmNlIGxheWVycwojCiMgRm9yIElQ LWJhc2VkIGludGVyZmFjZXMsIGludGVyZmFjZXMgbGlzdGVuIG9uIElOQUREUl9BTlkgcG9ydCA0 NTU2CiMgYnkgZGVmYXVsdC4gVGhlc2UgY2FuIGJlIG92ZXJyaWRkZW4gYnkgdXNpbmcgdGhlIGxv Y2FsX2FkZHIgYW5kL29yCiMgbG9jYWxfcG9ydCBhcmd1bWVudHMuCiNpbnRlcmZhY2UgYWRkIHRj cDAgdGNwIGxvY2FsX2FkZHI9MTkyLjE2OC44MC4xMCBsb2NhbF9wb3J0PTQ1NTYKCgppbnRlcmZh Y2UgYWRkIHVkcDAgdWRwIGxvY2FsX2FkZHI9MTkyLjE2OC44MC4xMCBsb2NhbF9wb3J0PTQ1NTYK CgojCiMgbGluayBhZGQgPG5hbWU+IDxuZXh0aG9wPiA8dHlwZT4gPGNsYXllcj4gPGFyZ3MuLi4+ CiMKIyBBZGQgYSBsaW5rIHRvIGEgcGVlciBub2RlLgojIAojIEZvciBJUC1iYXNlZCBsaW5rcyAo dGNwIG9yIHVkcCksIHRoZSBuZXh0aG9wIHNob3VsZCBjb250YWluIGEgRE5TCiMgaG9zdG5hbWUg b3IgSVAgYWRkcmVzcywgZm9sbG93ZWQgb3B0aW9uYWxseSBieSBhIDogYW5kIGEgcG9ydC4gSWYK IyB0aGUgcG9ydCBpcyBub3Qgc3BlY2lmaWVkLCB0aGUgZGVmYXVsdCBvZiA0NTU2IGlzIHVzZWQu CiMKIyBlLmcuICBsaW5rIGFkZCBsaW5rMSBkdG4uZHRucmcub3JnIE9OREVNQU5EIHRjcAojICAg ICAgIGxpbmsgYWRkIGxpbmsyIGR0bjIuZHRucmcub3JnOjEwMDAwIE9OREVNQU5EIHRjcAoKI2xp bmsgYWRkIGxpbmtfdGNwMiAxOTIuMTY4LjgwLjIyMjo0NTU2IE9OREVNQU5EIHRjcAoKIwojIHJv dXRlIGFkZCA8ZGVzdD4gPGxpbmt8cGVlcj4KIwojIEFkZCBhIHJvdXRlIHRvIHRoZSBnaXZlbiBi dW5kbGUgZW5kcG9pbnQgaWQgcGF0dGVybiA8ZGVzdD4gdXNpbmcgdGhlCiMgc3BlY2lmaWVkIGxp bmsgbmFtZSBvciBwZWVyIGVuZHBvaW50LgojCiMgZS5nLiByb3V0ZSBhZGQgZHRuOi8vaG9zdC5k b21haW4vKiB0Y3AwCgojcm91dGUgYWRkIGR0bjovL2JydW5vLmR0bi8qIGxpbmtfdGNwMgoKIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojCiMgU2VydmljZSBkaXNjb3Zl cnkKIwojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgojCiMgZGlzY292 ZXJ5IGFkZCA8bmFtZT4gPGFmPiA8b3B0cy4uLj4KIyBkaXNjb3ZlcnkgYW5ub3VuY2UgPGNsX25h bWU+IDxkaXNjb3ZlcnlfbmFtZT4gPGNsX3R5cGU+IDxvcHRzLi4uPgojCiMgQWRkIGEgbG9jYWwg bmVpZ2hib3Job29kIGRpc2NvdmVyeSBtb2R1bGUKIwojIGUuZy4gZGlzY292ZXJ5IGFkZCBkaXNj b3ZlcnlfYm9uam91ciBib25qb3VyCgpkaXNjb3ZlcnkgYWRkIHVkcDBkIGlwIHBvcnQ9OTU1NiAK ZGlzY292ZXJ5IGFubm91bmNlIHVkcDAgdWRwMGQgdWRwIGludGVydmFsPTEgY2xfYWRkcj0xOTIu MTY4LjgwLjEwIGNsX3BvcnQ9NDU1NgoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIwojCiMgUGFyYW1ldGVyIFR1bmluZwojCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMKCiMKIyBTZXQgdGhlIHNpemUgdGhyZXNob2xkIGZvciB0aGUgZGFlbW9u IHNvIGFueSBidW5kbGVzIHNtYWxsZXIgdGhhbiB0aGlzCiMgc2l6ZSBtYWludGFpbiBhIHNoYWRv dyBjb3B5IGluIG1lbW9yeSB0byBtaW5pbWl6ZSBkaXNrIGFjY2Vzc2VzLiAKIwojIHBhcmFtIHNl dCBwYXlsb2FkX21lbV90aHJlc2hvbGQgMTYzODQKCiMKIyBUZXN0IG9wdGlvbiB0byBrZWVwIGFs bCBidW5kbGUgZmlsZXMgaW4gdGhlIGZpbGVzeXN0ZW0sIGV2ZW4gYWZ0ZXIgdGhlCiMgYnVuZGxl IGlzIG5vIGxvbmdlciBwcmVzZW50IGF0IHRoZSBkYWVtb24uCiMKIyBwYXJhbSBzZXQgcGF5bG9h ZF90ZXN0X25vX3JlbW92ZSB0cnVlCgojCiMgU2V0IHRoZSBzaXplIGZvciB3aGljaCB0aGUgdGNw IGNvbnZlcmdlbmNlIGxheWVyIHNlbmRzIHBhcnRpYWwgcmVjZXB0aW9uCiMgYWNrbm93bGVkZ2Vt ZW50cy4gVXNlZCB3aXRoIHJlYWN0aXZlIGZyYWdtZW50YXRpb24KIwojIHBhcmFtIHNldCB0Y3Bj bF9wYXJ0aWFsX2Fja19sZW4gNDA5NgoKIwojIFNldCBpZiBidW5kbGVzIGFyZSBhdXRvbWF0aWNh bGx5IGRlbGV0ZWQgYWZ0ZXIgdHJhbnNtaXNzaW9uCiMKIyBwYXJhbSBzZXQgZWFybHlfZGVsZXRp b24gdHJ1ZQoKIyAob3RoZXJzIGV4aXN0IGJ1dCBhcmUgbm90IGZ1bGx5IHJlcHJlc2VudGVkIGhl cmUpCgoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojCiMgRXh0ZW5z aW9uIEJsb2NrIENvbmZpZ3VyYXRpb24KIwojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjCgojCiMgQXR0YWNoIGFuIEFnZSBFeHRlbnNpb24gQmxvY2sgdG8gb3V0Z29pbmcg YnVuZGxlcwojCiMgYmxvY2sgc2V0IGFnZV9vdXRib3VuZF9lbmFibGVkIGZhbHNlCgojCiMgUHJv Y2VzcyB0aGUgQWdlIEV4dGVuc2lvbiBCbG9jayBvbiBpbmNvbWluZyBidW5kbGVzCiMKIyBibG9j ayBzZXQgYWdlX2luYm91bmRfcHJvY2Vzc2luZyB0cnVlCgojCiMgWmVybyBvdXQgdGhlIENyZWF0 aW9uIFRpbWVzdGFtcCBUaW1lIG9uIGJ1bmRsZXMKIwojIGJsb2NrIHNldCBhZ2VfemVyb19jcmVh dGlvbl90c190aW1lIGZhbHNlCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCiMKIyBCUFEgY2FjaGluZyBjb250cm9sCiMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIwoKIwojIFR1cm4gb24gY2FjaGluZyBvZiBwYXNzaW5nIGJ1bmRsZXMgd2l0 aCBCUFEgYmxvY2tzCiMKIyBicHEgZW5hYmxlCiMKCgpsb2cgL2R0bmQgaW5mbyAiZHRuZCBjb25m aWd1cmF0aW9uIHBhcnNpbmcgY29tcGxldGUiCgojIyBlbWFjcyBzZXR0aW5ncyB0byB1c2UgdGNs LW1vZGUgYnkgZGVmYXVsdAojIyBMb2NhbCBWYXJpYWJsZXM6ICoqKgojIyBtb2RlOnRjbCAqKioK IyMgRW5kOiAqKioK --_003_90494CFA1222DC45A1855F79747890D81155375EDBXPRD0210MB358_-- From sickmind@lavabit.com Thu Feb 14 23:11:19 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27921F8967 for ; Thu, 14 Feb 2013 23:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgqUidGAbTgI for ; Thu, 14 Feb 2013 23:11:11 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12821F8964 for ; Thu, 14 Feb 2013 23:11:11 -0800 (PST) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id B760711B9A9 for ; Fri, 15 Feb 2013 01:11:10 -0600 (CST) Received: from localhost (92.53.115.234) by lavabit.com with ESMTP id YMUSXW3IABVF for ; Fri, 15 Feb 2013 01:11:09 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=O5Wlih0QAdp8CQx2IKPhh+7fWIWwfoYpU1k9o0glIMtv7YJ3QyoML2IQaRHpykTKfZTHR3Kyp+a04X2jodlgl7/Q9Dp2uc+s+zYv05lFCMCEF4C1tjDmtSO4RxKGXbkR6IQaBJuLfNLlfETmYB7YEfARtXPmsaQHhafGFMbE5h8=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Fri, 15 Feb 2013 07:10:18 +0000 From: Lana Black To: dtn-users maillist Message-ID: <20130215071018.GA6031@kasumi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dtn-users] EthConvergenceLayer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 07:11:19 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I managed to get ethernet convergence layer working. Changes were made to both DTN and oasys. See the patches attached. Any chance for this to be commited? --45Z9DzgjV8m4Oswq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="oasys.patch" diff -r 4cf51fd37f22 util/URI.cc --- a/util/URI.cc Tue Jul 24 16:09:54 2012 +0100 +++ b/util/URI.cc Fri Feb 15 07:02:30 2013 +0000 @@ -231,9 +231,14 @@ } host_end++; // include '[' character } else { - host_end = authority.find(':', curr_pos); - if (host_end == std::string::npos) { + // Special case for ethernet uri + if(this->scheme() == "eth") { host_end = authority.length(); + } else { + host_end = authority.find(':', curr_pos); + if (host_end == std::string::npos) { + host_end = authority.length(); + } } } @@ -418,6 +423,11 @@ return validate_ip_literal(host.substr(1, host.length() - 2)); } + // check for ethernet literal + if(this->scheme() == "eth") { + return validate_eth_literal(host); + } + // check for valid characters for (unsigned int i = 0; i < host.length(); ++i) { char c = host.at(i); @@ -872,6 +882,29 @@ } //---------------------------------------------------------------------- +uri_parse_err_t URI::validate_eth_literal(const std::string& host) const +{ + if(host.length() != 17) { + log_debug_p(URI_LOG, "URI::validate_eth_literal: bad host"); + return URI_PARSE_BAD_HOST; + } + + for(int i = 0; i < host.length(); i++) { + if((i + 1) % 3) { + if(is_hexdig(host.at(i))) + continue; + } else { + if(host.at(i) == ':') + continue; + } + + return URI_PARSE_BAD_HOST; + } + + return URI_PARSE_OK; +} + +//---------------------------------------------------------------------- void URI::normalize_path() { diff -r 4cf51fd37f22 util/URI.h --- a/util/URI.h Tue Jul 24 16:09:54 2012 +0100 +++ b/util/URI.h Fri Feb 15 07:02:30 2013 +0000 @@ -275,6 +275,7 @@ uri_parse_err_t validate_query() const; uri_parse_err_t validate_fragment() const; uri_parse_err_t validate_ip_literal(const std::string& host) const; + uri_parse_err_t validate_eth_literal(const std::string& host) const; /** * Normalize the URI to the standard format as described in RFC 3986 --45Z9DzgjV8m4Oswq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="dtn-eth.patch" diff -r 660ce8ebcd3b servlib/conv_layers/EthConvergenceLayer.cc --- a/servlib/conv_layers/EthConvergenceLayer.cc Thu Jan 10 17:14:59 2013 +0000 +++ b/servlib/conv_layers/EthConvergenceLayer.cc Fri Feb 15 07:06:08 2013 +0000 @@ -23,12 +23,14 @@ #include #include +#include #include #include #include #include #include #include +#include #include #include @@ -59,6 +61,7 @@ EthConvergenceLayer::Params::serialize(oasys::SerializeAction *a) { a->process("beacon_interval", &beacon_interval_); + a->process("interface", &if_name_); } /****************************************************************************** @@ -100,6 +103,7 @@ oasys::OptParser p; p.addopt(new oasys::UIntOpt("beacon_interval", ¶ms->beacon_interval_)); + p.addopt(new oasys::StringOpt("interface", ¶ms->if_name_)); if (! p.parse(argc, argv, invalidp)) { return false; @@ -169,7 +173,7 @@ Receiver *receiver = (Receiver *)iface->cl_info(); receiver->set_should_stop(); - // receiver->interrupt_from_io(); + //receiver->interrupt(); while (! receiver->is_stopped()) { oasys::Thread::yield(); } @@ -186,6 +190,7 @@ ASSERT(link != NULL); ASSERT(!link->isdeleted()); ASSERT(link->cl_info() != NULL); + Params* link_params = dynamic_cast(link->cl_info()); log_debug("EthConvergenceLayer::open_contact: " "opening contact to link *%p", link.object()); @@ -199,7 +204,7 @@ } // create a new connection for the contact - Sender* sender = new Sender(((EthCLInfo*)link->cl_info())->if_name_, + Sender* sender = new Sender(link_params->if_name_.c_str(), link->contact()); contact->set_cl_info(sender); @@ -265,6 +270,7 @@ ASSERT(params != NULL); buf->appendf("beacon_interval: %u\n", params->beacon_interval_); + buf->appendf("interface: %s\n", params->if_name_.c_str()); } //---------------------------------------------------------------------- @@ -403,8 +409,9 @@ link->name()); return; } - ASSERT(link->cl_info() == NULL); - link->set_cl_info(new EthCLInfo(if_name_)); + ASSERT(link->cl_info() != NULL); + Params *params = dynamic_cast(link->cl_info()); + params->if_name_ = if_name_; l.unlock(); } @@ -418,15 +425,16 @@ } ASSERT(link->cl_info() != NULL); - ASSERT(strcmp(((EthCLInfo*)link->cl_info())->if_name_, if_name_) == 0); + ASSERT(dynamic_cast(link->cl_info())->if_name_ == if_name_); if(!link->isavailable()) { log_info("EthConvergenceLayer::Receiver::process_data: " "Got beacon for previously unavailable link %s", link->name()); - // XXX/demmer something should be done here to kick the link... - log_err("XXX/demmer do something about link availability"); + // Kicking the link available here + BundleDaemon::post( + new LinkStateChangeRequest(link, Link::OPEN, ContactUpEvent::DISCOVERY)); } /** @@ -434,14 +442,14 @@ * will delete it when it bubbles to the top of the timer * queue. Then create a new timer. */ - BeaconTimer *timer = ((EthCLInfo*)link->cl_info())->timer; + BeaconTimer *timer = ((Params*)link->cl_info())->timer; if (timer) timer->cancel(); timer = new BeaconTimer(next_hop_string); timer->schedule_in(ETHCL_BEACON_TIMEOUT_INTERVAL); - ((EthCLInfo*)link->cl_info())->timer = timer; + ((Params*)link->cl_info())->timer = timer; l.unlock(); } @@ -488,6 +496,7 @@ { int sock; int cc; + int flags; struct sockaddr_ll iface; unsigned char buffer[MAX_ETHER_PACKET]; @@ -497,6 +506,16 @@ "Couldn't open socket."); exit(1); } + + // Make the socket non-blocking + flags = fcntl(sock, F_GETFL, 0); + if(flags == -1) { + perror("fcntl"); + log_err("EthConvergenceLayer::Receiver::run() " + "Couldn't get socket flags."); + exit(1); + } + fcntl(sock, F_SETFL, flags | O_NONBLOCK); // figure out the interface index of the device with name if_name_ struct ifreq req; @@ -517,19 +536,23 @@ while(true) { cc=read (sock, buffer, MAX_ETHER_PACKET); if(cc<=0) { - perror("EthConvergenceLayer::Receiver::run()"); - exit(1); - } - struct ether_header* hdr=(struct ether_header*)buffer; + // EAGAIN means we haven't received anything yet + if(errno != EAGAIN) { + perror("EthConvergenceLayer::Receiver::run()"); + exit(1); + } + } else { + struct ether_header* hdr=(struct ether_header*)buffer; - if(ntohs(hdr->ether_type)==ETHERTYPE_DTN) { - process_data(buffer, cc); - } - else if(ntohs(hdr->ether_type)!=0x800) - { - log_err("Got non-DTN packet in Receiver, type %4X.", - ntohs(hdr->ether_type)); - // exit(1); + if(ntohs(hdr->ether_type)==ETHERTYPE_DTN) { + process_data(buffer, cc); + } + else if(ntohs(hdr->ether_type)!=0x800) + { + log_err("Got non-DTN packet in Receiver, type %4X.", + ntohs(hdr->ether_type)); + // exit(1); + } } if(should_stop()) @@ -546,11 +569,13 @@ /** * Constructor for the active connection side of a connection. */ -EthConvergenceLayer::Sender::Sender(char* if_name, +EthConvergenceLayer::Sender::Sender(const char* if_name, const ContactRef& contact) : Logger("EthConvergenceLayer::Sender", "/dtn/cl/eth/sender"), contact_(contact.object(), "EthConvergenceLayer::Sender") { + ASSERT(strlen(if_name) > 0); + struct ifreq req; struct sockaddr_ll iface; LinkRef link = contact->link(); diff -r 660ce8ebcd3b servlib/conv_layers/EthConvergenceLayer.h --- a/servlib/conv_layers/EthConvergenceLayer.h Thu Jan 10 17:14:59 2013 +0000 +++ b/servlib/conv_layers/EthConvergenceLayer.h Fri Feb 15 07:06:08 2013 +0000 @@ -82,29 +82,6 @@ } __attribute__((packed)); /** - * Data state of a Eth cl - * - */ - class EthCLInfo : public CLInfo { - public: - EthCLInfo(char* if_name) { - memset(if_name_,0,IFNAMSIZ); - strcpy(if_name_,if_name); - timer = NULL; - } - - ~EthCLInfo() { - if(timer) - delete timer; - } - - // Name of the device - char if_name_[IFNAMSIZ]; - - BeaconTimer* timer; - }; - - /** * Constructor. */ EthConvergenceLayer(); @@ -177,7 +154,15 @@ */ virtual void serialize(oasys::SerializeAction *a); + ~Params() { + if(timer) + delete timer; + } + u_int32_t beacon_interval_; ///< Beacon Interval + std::string if_name_; ///< Interface name to bind sender to + + BeaconTimer *timer; ///< XXX this should be moved somewhere else }; /** @@ -241,7 +226,7 @@ /** * Constructor for the active connection side of a connection. */ - Sender(char* if_name, const ContactRef& contact); + Sender(const char* if_name, const ContactRef& contact); /** * Destructor. --45Z9DzgjV8m4Oswq-- From alexmcm@gmail.com Fri Feb 15 00:17:45 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DCC21F8801 for ; Fri, 15 Feb 2013 00:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7zOolhxrYeA for ; Fri, 15 Feb 2013 00:17:44 -0800 (PST) Received: from mail-we0-x22d.google.com (we-in-x022d.1e100.net [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 30FAA21F8A09 for ; Fri, 15 Feb 2013 00:17:44 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so2627811wey.32 for ; Fri, 15 Feb 2013 00:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:subject:message-id:from:to:cc:mime-version :content-type:content-transfer-encoding; bh=/poCSY0VkgbCdGoJ1iD2nwQlD8RWwzz00jimB5zGmYo=; b=siItnxsATpoRaun/u5xnqxzai5i/dd6LjD2bY0sicwm+cdNTkXzEiufXn/d3Ip+Xb9 gOIg6Lkjj83+MqeEyYmmIXtp3f+QrTQjmzy0f1VcZkTyyFGbAqw2FRmRkpPPUFm6o+q4 j/PdtSkpjUbSh5BvGrYl7whaCGyR2nH+Qcv6LVaiLdHd/CdXlz59TUB3/tnnLMs5NHPG Iurb494JEm0AIXP6sOjDpQGQtAv37YH4iZtH4N6K8lV1iGdAOMi5h7XKOW8UwCUEI9p8 e+rCxiHN8vIwMNbo+pH87otfIPCo4MgjVlrZ77SvlZYi/7JTsRVTA2IgAEJhs6smIppN OaKg== X-Received: by 10.194.83.105 with SMTP id p9mr2322052wjy.56.1360916260189; Fri, 15 Feb 2013 00:17:40 -0800 (PST) Received: from [192.168.1.67] (84-203-38-124.mysmart.ie. [84.203.38.124]) by mx.google.com with ESMTPS id q13sm4038867wie.0.2013.02.15.00.17.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 00:17:39 -0800 (PST) Sender: Alex McMahon Date: Fri, 15 Feb 2013 08:17:35 +0000 Message-ID: <0xiwepmxmatr6hunapcwgv6u.1360916255953@email.android.com> From: Alex McMahon To: Lana Black MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: dtn-users maillist Subject: Re: [dtn-users] EthConvergenceLayer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 08:17:45 -0000 SGkgTGFuYQoKWWVzLCBJIHNoYWxsIHRlc3QgdGhlIHBhdGNoZXMgYW5kIGFsbCBnb2luZyB3ZWxs LCBjb21taXQgdGhlbS4KCkFsbCB0aGUgYmVzdApBbGV4CgpMYW5hIEJsYWNrIDxzaWNrbWluZEBs YXZhYml0LmNvbT4gd3JvdGU6Cgo+SGksCj4KPkkgbWFuYWdlZCB0byBnZXQgZXRoZXJuZXQgY29u dmVyZ2VuY2UgbGF5ZXIgd29ya2luZy4gQ2hhbmdlcyB3ZXJlIG1hZGUKPnRvIGJvdGggRFROIGFu ZCBvYXN5cy4gU2VlIHRoZSBwYXRjaGVzIGF0dGFjaGVkLiBBbnkgY2hhbmNlIGZvciB0aGlzIHRv Cj5iZSBjb21taXRlZD8KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPmR0bi11c2VycyBtYWlsaW5nIGxpc3QKPmR0bi11c2Vyc0BpcnRmLm9yZwo+aHR0 cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG4tdXNlcnMK From sickmind@lavabit.com Fri Feb 15 03:02:32 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FBD21F8532 for ; Fri, 15 Feb 2013 03:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci08Gbu5D8Sx for ; Fri, 15 Feb 2013 03:02:32 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id DDBCB21F852C for ; Fri, 15 Feb 2013 03:02:31 -0800 (PST) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 91DB111B9AD; Fri, 15 Feb 2013 05:02:31 -0600 (CST) Received: from localhost (92.53.115.234) by lavabit.com with ESMTP id N4H9LVDWSZRG; Fri, 15 Feb 2013 05:02:30 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=JyRzT36bph7LCuwTkLPqirs5h6SpnnCPAcGT8+Nh4/CBEJAEFgtuSZomU1JQf7UvuqNsO9UxRo6ITvKGldSQMrmbHMC+LTpwgcEhrVAIJ3ZBfVIRYqzwgKAHPVbB5kigtE5L0wWZ7xmCX2kaOJkCCxlK1gB9Fh3MoX7vLK4nJRQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Date: Fri, 15 Feb 2013 11:01:39 +0000 From: Lana Black To: Alex McMahon Message-ID: <20130215110138.GA21761@kasumi> References: <0xiwepmxmatr6hunapcwgv6u.1360916255953@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0xiwepmxmatr6hunapcwgv6u.1360916255953@email.android.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dtn-users maillist Subject: Re: [dtn-users] EthConvergenceLayer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:02:32 -0000 On 08:17 Fri 15 Feb , Alex McMahon wrote: > Hi Lana > > Yes, I shall test the patches and all going well, commit them. > > All the best > Alex > > Lana Black wrote: > > >Hi, > > > >I managed to get ethernet convergence layer working. Changes were made > >to both DTN and oasys. See the patches attached. Any chance for this to > >be commited? > > > >_______________________________________________ > >dtn-users mailing list > >dtn-users@irtf.org > >https://www.irtf.org/mailman/listinfo/dtn-users Thank you for the quick reply, Alex. Those patches fix only basic functions, and EthCL still requires some work (e.g. fragmentation support). At the moment bundles larger than the interface's MTU cannot be sent. From elwynd@folly.org.uk Fri Feb 15 03:09:27 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6B021F8A7E for ; Fri, 15 Feb 2013 03:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-YSoXj2Tw2n for ; Fri, 15 Feb 2013 03:09:25 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id 4274B21F8A7B for ; Fri, 15 Feb 2013 03:09:25 -0800 (PST) Received: from aptilo1-sesb.ericsson.net ([192.165.126.77] helo=[10.156.69.237]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U6JAR-0007HV-IK for dtn-users@irtf.org; Fri, 15 Feb 2013 11:09:23 +0000 Message-ID: <511E1760.3030200@folly.org.uk> Date: Fri, 15 Feb 2013 12:09:20 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dtn-users maillist References: <20130215071018.GA6031@kasumi> In-Reply-To: <20130215071018.GA6031@kasumi> Content-Type: multipart/alternative; boundary="------------020004030904030007080209" Subject: Re: [dtn-users] EthConvergenceLayer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "elwynd@folly.org.uk" List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:09:27 -0000 This is a multi-part message in MIME format. --------------020004030904030007080209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Lana. Thanks for this... I was actually thinking about how to get the Ethernet convergence layer working again when I did the last set of changes (3557) - I tried it and reelized it didn't work but no time to get it working. Could you write two sets of 'a few words' to go with the patches: 1. For the change commentary 2. Manual notes for how to configure a couple of nodes to use the Ethernet convergence layer. Regards, Elwyn On 15/02/13 08:10, Lana Black wrote: > Hi, > > I managed to get ethernet convergence layer working. Changes were made > to both DTN and oasys. See the patches attached. Any chance for this to > be commited? > > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users --------------020004030904030007080209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi, Lana.

Thanks for this... I was actually thinking about how to get the Ethernet convergence layer working again when I did the last set of changes (3557) - I tried it and reelized it didn't work but no time to get it working.

Could you write two sets of 'a few words' to go with the patches:
1.  For the change commentary
2.  Manual notes for how to configure a couple of nodes to use the Ethernet convergence layer.

Regards,
Elwyn


On 15/02/13 08:10, Lana Black wrote:
Hi,

I managed to get ethernet convergence layer working. Changes were made
to both DTN and oasys. See the patches attached. Any chance for this to
be commited?



_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users


--------------020004030904030007080209-- From sickmind@lavabit.com Sun Feb 17 02:43:50 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FA121F87EA for ; Sun, 17 Feb 2013 02:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMx4ShkgULdC for ; Sun, 17 Feb 2013 02:43:49 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D221F87D5 for ; Sun, 17 Feb 2013 02:43:48 -0800 (PST) Received: from b.earth.lavabit.com (b.earth.lavabit.com [192.168.111.11]) by karen.lavabit.com (Postfix) with ESMTP id 8C90411B8F5; Sun, 17 Feb 2013 04:43:48 -0600 (CST) Received: from localhost (pppoe.178-66-164-34.dynamic.avangarddsl.ru [178.66.164.34]) by lavabit.com with ESMTP id CMJXY3SQRY41; Sun, 17 Feb 2013 04:43:48 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=eoukM7hO+KEC2bVak4wAANeOikuC4sahelJDtimtcP+uRZDqrTp/elVFz1tJ5dYIIFkIDl5R5P6CM3eud4FXEwxktcM8N0ml2Ct7fA/cZgpzPq4G6pqxdNuArhW5UqfKd8UXviUtcEbwXcrmL3jtedccnwA2mLHxY87iVqXLcKs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Date: Sun, 17 Feb 2013 10:42:50 +0000 From: Lana Black To: Elwyn Davies Message-ID: <20130217104250.GA1414@kasumi> References: <20130215071018.GA6031@kasumi> <511E1675.6030907@dial.pipex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <511E1675.6030907@dial.pipex.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dtn-users maillist Subject: Re: [dtn-users] EthConvergenceLayer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 10:43:50 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 12:05 Fri 15 Feb , Elwyn Davies wrote: >Hi, Lana. > >Thanks for this... I was actually thinking about how to get the >Ethernet >convergence layer working again when I did the last set of changes >(3557) - I tried it and reelized it didn't work but no time to get it >working. > >Could you write two sets of 'a few words' to go with the patches: >1. For the change commentary >2. Manual notes for how to configure a couple of nodes to use the >Ethernet convergence layer. > >Regards, >Elwyn Sure. The oasys patch fixes the ethernet address validation. The EthCL patch reorganizes parameters handling code and makes the receiver socket non-blocking to allow graceful exit. To configure a node one needs to do the following: add local network interface: >interface add string://eth0 eth add link to the remote host: >link add host0 eth interface=eth0 please note that the interface parameter is mandatory because there is no way to figure what interface the host is connected to. and finally add the route: >route add dtn://host0.dtn/* host0 P.S. dtn-eth.patch contains a error which results in excessive cpu load. Please see the patch attached to this message. --9jxsPFA5p3P2qPhR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="dtn-eth2.patch" diff -r 660ce8ebcd3b servlib/conv_layers/EthConvergenceLayer.cc --- a/servlib/conv_layers/EthConvergenceLayer.cc Thu Jan 10 17:14:59 2013 +0000 +++ b/servlib/conv_layers/EthConvergenceLayer.cc Fri Feb 15 15:33:32 2013 +0000 @@ -23,12 +23,15 @@ #include #include +#include #include #include #include #include #include #include +#include +#include #include #include @@ -59,6 +62,7 @@ EthConvergenceLayer::Params::serialize(oasys::SerializeAction *a) { a->process("beacon_interval", &beacon_interval_); + a->process("interface", &if_name_); } /****************************************************************************** @@ -100,6 +104,7 @@ oasys::OptParser p; p.addopt(new oasys::UIntOpt("beacon_interval", ¶ms->beacon_interval_)); + p.addopt(new oasys::StringOpt("interface", ¶ms->if_name_)); if (! p.parse(argc, argv, invalidp)) { return false; @@ -169,7 +174,7 @@ Receiver *receiver = (Receiver *)iface->cl_info(); receiver->set_should_stop(); - // receiver->interrupt_from_io(); + //receiver->interrupt(); while (! receiver->is_stopped()) { oasys::Thread::yield(); } @@ -186,6 +191,7 @@ ASSERT(link != NULL); ASSERT(!link->isdeleted()); ASSERT(link->cl_info() != NULL); + Params* link_params = dynamic_cast(link->cl_info()); log_debug("EthConvergenceLayer::open_contact: " "opening contact to link *%p", link.object()); @@ -199,7 +205,7 @@ } // create a new connection for the contact - Sender* sender = new Sender(((EthCLInfo*)link->cl_info())->if_name_, + Sender* sender = new Sender(link_params->if_name_.c_str(), link->contact()); contact->set_cl_info(sender); @@ -265,6 +271,7 @@ ASSERT(params != NULL); buf->appendf("beacon_interval: %u\n", params->beacon_interval_); + buf->appendf("interface: %s\n", params->if_name_.c_str()); } //---------------------------------------------------------------------- @@ -403,8 +410,9 @@ link->name()); return; } - ASSERT(link->cl_info() == NULL); - link->set_cl_info(new EthCLInfo(if_name_)); + ASSERT(link->cl_info() != NULL); + Params *params = dynamic_cast(link->cl_info()); + params->if_name_ = if_name_; l.unlock(); } @@ -418,15 +426,16 @@ } ASSERT(link->cl_info() != NULL); - ASSERT(strcmp(((EthCLInfo*)link->cl_info())->if_name_, if_name_) == 0); + ASSERT(dynamic_cast(link->cl_info())->if_name_ == if_name_); if(!link->isavailable()) { log_info("EthConvergenceLayer::Receiver::process_data: " "Got beacon for previously unavailable link %s", link->name()); - // XXX/demmer something should be done here to kick the link... - log_err("XXX/demmer do something about link availability"); + // Kicking the link available here + BundleDaemon::post( + new LinkStateChangeRequest(link, Link::OPEN, ContactUpEvent::DISCOVERY)); } /** @@ -434,14 +443,14 @@ * will delete it when it bubbles to the top of the timer * queue. Then create a new timer. */ - BeaconTimer *timer = ((EthCLInfo*)link->cl_info())->timer; + BeaconTimer *timer = ((Params*)link->cl_info())->timer; if (timer) timer->cancel(); timer = new BeaconTimer(next_hop_string); timer->schedule_in(ETHCL_BEACON_TIMEOUT_INTERVAL); - ((EthCLInfo*)link->cl_info())->timer = timer; + ((Params*)link->cl_info())->timer = timer; l.unlock(); } @@ -488,6 +497,7 @@ { int sock; int cc; + int flags; struct sockaddr_ll iface; unsigned char buffer[MAX_ETHER_PACKET]; @@ -497,6 +507,16 @@ "Couldn't open socket."); exit(1); } + + // Make the socket non-blocking + flags = fcntl(sock, F_GETFL, 0); + if(flags == -1) { + perror("fcntl"); + log_err("EthConvergenceLayer::Receiver::run() " + "Couldn't get socket flags."); + exit(1); + } + fcntl(sock, F_SETFL, flags | O_NONBLOCK); // figure out the interface index of the device with name if_name_ struct ifreq req; @@ -517,23 +537,30 @@ while(true) { cc=read (sock, buffer, MAX_ETHER_PACKET); if(cc<=0) { - perror("EthConvergenceLayer::Receiver::run()"); - exit(1); - } - struct ether_header* hdr=(struct ether_header*)buffer; + // EAGAIN means we haven't received anything yet + if(errno != EAGAIN) { + perror("EthConvergenceLayer::Receiver::run()"); + exit(1); + } + } else { + struct ether_header* hdr=(struct ether_header*)buffer; - if(ntohs(hdr->ether_type)==ETHERTYPE_DTN) { - process_data(buffer, cc); - } - else if(ntohs(hdr->ether_type)!=0x800) - { - log_err("Got non-DTN packet in Receiver, type %4X.", - ntohs(hdr->ether_type)); - // exit(1); + if(ntohs(hdr->ether_type)==ETHERTYPE_DTN) { + process_data(buffer, cc); + } + else if(ntohs(hdr->ether_type)!=0x800) + { + log_err("Got non-DTN packet in Receiver, type %4X.", + ntohs(hdr->ether_type)); + // exit(1); + } } if(should_stop()) break; + + // Sleep 1/10000th second here to prevent excessive cpu load + usleep(100); } } @@ -546,11 +573,13 @@ /** * Constructor for the active connection side of a connection. */ -EthConvergenceLayer::Sender::Sender(char* if_name, +EthConvergenceLayer::Sender::Sender(const char* if_name, const ContactRef& contact) : Logger("EthConvergenceLayer::Sender", "/dtn/cl/eth/sender"), contact_(contact.object(), "EthConvergenceLayer::Sender") { + ASSERT(strlen(if_name) > 0); + struct ifreq req; struct sockaddr_ll iface; LinkRef link = contact->link(); diff -r 660ce8ebcd3b servlib/conv_layers/EthConvergenceLayer.h --- a/servlib/conv_layers/EthConvergenceLayer.h Thu Jan 10 17:14:59 2013 +0000 +++ b/servlib/conv_layers/EthConvergenceLayer.h Fri Feb 15 15:33:32 2013 +0000 @@ -82,29 +82,6 @@ } __attribute__((packed)); /** - * Data state of a Eth cl - * - */ - class EthCLInfo : public CLInfo { - public: - EthCLInfo(char* if_name) { - memset(if_name_,0,IFNAMSIZ); - strcpy(if_name_,if_name); - timer = NULL; - } - - ~EthCLInfo() { - if(timer) - delete timer; - } - - // Name of the device - char if_name_[IFNAMSIZ]; - - BeaconTimer* timer; - }; - - /** * Constructor. */ EthConvergenceLayer(); @@ -177,7 +154,15 @@ */ virtual void serialize(oasys::SerializeAction *a); + ~Params() { + if(timer) + delete timer; + } + u_int32_t beacon_interval_; ///< Beacon Interval + std::string if_name_; ///< Interface name to bind sender to + + BeaconTimer *timer; ///< XXX this should be moved somewhere else }; /** @@ -241,7 +226,7 @@ /** * Constructor for the active connection side of a connection. */ - Sender(char* if_name, const ContactRef& contact); + Sender(const char* if_name, const ContactRef& contact); /** * Destructor. --9jxsPFA5p3P2qPhR-- From sickmind@lavabit.com Sun Feb 17 14:53:31 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE82B21F8A52 for ; Sun, 17 Feb 2013 14:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHEIE6RV10Ku for ; Sun, 17 Feb 2013 14:53:30 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id AD7B721F8A48 for ; Sun, 17 Feb 2013 14:53:30 -0800 (PST) Received: from b.earth.lavabit.com (b.earth.lavabit.com [192.168.111.11]) by karen.lavabit.com (Postfix) with ESMTP id 2A57111B87B for ; Sun, 17 Feb 2013 16:53:30 -0600 (CST) Received: from localhost (pppoe.178-66-164-34.dynamic.avangarddsl.ru [178.66.164.34]) by lavabit.com with ESMTP id A2D34CS9L3VG for ; Sun, 17 Feb 2013 16:53:30 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=emZbUfySddKRm8muXLVNz47W/CwL/dumES4DOdcueXKAZfSzvlY6Qgz9GZtEjurz0i2SNj33kCVbr7/9MvpB7xhntl5cyz7fsg3UI0EzTbIaEOPgpn1X2yiyiLPXZql5iGrA+lwhW6QE0rTrSRJGg/14Q8pe7irq94SY1UWNiuU=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Sun, 17 Feb 2013 22:53:26 +0000 From: Lana Black To: dtn-users maillist Message-ID: <20130217225326.GA3067@glow> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dtn-users] oasys and tcl 8.6 support X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 22:53:31 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The patch attached adds support for the newer Tcl version. Tcl 8.6 drops direct access to several Tcl_Interp fields in favor of API functions. Also, since some pre 8.6 installations don't have Tcl_GetErrorLine() function, we have to check its presence and build our implementation in case of absence. Tested on Tcl versions 8.5 and 8.6. Don't forget to run build-configure.sh script after applying the patch. --YiEDa0DAkWCtVeE4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="tcl.patch" diff -r 4cf51fd37f22 aclocal/tcl.ac --- a/aclocal/tcl.ac Tue Jul 24 16:09:54 2012 +0100 +++ b/aclocal/tcl.ac Sun Feb 17 22:42:26 2013 +0000 @@ -22,7 +22,7 @@ dnl Main macro for finding a usable tcl installation dnl AC_DEFUN(AC_CONFIG_TCL, [ - ac_tclvers='8.5 8.4 8.3' + ac_tclvers='8.6 8.5 8.4 8.3' ac_tcldir='system' AC_ARG_WITH(tcl, @@ -83,6 +83,12 @@ EXTLIB_LDFLAGS="$EXTLIB_LDFLAGS $TCL_LDFLAGS" AC_SUBST(TCL_LDFLAGS) + + dnl + dnl Check for some APIs + dnl + AC_SEARCH_LIBS(Tcl_GetErrorLine, tcl, + [AC_DEFINE([HAVE_TCL_GETERRORLINE], [1], [Define if Tcl has Tcl_GetErrorLine function.])]) ]) dnl diff -r 4cf51fd37f22 tclcmd/TclCommand.cc --- a/tclcmd/TclCommand.cc Tue Jul 24 16:09:54 2012 +0100 +++ b/tclcmd/TclCommand.cc Sun Feb 17 22:42:26 2013 +0000 @@ -70,7 +70,7 @@ if (Tcl_Init(interp_) != TCL_OK) { StringBuffer err("initialization problem calling Tcl_Init: %s\n" "(this is not a fatal error, continuing initialization...)\n\n", - interp_->result); + Tcl_GetStringResult(interp_)); log_multiline(LOG_WARN, err.c_str()); } @@ -99,7 +99,7 @@ // overwrite the string value) char* cmd = strdup(INIT_COMMAND); if (Tcl_Eval(interp_, cmd) != TCL_OK) { - log_err("error in init commands: \"%s\"", interp_->result); + log_err("error in init commands: \"%s\"", Tcl_GetStringResult(interp_)); return TCL_ERROR; } free(cmd); @@ -163,7 +163,7 @@ if (err != TCL_OK) { logf(LOG_ERR, "error: line %d: '%s':\n%s", - interp_->errorLine, Tcl_GetStringResult(interp_), + Tcl_GetErrorLine(interp_), Tcl_GetStringResult(interp_), Tcl_GetVar(interp_, "errorInfo", TCL_GLOBAL_ONLY)); } @@ -193,7 +193,7 @@ if (err != TCL_OK) { logf(LOG_ERR, "error: line %d: '%s':\n%s", - interp_->errorLine, Tcl_GetStringResult(interp_), + Tcl_GetErrorLine(interp_), Tcl_GetStringResult(interp_), Tcl_GetVar(interp_, "errorInfo", TCL_GLOBAL_ONLY)); } @@ -211,7 +211,7 @@ if (err != TCL_OK) { logf(LOG_ERR, "error: line %d: '%s':\n%s", - interp_->errorLine, Tcl_GetStringResult(interp_), + Tcl_GetErrorLine(interp_), Tcl_GetStringResult(interp_), Tcl_GetVar(interp_, "errorInfo", TCL_GLOBAL_ONLY)); } @@ -225,7 +225,7 @@ StringBuffer cmd("set command_logpath %s", logpath()); if (Tcl_Eval(interp_, const_cast(cmd.c_str())) != TCL_OK) { log_err("tcl error setting command_logpath: \"%s\"", - interp_->result); + Tcl_GetStringResult(interp_)); } } @@ -240,7 +240,7 @@ if (Tcl_Eval(interp_, const_cast(cmd.c_str())) != TCL_OK) { log_err("tcl error starting command_server: \"%s\"", - interp_->result); + Tcl_GetStringResult(interp_)); } } @@ -256,7 +256,7 @@ #endif if (Tcl_Eval(interp_, const_cast(cmd.c_str())) != TCL_OK) { - log_err("tcl error in command_loop: \"%s\"", interp_->result); + log_err("tcl error in command_loop: \"%s\"", Tcl_GetStringResult(interp_)); } } @@ -266,7 +266,7 @@ { set_command_logpath(); if (Tcl_Eval(interp_, "event_loop") != TCL_OK) { - log_err("tcl error in event_loop: \"%s\"", interp_->result); + log_err("tcl error in event_loop: \"%s\"", Tcl_GetStringResult(interp_)); } } @@ -275,7 +275,7 @@ TclCommandInterp::exit_event_loop() { if (Tcl_Eval(interp_, "exit_event_loop") != TCL_OK) { - log_err("tcl error in event_loop: \"%s\"", interp_->result); + log_err("tcl error in event_loop: \"%s\"", Tcl_GetStringResult(interp_)); } } diff -r 4cf51fd37f22 tclcmd/TclCommand.h --- a/tclcmd/TclCommand.h Tue Jul 24 16:09:54 2012 +0100 +++ b/tclcmd/TclCommand.h Sun Feb 17 22:42:26 2013 +0000 @@ -32,6 +32,16 @@ #include "../util/Singleton.h" #include "../util/StringBuffer.h" +/** + * Workaround for older tcl versions + */ +#ifndef HAVE_TCL_GETERRORLINE +static inline int Tcl_GetErrorLine(Tcl_Interp *interp) +{ + return interp->errorLine; +} +#endif + namespace oasys { // forward decls --YiEDa0DAkWCtVeE4-- From sickmind@lavabit.com Tue Feb 19 04:43:56 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD5621F89FD for ; Tue, 19 Feb 2013 04:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w2zAiTmup+I for ; Tue, 19 Feb 2013 04:43:56 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6721F888B for ; Tue, 19 Feb 2013 04:43:56 -0800 (PST) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 8495C11B99B for ; Tue, 19 Feb 2013 06:43:55 -0600 (CST) Received: from localhost (92.53.115.234) by lavabit.com with ESMTP id JSM7LA7GYZK1 for ; Tue, 19 Feb 2013 06:43:52 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=hyuzKbRvzZDZQDyaG1jMB8ESeIiEwFIkg+WRY1O7pnDZx6jXFgkfPYyY88exmVkyFy3dJY1qcQATyj5kYltDB6Bj2aISAO6SlPl3keKQMPg+KE70AMgnYsF1Q9bGCEPqTYYsjfXS6l/HZMsuG1xLeINpWGeQ/TDu1OAGPtKZKPY=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Tue, 19 Feb 2013 12:42:55 +0000 From: Lana Black To: dtn-users maillist Message-ID: <20130219124254.GA1793@kasumi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dtn-users] another ethcl patch X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 12:43:56 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, This patch fixes the excessive cpu usage by adding nanosleep() to EthernetConvergenceLayer::Receiver::run() loop. Also fixes the failing assertion because BeaconTimer is deleted instead of being cancelled. --+QahgC5+KEYLbs62 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ethcl.patch" diff -r 2c5b711a66b0 servlib/conv_layers/EthConvergenceLayer.cc --- a/servlib/conv_layers/EthConvergenceLayer.cc Mon Feb 18 09:55:58 2013 +0000 +++ b/servlib/conv_layers/EthConvergenceLayer.cc Tue Feb 19 12:37:02 2013 +0000 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -557,6 +558,9 @@ if(should_stop()) break; + + struct timespec ts = { 0, 1*1000*1000 }; // 1 msec + nanosleep(&ts, NULL); } } diff -r 2c5b711a66b0 servlib/conv_layers/EthConvergenceLayer.h --- a/servlib/conv_layers/EthConvergenceLayer.h Mon Feb 18 09:55:58 2013 +0000 +++ b/servlib/conv_layers/EthConvergenceLayer.h Tue Feb 19 12:37:02 2013 +0000 @@ -155,8 +155,9 @@ virtual void serialize(oasys::SerializeAction *a); ~Params() { - if(timer) - delete timer; + if(timer) { + timer->cancel(); + } } u_int32_t beacon_interval_; ///< Beacon Interval --+QahgC5+KEYLbs62-- From sickmind@lavabit.com Tue Feb 19 11:50:08 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D8721F8E05 for ; Tue, 19 Feb 2013 11:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpHeBo87gTET for ; Tue, 19 Feb 2013 11:50:06 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8707221F89FD for ; Tue, 19 Feb 2013 11:50:06 -0800 (PST) Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id D388411BB27; Tue, 19 Feb 2013 13:50:05 -0600 (CST) Received: from localhost (pppoe.178-66-174-54.dynamic.avangarddsl.ru [178.66.174.54]) by lavabit.com with ESMTP id G8DYCQL8RYAE; Tue, 19 Feb 2013 13:50:05 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=MCODmiSEWSPFfW9efEY6fwwZNM7V6iJFpOFNBGIbjXISU3aCxWIO2wL5mK8YQCNkBnf1O928SaAnHf1or5fQQEBxq6inwZJ2drCpLkkRQNciziNN25+dD0Sq6S3WQc222ZuJLwLcsFp1QmLdnVbPLMmRFVfTjxt4+XlX85LkGzM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Date: Tue, 19 Feb 2013 19:50:04 +0000 From: Lana Black To: Elwyn Davies Message-ID: <20130219195004.GA16811@glow> References: <20130215071018.GA6031@kasumi> <511E1675.6030907@dial.pipex.com> <20130217104250.GA1414@kasumi> <1361214324.4494.859.camel@mightyatom> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1361214324.4494.859.camel@mightyatom> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dtn-users maillist Subject: Re: [dtn-users] EthConvergenceLayer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:50:08 -0000 On 19:05 Mon 18 Feb , Elwyn Davies wrote: > Thanks. > > I'll add a bit into the manual to reflect this shortly. > > Since you are working on Ethernet links (well, I assume you are!), and > you now have them working again, could I ask you to check that the link > name persistent storage mechanism is working correctly for Ethernet > links. I put in the code that should handle this correctly some time > ago but with the Ethernet links not working at that time I wasn't able > to check it out. The purpose of this code is to ensure that the bundle > forwarding logs can be stored and remain consistent after restarting the > daemon because link names remain consistent across restarts: after a > restart, links from previous runs are recorded in the 'Previously active > links' list and new links are checked for consistency of name and basic > parameters distinguishing between OPPORTUNISTIC and other types of links > (see ContactManager::consistent_with_previous_usage in > servlib/contacts/ContactManager.cc). > > Testing this should be fairly simple. There are two cases to check - > they can be cheked at the two ends of a single link as you are showing > the setup for below if I remember how it should work: > > 1. Manually configured link: > 1.0 Check that the database is empty of link data by running the dtnd > command 'link dump' and verifying that both the lists of 'Active links' > and Previously active links' are empty > 1.1 Set up the link between two nodes as below; for testing purposes > enter the 'link add' command manually rather than putting it in the > configuration file and specify a type of 'ALWAYS ON' (indeed anything > except 'OPPORTUNISTIC'). > 1.2 Once the link is active, on the node where you specified the link > ('remote' node) use the command interface to perform a 'link dump' > command. All being well this should show one active link name 'host0' > in an OPEN state and an empty set of 'Previously Acive Links' (assuming > you started with a 'clean' tidied database as mentioned above). > 1.3 Shutdown the daemon on the 'remote node' - check that the 'local' > node thinks the link is now CLOSED using 'link dump'. > 1.4 Restart the 'remote' node but don't (yet) enter the 'add link' > command. > 1.5 Issue a 'link dump' command on the 'remote node' and check that > there are no active links but there should be a record of the 'host0' > link under 'Previously active links'. > 1.6 Reissue the 'link add' command with the same parameters as before. > The link should come up as expected. Check all is well using the 'link > dump' command which should show the link in both 'Active links' and > 'Previously active links'. > 1.7 Repeat the exercise from step 1.3 but choose a different hardware > address at step 1.6. The 'link add' command should fail because the new > 'host0' link has inconsistent parameters to the one in 'Previous active > links'. > > 2. Opportunistic links: > Use the same configuration as in case 1, but restart the 'local node' > which should have the link marked as OPPORTUNISTIC and examine the link > state on the local node. The link should be name 'link-0'. After > restarting the daemon, the link should restart automatically and have > the same name as before (link-0). > > The error case for the OPPORTUNISTIC case can be tested by using a third > node with a different hardware address. The 'local node' should end up > with 'link-1' in 'Active links' connected to the third node and 'link-0' > still in 'Previously active links'. > > Thanks in adavnce. > Elwyn Took some time to test. Both approaches work fine with the only exception - ethernet links switch to UNAVAILABLE status instead of CLOSED when I turn off the remote daemon. There is also no way to have no links at the moment because of the ethernet beacons sent by EthCL. BTW, I think that the beacons mechanism in EthCL is redundant and should be merged into the discovery subsystem. Any opinion? From sickmind@lavabit.com Sun Feb 24 04:33:10 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6D21F88DD for ; Sun, 24 Feb 2013 04:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4AWeYoukn-X for ; Sun, 24 Feb 2013 04:33:10 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id E029F21F87A3 for ; Sun, 24 Feb 2013 04:33:08 -0800 (PST) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 4551711BA8B for ; Sun, 24 Feb 2013 06:33:08 -0600 (CST) Received: from localhost (pppoe.178-66-170-35.dynamic.avangarddsl.ru [178.66.170.35]) by lavabit.com with ESMTP id N5QFJ5M9QAPQ for ; Sun, 24 Feb 2013 06:33:08 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=f0RjWkYd9IrcBtEGfG+4HpksPekw1De8x8yzKJKr49gcTqFXTQzxGZMHVSwMWK+bA5UG9oO4FgZNmRCuWiatbnizOkDlLWJMeSLClOgFqc51cuWCVDRexsZqKQj89aL3jogU426NfYOrSxqzHv+S7Uf7yCJunEEND5pJxlrn93Y=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Sun, 24 Feb 2013 12:33:09 +0000 From: Lana Black To: dtn-users maillist Message-ID: <20130224123309.GA19354@glow> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 12:33:10 -0000 Hi, I've been trying to find some information on how to deal with bundle fragmentation in the docs and in the code itself, but no luck. Should I just send bundle in pieces produced by BundleProtocol::produce() with correct offset and len arguments, or use FragmentManager either directly or through some other class? With best regards. From elwynd@folly.org.uk Sun Feb 24 06:31:56 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5221F8F75 for ; Sun, 24 Feb 2013 06:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19sApmH8+15V for ; Sun, 24 Feb 2013 06:31:55 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id E02EF21F8936 for ; Sun, 24 Feb 2013 06:31:54 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1U9ccK-00006v-71; Sun, 24 Feb 2013 14:31:52 +0000 From: Elwyn Davies To: Lana Black In-Reply-To: <20130224123309.GA19354@glow> References: <20130224123309.GA19354@glow> Content-Type: text/plain Organization: Folly Consulting Date: Sun, 24 Feb 2013 14:30:56 +0000 Message-Id: <1361716256.4494.1191.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-users maillist Subject: Re: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 14:31:56 -0000 Hi, Lana. On Sun, 2013-02-24 at 12:33 +0000, Lana Black wrote: > Hi, > > I've been trying to find some information on how to deal with bundle > fragmentation in the docs and in the code itself, but no luck. The technical term is proactive fragmentation. You can read a bit about what DTN2 does about this in the functional spec document I wrote a while ago. http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf Section 4.6.4 and specifically item 167 talk about proactive fragmentation. > > Should I just send bundle in pieces produced by > BundleProtocol::produce() with correct offset and len arguments, or use > FragmentManager either directly or through some other class? As you will read in the document above there is functionality in DTN2 to deal with proactive fragmentation but none of the CLs uses it (as far as I could understand). There is a method in the FragmentManager class (servlib/bundling) called FragmentManager::proactively_fragment which does the work of splitting up a bundle but nothing calls it. (Probably) the point at which this should be called is in BundleActions::queue_bundle where the link mtu is tested to decide if the bundle could be sent on the link. At present if the bundle is too big for the configured link mtu, queue_bundle fails and the bundle is just left pending until some other link can take it (I think - haven't checked this logic). I suspect that the code in proactively_fragment is essentially untested, so no guarantees that it does the business correctly but it looks reasonably sane. However what *does* need to be done is to inform the central loop that there are now alternative (fragment) bundles to process. Have a look at the code in FragmentManager::try_to_reactively_fragment. I think you will need to get the new fragments into the BundleDaemon event loop by calling // treat the new fragment as if it just arrived BundleDaemon::post_at_head( new BundleReceivedEvent(, EVENTSRC_FRAGMENTATION)); for each fragment that is created. Have a look at the code in BundleDaemon::handle_bundle_transmitted that deals with reactive fragmentation to decide how to deal with the original 'whole' bundle. [HMM! Looking at the code, none of the places where queue_bundle is called actually test the return code! So if queueing fails the code just ploughs on. Not sure whether this matters or not. Thats definitely FFS!] THis is quite a complicated issue. After thinking about it a bit, one should probably keep both the fragmented bundle and the original, but add a flag to the bundle data structure to say that it has already been fragmented once.. this might even have to be a list of MTU's that it has been fragmented for so that it isn't fragmented again at the same MTU (or larger). Maybe just keeping the smallest MTU is has been fragmented for would do. Then it would only be refragmented for even smaller MTUs (hopefully an unlikely event). Hope this helps a bit! /Elwyn PS Implementing proactive fragmentatio would be useful more generally! /E > > With best regards. > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From aloomis@sarn.org Sun Feb 24 12:06:51 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEA821F9111 for ; Sun, 24 Feb 2013 12:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[AWL=-3.279, BAYES_00=-2.599, FB_REPLIC_CAP=6.557, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjIogrhjZzKA for ; Sun, 24 Feb 2013 12:06:50 -0800 (PST) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id E475821F910E for ; Sun, 24 Feb 2013 12:06:49 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id w7so1195437qeb.37 for ; Sun, 24 Feb 2013 12:06:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=tlQ3NtcFR/QQsPUPNEesGiMKfQqqC3DxfoYxI3lgHh4=; b=hf6jkqKVKmWBscTVKXpO0GgSlkRrHeF8zYlsYjuPWSvJX1RhcZZgYerHSugTl8wZ9r d7tQEIZyBewl4Z4geSQRbdGJk3NVUodJ0WYP/UaK6df/o5KeGhD7yMNbAwZzR34AcTUp N3pVCQ6HE9PajqG9baS3MzXrUXvnAWK6rWom4dNupSS5HVTRCSeqMh3+vkqQhGp+3pK4 KGQCt+l/lXmnnYd+o5WroLBVggz9wFFxn/7Zp0rmJbyckSD/vgOP1rAfJ93KoGVD7VMB eIKxS5OmBq9jgfp1iAr9i7TWdG0Ke2fhWEJ8ggvn1+QL4PQ9/YBoi8/E3ZLCDOz79SCq rriA== MIME-Version: 1.0 X-Received: by 10.49.29.135 with SMTP id k7mr9191816qeh.39.1361736408982; Sun, 24 Feb 2013 12:06:48 -0800 (PST) Received: by 10.49.48.4 with HTTP; Sun, 24 Feb 2013 12:06:48 -0800 (PST) In-Reply-To: <1361716256.4494.1191.camel@mightyatom> References: <20130224123309.GA19354@glow> <1361716256.4494.1191.camel@mightyatom> Date: Sun, 24 Feb 2013 15:06:48 -0500 Message-ID: From: Amy Alford To: Elwyn Davies Content-Type: multipart/alternative; boundary=047d7bea3f14ef64d204d67df6ab X-Gm-Message-State: ALoCoQmC5WdJYvehYyCTnju6oZzeRGca8BKu0h95e+ZUf/dlBVbyq5INzrYpQGjLz5CAZhZIcnb5 Cc: dtn-users maillist Subject: Re: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 20:06:51 -0000 --047d7bea3f14ef64d204d67df6ab Content-Type: text/plain; charset=ISO-8859-1 I've just been looking at this in order to test how the BSP code interacts with fragmentation. On Sun, Feb 24, 2013 at 9:30 AM, Elwyn Davies wrote: > Hi, Lana. > On Sun, 2013-02-24 at 12:33 +0000, Lana Black wrote: > > Hi, > > > > I've been trying to find some information on how to deal with bundle > > fragmentation in the docs and in the code itself, but no luck. > The technical term is proactive fragmentation. You can read a bit about > what DTN2 does about this in the functional spec document I wrote a > while ago. > http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf > > Section 4.6.4 and specifically item 167 talk about proactive > fragmentation. > > > > Should I just send bundle in pieces produced by > > BundleProtocol::produce() with correct offset and len arguments, or use > > FragmentManager either directly or through some other class? > As you will read in the document above there is functionality in DTN2 to > deal with proactive fragmentation but none of the CLs uses it (as far as > I could understand). There is a method in the FragmentManager class > (servlib/bundling) called FragmentManager::proactively_fragment which > does the work of splitting up a bundle but nothing calls it. > > (Probably) the point at which this should be called is in > BundleActions::queue_bundle where the link mtu is tested to decide if > the bundle could be sent on the link. At present if the bundle is too > big for the configured link mtu, queue_bundle fails and the bundle is > just left pending until some other link can take it (I think - haven't > checked this logic). > > I suspect that the code in proactively_fragment is essentially untested, > so no guarantees that it does the business correctly but it looks > reasonably sane. However what *does* need to be done is to inform the > central loop that there are now alternative (fragment) bundles to > process. Have a look at the code in > FragmentManager::try_to_reactively_fragment. I think you will need to > get the new fragments into the BundleDaemon event loop by calling > // treat the new fragment as if it just arrived > BundleDaemon::post_at_head( > new BundleReceivedEvent(, > EVENTSRC_FRAGMENTATION)); > for each fragment that is created. > This is essentially what I did (with the additional twist that I'm trying to force fragmentation based on configuration settings in order to test BSP), but I've had some difficulty getting the new bundles queued on links. Calling BundleDaemon::post_at_head(new BundleReceivedEvent(*it, EVENTSRC_FRAGMENTATION)); doesn't actually get the fragments sent. Calling queue_bundle again isn't an option because the xmit_blocks have already been created (and shouldn't be prepare/generate/finalize'd again). I ended up duplicating the code in queue_bundle that actually queues the bundle on the link to queue the fragments. You also need to calculate the fragment lengths before you do this. The code in proactively fragment (and the version of create_fragment it calls) is very buggy. Issues I know of in create_fragment are: - It needs to set the eid dictionary of the fragment based on the source one. - The payload length of the fragment is set by the PayloadBlockProcessor's generate method, so this needs to be called on the copy of the payload block in the new fragment. - The last block flag needs to be adjusted, since the last block may have changed (the first fragment only contains extension blocks that proceed the payload, or have the REPLICATE_IN_EVERY_FRAGMENT flag set. - The PrimaryBlockProcessor's generate_primary method needs to be called again on the primary block in the new fragment in order to include the fragment info (original block length, fragment offset) in the serialized primary block. In proactively_fragment: - The code tracks extension blocks that should appear in the first fragment versus extension blocks that should appear in all fragments. It actually needs to track three sets of blocks. The first fragment is supposed to contain all extension blocks that proceed the payload and any other extension blocks that have the REPLICATE_IN_EVERY_FRAGMENT flag set. The last fragment contains all extension blocks that follow the payload, as well as the extension blocks that should appear in all fragments. All other fragments contain only the extension blocks with the REPLICATE_IN_EVERY_FRAGMENT flag set. In particular, the current code doesn't include the extension blocks that should be replicated in all fragments in the first fragment. - It may not be possible to create fragments less than max_length because the length of the extension blocks required in the first or last fragment may exceed that size. proactively_fragment needs to check for this. - The loop that calls create_fragment needs to decide whether to use the first_frag_blocks, all_frag_blocks, or last_frag_blocks. > > Have a look at the code in BundleDaemon::handle_bundle_transmitted that > deals with reactive fragmentation to decide how to deal with the > original 'whole' bundle. [HMM! Looking at the code, none of the places > where queue_bundle is called actually test the return code! So if > queueing fails the code just ploughs on. Not sure whether this matters > or not. Thats definitely FFS!] THis is quite a complicated issue. > After thinking about it a bit, one should probably keep both the > fragmented bundle and the original, but add a flag to the bundle data > structure to say that it has already been fragmented once.. this might > even have to be a list of MTU's that it has been fragmented for so that > it isn't fragmented again at the same MTU (or larger). Maybe just > keeping the smallest MTU is has been fragmented for would do. Then it > would only be refragmented for even smaller MTUs (hopefully an unlikely > event). > I deleted the original bundle, but this is probably insufficient. An added complication is that the next receiving node will both forward the fragments and reassemble them and try to forward the reassembled bundle. I don't know if that's desirable or undesirable in various situations, but it does cause a lot of duplication. - Amy --047d7bea3f14ef64d204d67df6ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've just been looking at this in order to test how the BSP code intera= cts with fragmentation.

On Sun, Feb 24, 2= 013 at 9:30 AM, Elwyn Davies <elwynd@folly.org.uk> wrote:<= br>
Hi, Lana.
On Sun, 2013-02-24 at 12:33 +0000, Lana Black wrote:
> Hi,
>
> I've been trying to find some information on how to deal with bund= le
> fragmentation in the docs and in the code itself, but no luck.
The technical term is proactive fragmentation. =A0You can read a bit = about
what DTN2 does about this in the functional spec document I wrote a
while ago.
http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastru= cture-fs-12.pdf

Section 4.6.4 and specifically item 167 talk about proactive
fragmentation.
>
> Should I just send bundle in pieces produced by
> BundleProtocol::produce() with correct offset and len arguments, or us= e
> FragmentManager either directly or through some other class?
As you will read in the document above there is functionality in DTN2= to
deal with proactive fragmentation but none of the CLs uses it (as far as I could understand). =A0There is a method in the FragmentManager class
(servlib/bundling) called FragmentManager::proactively_fragment which
does the work of splitting up a bundle but nothing calls it.

(Probably) the point at which this should be called is in
BundleActions::queue_bundle where the link mtu is tested to decide if
the bundle could be sent on the link. =A0At present if the bundle is too big for the configured link mtu, queue_bundle fails and the bundle is
just left pending until some other link can take it (I think - haven't<= br> checked this logic).

I suspect that the code in proactively_fragment is essentially untested, so no guarantees that it does the business correctly but it looks
reasonably sane. =A0However what *does* need to be done is to inform the central loop that there are now alternative (fragment) bundles to
process. =A0Have a look at the code in
FragmentManager::try_to_reactively_fragment. =A0I think you will need to get the new fragments into the BundleDaemon event loop by calling
=A0 =A0 // treat the new fragment as if it just arrived
=A0 =A0 BundleDaemon::post_at_head(
=A0 =A0 =A0 =A0 new BundleReceivedEvent(<new fragment bundle>, EVENTS= RC_FRAGMENTATION));
for each fragment that is created.
This is essent= ially what I did (with the additional twist that I'm trying to force fr= agmentation based on configuration settings in order to test BSP), but I= 9;ve had some difficulty getting the new bundles queued on links. =A0Callin= g
BundleDaemon::post_at_head(new BundleReceivedEvent(*it, EVENTSRC_FRAGM= ENTATION));
doesn't actually get the fragments sent. =A0Calli= ng queue_bundle again isn't an option because the xmit_blocks have alre= ady been created (and shouldn't be prepare/generate/finalize'd agai= n). =A0I ended up duplicating the code in queue_bundle that actually queues= the bundle on the link to queue the fragments. =A0You also need to calcula= te the fragment lengths before you do this.

The code in proactively fragment (and the version= of create_fragment it calls) is very buggy. =A0
Issues I know of= in create_fragment are:
- It needs to set the eid dictionary of = the fragment based on the source one.
- The payload length of the fragment is set by the PayloadBlockProcess= or's generate method, so this needs to be called on the copy of the pay= load block in the new fragment.
- The last block flag needs to be= adjusted, since the last block may have changed (the first fragment only c= ontains extension blocks that proceed the payload, or have the REPLICATE_IN= _EVERY_FRAGMENT flag set.
- The PrimaryBlockProcessor's generate_primary method needs to be = called again on the primary block in the new fragment in order to include t= he fragment info (original block length, fragment offset) in the serialized= primary block.
In proactively_fragment:
- The code tracks extension blocks = that should appear in the first fragment versus extension blocks that shoul= d appear in all fragments. =A0It actually needs to track three sets of bloc= ks. =A0The first fragment is supposed to contain all extension blocks that = proceed the payload and any other extension blocks that have the REPLICATE_= IN_EVERY_FRAGMENT flag set. =A0The last fragment contains all extension blo= cks that follow the payload, as well as the extension blocks that should ap= pear in all fragments. =A0All other fragments contain only the extension bl= ocks with the REPLICATE_IN_EVERY_FRAGMENT flag set. =A0In particular, the c= urrent code doesn't include the extension blocks that should be replica= ted in all fragments in the first fragment.
- It may not be possible to create fragments less than max_length beca= use the length of the extension blocks required in the first or last fragme= nt may exceed that size. =A0proactively_fragment needs to check for this.
- The loop that calls create_fragment needs to decide whether to use t= he first_frag_blocks, all_frag_blocks, or last_frag_blocks. =A0
= =A0

Have a look at the code in BundleDaemon::handle_bundle_transmitted that
deals with reactive fragmentation to decide how to deal with the
original 'whole' bundle. [HMM! Looking at the code, none of the pla= ces
where queue_bundle is called actually test the return code! =A0So if
queueing fails the code just ploughs on. =A0Not sure whether this matters or not. Thats definitely FFS!] =A0THis is quite a complicated issue.
After thinking about it a bit, one should probably keep both the
fragmented bundle and the original, but add a flag to the bundle data
structure to say that it has already been fragmented once.. this might
even have to be a list of MTU's that it has been fragmented for so that=
it isn't fragmented again at the same MTU (or larger). =A0Maybe just keeping the smallest MTU is has been fragmented for would do. =A0Then it would only be refragmented for even smaller MTUs (hopefully an unlikely
event).
I deleted the original bundle, but this is pro= bably insufficient. =A0An added complication is that the next receiving nod= e will both forward the fragments and reassemble them and try to forward th= e reassembled bundle. =A0I don't know if that's desirable or undesi= rable in various situations, but it does cause a lot of duplication.
- Amy
--047d7bea3f14ef64d204d67df6ab-- From elwynd@folly.org.uk Mon Feb 25 09:03:50 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EDA21F95BD for ; Mon, 25 Feb 2013 09:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.929 X-Spam-Level: X-Spam-Status: No, score=0.929 tagged_above=-999 required=5 tests=[AWL=-3.029, BAYES_00=-2.599, FB_REPLIC_CAP=6.557] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afFr8E7HqhMM for ; Mon, 25 Feb 2013 09:03:49 -0800 (PST) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7321F9580 for ; Mon, 25 Feb 2013 09:03:43 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1UA1Sm-0003xT-Q3; Mon, 25 Feb 2013 17:03:41 +0000 From: Elwyn Davies To: Amy Alford In-Reply-To: References: <20130224123309.GA19354@glow> <1361716256.4494.1191.camel@mightyatom> Content-Type: text/plain Organization: Folly Consulting Date: Mon, 25 Feb 2013 17:02:40 +0000 Message-Id: <1361811760.4494.1284.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-users maillist Subject: Re: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:03:50 -0000 Hi.. yes, the proactively_fragment routine has clearly never been used. As Amy noted below it has to consider the three cases - first, middle and last. The first and last have preordained minimum sizes given that they have to have respectively all the pre-payload blocks for the 'first' case and all the REPLICATE blocks plus all the post-payload blocks for the 'last' case so this may mean that fragmentation is impossible for a given MTU. There is a further complication that it may be dealing with refragmentation if the bundle being fragmented is already a fragment. Looking at the two create_fragment methods, the second one is essentially useless (that's the one with 'link' in its parameters - it should probably be deleted as it is pointless copying the xmit blocks as Amy discovered) and the first one needs some refinement to make it work properly. If we actually generated a new recv_blocks list (and possibly an api_blocks list - but that is probably not vital) the new fragments would get transmitted properly without needing to fudge queue_bundles and also without deleteing the original full size bundle (I believe). However I think recording the MTU size to which the bundle has been fragmented would help as we could avoid refragmenting the whole bundle if it got tested on the same link again (as it might after a new link opened). In particular create_fragment has to deal with the dictionary (as Amy found out - neither create_fragment seems to do that). It also has to deal with the metadata block structures. Also for extension blocks that create local data structures (BPQ blocks and Metadata blocks at least) the local data structures have to be recreated -and BPQ blocks don't (yet) have a copy constructor. WARNING: the append and push_back routines used on the BlockInfoList (which are at heart std::list classes) are very dangerous. They call delete and copy routines if the list gets extended and these can screw up extension blocks that use the locals storage. This can be worked around (and the creation speed improved) by counting how many blocks have to go in the list and pre-reserving enough entries for all the blocks that might go in - this avoids lots of reallocation and copying. So I think that probably the first create_fragment method needs significant updating and the second one should be junked. Its also more complex to deal with cases where extra blocks might be added on a link specific basis. proactively_fragment currently works with the link's xmit_blocks list. You win some and you lose some here. The xmit_blocks list doesn't have the BP_Locals filled in as it is irrelevant for transmission so the delete/copy problem doesn't hit you BUT (more difficult - and highly relevant to Amy's work) there may be link specific security or metadata blocks added to the list before the fragmentation is done. This probably means that one should do a check to see if the largest possible per link version can be fragmented for the specified MTU.. this needs some discussion I think to see exactly how this should be handled. Oh, dear! This sounds as if the traditional adage about cans of worms applies: "Never open a can of worms unless you have a larger can ready to put them back into!" /Elwyn On Sun, 2013-02-24 at 15:06 -0500, Amy Alford wrote: > I've just been looking at this in order to test how the BSP code > interacts with fragmentation. > > On Sun, Feb 24, 2013 at 9:30 AM, Elwyn Davies > wrote: > Hi, Lana. > On Sun, 2013-02-24 at 12:33 +0000, Lana Black wrote: > > Hi, > > > > I've been trying to find some information on how to deal > with bundle > > fragmentation in the docs and in the code itself, but no > luck. > > The technical term is proactive fragmentation. You can read a > bit about > what DTN2 does about this in the functional spec document I > wrote a > while ago. > http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf > > Section 4.6.4 and specifically item 167 talk about proactive > fragmentation. > > > > Should I just send bundle in pieces produced by > > BundleProtocol::produce() with correct offset and len > arguments, or use > > FragmentManager either directly or through some other class? > > As you will read in the document above there is functionality > in DTN2 to > deal with proactive fragmentation but none of the CLs uses it > (as far as > I could understand). There is a method in the FragmentManager > class > (servlib/bundling) called > FragmentManager::proactively_fragment which > does the work of splitting up a bundle but nothing calls it. > > (Probably) the point at which this should be called is in > BundleActions::queue_bundle where the link mtu is tested to > decide if > the bundle could be sent on the link. At present if the > bundle is too > big for the configured link mtu, queue_bundle fails and the > bundle is > just left pending until some other link can take it (I think - > haven't > checked this logic). > > I suspect that the code in proactively_fragment is essentially > untested, > so no guarantees that it does the business correctly but it > looks > reasonably sane. However what *does* need to be done is to > inform the > central loop that there are now alternative (fragment) bundles > to > process. Have a look at the code in > FragmentManager::try_to_reactively_fragment. I think you will > need to > get the new fragments into the BundleDaemon event loop by > calling > // treat the new fragment as if it just arrived > BundleDaemon::post_at_head( > new BundleReceivedEvent(, > EVENTSRC_FRAGMENTATION)); > for each fragment that is created. > This is essentially what I did (with the additional twist that I'm > trying to force fragmentation based on configuration settings in order > to test BSP), but I've had some difficulty getting the new bundles > queued on links. Calling > BundleDaemon::post_at_head(new BundleReceivedEvent(*it, > EVENTSRC_FRAGMENTATION)); > doesn't actually get the fragments sent. Calling queue_bundle again > isn't an option because the xmit_blocks have already been created (and > shouldn't be prepare/generate/finalize'd again). I ended up > duplicating the code in queue_bundle that actually queues the bundle > on the link to queue the fragments. You also need to calculate the > fragment lengths before you do this. > > > The code in proactively fragment (and the version of create_fragment > it calls) is very buggy. > Issues I know of in create_fragment are: > - It needs to set the eid dictionary of the fragment based on the > source one. > - The payload length of the fragment is set by the > PayloadBlockProcessor's generate method, so this needs to be called on > the copy of the payload block in the new fragment. > - The last block flag needs to be adjusted, since the last block may > have changed (the first fragment only contains extension blocks that > proceed the payload, or have the REPLICATE_IN_EVERY_FRAGMENT flag set. > - The PrimaryBlockProcessor's generate_primary method needs to be > called again on the primary block in the new fragment in order to > include the fragment info (original block length, fragment offset) in > the serialized primary block. > In proactively_fragment: > - The code tracks extension blocks that should appear in the first > fragment versus extension blocks that should appear in all fragments. > It actually needs to track three sets of blocks. The first fragment > is supposed to contain all extension blocks that proceed the payload > and any other extension blocks that have the > REPLICATE_IN_EVERY_FRAGMENT flag set. The last fragment contains all > extension blocks that follow the payload, as well as the extension > blocks that should appear in all fragments. All other fragments > contain only the extension blocks with the REPLICATE_IN_EVERY_FRAGMENT > flag set. In particular, the current code doesn't include the > extension blocks that should be replicated in all fragments in the > first fragment. > - It may not be possible to create fragments less than max_length > because the length of the extension blocks required in the first or > last fragment may exceed that size. proactively_fragment needs to > check for this. > - The loop that calls create_fragment needs to decide whether to use > the first_frag_blocks, all_frag_blocks, or last_frag_blocks. > > > Have a look at the code in > BundleDaemon::handle_bundle_transmitted that > deals with reactive fragmentation to decide how to deal with > the > original 'whole' bundle. [HMM! Looking at the code, none of > the places > where queue_bundle is called actually test the return code! > So if > queueing fails the code just ploughs on. Not sure whether > this matters > or not. Thats definitely FFS!] THis is quite a complicated > issue. > After thinking about it a bit, one should probably keep both > the > fragmented bundle and the original, but add a flag to the > bundle data > structure to say that it has already been fragmented once.. > this might > even have to be a list of MTU's that it has been fragmented > for so that > it isn't fragmented again at the same MTU (or larger). Maybe > just > keeping the smallest MTU is has been fragmented for would do. > Then it > would only be refragmented for even smaller MTUs (hopefully an > unlikely > event). > I deleted the original bundle, but this is probably insufficient. An > added complication is that the next receiving node will both forward > the fragments and reassemble them and try to forward the reassembled > bundle. I don't know if that's desirable or undesirable in various > situations, but it does cause a lot of duplication. > - Amy From bmpt@ua.pt Mon Feb 25 10:52:15 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7F21E804C for ; Mon, 25 Feb 2013 10:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bICw7SX7uEUY for ; Mon, 25 Feb 2013 10:52:15 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id F257F21F927D for ; Mon, 25 Feb 2013 10:52:14 -0800 (PST) Received: from mail265-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 18:52:11 +0000 Received: from mail265-ch1 (localhost [127.0.0.1]) by mail265-ch1-R.bigfish.com (Postfix) with ESMTP id 903291980100 for ; Mon, 25 Feb 2013 18:52:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0210HT004.eurprd02.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 10 X-BigFish: VS10(z5c5ozzz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ah1082kzzz2fh87h2a8h668h839h944hd25h1220h1288h12a5h12a9h12bdh137ah13b6h13eah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail265-ch1: domain of ua.pt designates 157.56.253.181 as permitted sender) client-ip=157.56.253.181; envelope-from=bmpt@ua.pt; helo=DBXPRD0210HT004.eurprd02.prod.outlook.com ; .outlook.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail265-ch1 (localhost.localdomain [127.0.0.1]) by mail265-ch1 (MessageSwitch) id 1361818302306477_11229; Mon, 25 Feb 2013 18:51:42 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail265-ch1.bigfish.com (Postfix) with ESMTP id 4873E1260057 for ; Mon, 25 Feb 2013 18:51:42 +0000 (UTC) Received: from DBXPRD0210HT004.eurprd02.prod.outlook.com (157.56.253.181) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Feb 2013 18:51:42 +0000 Received: from DBXPRD0210MB358.eurprd02.prod.outlook.com ([169.254.6.73]) by DBXPRD0210HT004.eurprd02.prod.outlook.com ([10.255.78.167]) with mapi id 14.16.0263.000; Mon, 25 Feb 2013 18:51:40 +0000 From: Bruno Tavares To: "dtn-users@irtf.org" Thread-Topic: scheduling IMMEDIATE expiration for bundle Thread-Index: Ac4TiRuiOFBT77LKRE+p2bjU76Dj3Q== Date: Mon, 25 Feb 2013 18:51:40 +0000 Message-ID: <90494CFA1222DC45A1855F79747890D811553B6B@DBXPRD0210MB358.eurprd02.prod.outlook.com> Accept-Language: pt-PT, en-US Content-Language: pt-PT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.136.93.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ua.pt Subject: [dtn-users] scheduling IMMEDIATE expiration for bundle X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:52:15 -0000 Hello I'm testing the DTN2 with two nodes using the DTLSR routing protocol. I'm h= aving a problem in one of the nodes since in the other one the bundles on t= he bundle list are the following: 219: dtn://drivein253.dtn -> dtn://*/dtlsr?lsa_seqno=3D4 length 72 222: dtn://drivein101.dtn -> dtn://*/dtlsr?lsa_seqno=3D9 length 72 One the problematic node the bundle on the list is: 220: dtn://drivein253.dtn -> dtn://*/dtlsr?lsa_seqno=3D8 length 72 When the two nodes meet it appears on the daemon the following message (on = the problematic node): [1361810858.182801 /dtn/bundle/expiration warning] scheduling IMMEDIATE exp= iration for bundle id 208: [expiration 86400, creation time 214458376.210, = offset 946684800, now 1361810858.182773] Because of this i cannot send bundles in the two directions. If i send a bu= ndle to the problematic node the previous message appears. Can somebody help me? Thank you Bruno Tavares= From william.d.ivancic@nasa.gov Mon Feb 25 11:19:44 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2492121F92D1 for ; Mon, 25 Feb 2013 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.913 X-Spam-Level: X-Spam-Status: No, score=-3.913 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1d8YDsEqss5 for ; Mon, 25 Feb 2013 11:19:42 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (NDMSNPF02.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id 821B221F92D5 for ; Mon, 25 Feb 2013 11:19:42 -0800 (PST) Received: from ndjsppt105.ndc.nasa.gov (NDJSPPT105.ndc.nasa.gov [198.117.1.199]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 1520A10829C; Mon, 25 Feb 2013 13:19:35 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt105.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r1PJJZbK009434; Mon, 25 Feb 2013 13:19:35 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Mon, 25 Feb 2013 13:19:34 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: Bruno Tavares , "dtn-users@irtf.org" Date: Mon, 25 Feb 2013 13:20:28 -0600 Thread-Topic: [dtn-users] scheduling IMMEDIATE expiration for bundle Thread-Index: Ac4TiRuiOFBT77LKRE+p2bjU76Dj3QABA/Fd Message-ID: In-Reply-To: <90494CFA1222DC45A1855F79747890D811553B6B@DBXPRD0210MB358.eurprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-25_02:2013-02-22, 2013-02-25, 1970-01-01 signatures=0 Subject: Re: [dtn-users] scheduling IMMEDIATE expiration for bundle X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:19:44 -0000 I haven't messed with this in quite a while, but the first thing to check i= s "Are your systems synchronized?" If not, synch them and then see if you get these messages. Will > From: Bruno Tavares > Date: Mon, 25 Feb 2013 12:51:40 -0600 > To: "dtn-users@irtf.org" > Subject: [dtn-users] scheduling IMMEDIATE expiration for bundle >=20 > Hello >=20 > I'm testing the DTN2 with two nodes using the DTLSR routing protocol. I'm > having a problem in one of the nodes since in the other one the bundles o= n the > bundle list are the following: >=20 > 219: dtn://drivein253.dtn -> dtn://*/dtlsr?lsa_seqno=3D4 length 72 > 222: dtn://drivein101.dtn -> dtn://*/dtlsr?lsa_seqno=3D9 length 72 >=20 > One the problematic node the bundle on the list is: >=20 > 220: dtn://drivein253.dtn -> dtn://*/dtlsr?lsa_seqno=3D8 length 72 >=20 > When the two nodes meet it appears on the daemon the following message (o= n the > problematic node): >=20 > [1361810858.182801 /dtn/bundle/expiration warning] scheduling IMMEDIATE > expiration for bundle id 208: [expiration 86400, creation time 214458376.= 210, > offset 946684800, now 1361810858.182773] >=20 > Because of this i cannot send bundles in the two directions. If i send a > bundle to the problematic node the previous message appears. >=20 > Can somebody help me? >=20 > Thank you >=20 > Bruno Tavares > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From aloomis@sarn.org Mon Feb 25 17:21:15 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109B621E8127 for ; Mon, 25 Feb 2013 17:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMqLG1Lh5qYg for ; Mon, 25 Feb 2013 17:21:14 -0800 (PST) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 310AA21E80B6 for ; Mon, 25 Feb 2013 17:21:13 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id s14so2100851qeb.16 for ; Mon, 25 Feb 2013 17:21:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=aOl8vfNxBeumCl9fJ2oUYASUs0adCku275L1GteU9II=; b=pH4Gnh7IYTlbb/5Lr+aw6sf/dDekP7iudF3AoD1IigxOWzW/ZzI4/FvjQx9K9mRGkX /Go3J4fwcoXYEFDSKhFDsjzmiiKyUKln26s3E8k9ZzpkdiCOk5GKMOM/eqRS9vW3BLJb z/QFD0pawPLAkSrrNbW8OCkcIfuGD/hoAwY8gAGGk+EhAZFwrFO1hhV9OjACOzd6bmKG 5gdMskqNlEWy8s1DrET9aavBdupxZ4wRAYgucpv92284SEYHawaeidO2Wt8hr+vcrY3x TpjeBJJUZlKa6s5lFleJFxdinMs+UEIFw13+zpqor0LUu2cnWeYZJaBBGFAp1h6G4YPm 1YLQ== MIME-Version: 1.0 X-Received: by 10.49.24.110 with SMTP id t14mr16555758qef.48.1361841672876; Mon, 25 Feb 2013 17:21:12 -0800 (PST) Received: by 10.49.48.4 with HTTP; Mon, 25 Feb 2013 17:21:12 -0800 (PST) In-Reply-To: <1361811760.4494.1284.camel@mightyatom> References: <20130224123309.GA19354@glow> <1361716256.4494.1191.camel@mightyatom> <1361811760.4494.1284.camel@mightyatom> Date: Mon, 25 Feb 2013 20:21:12 -0500 Message-ID: From: Amy Alford To: Elwyn Davies Content-Type: multipart/alternative; boundary=047d7b3a89e4270d4204d696796f X-Gm-Message-State: ALoCoQm3y/boIHh1NyvcGnwFt9+1Oj7E5+I3NuwMyn2NZqz67N4gc3L9Cyo5QignjTvQFpGWSLey Cc: dtn-users maillist Subject: Re: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 01:21:15 -0000 --047d7b3a89e4270d4204d696796f Content-Type: text/plain; charset=ISO-8859-1 Why is it pointless to copy the xmit_blocks? They certainly need patching up, but I've been able to do that AFAICT. It ends up behaving as though you sent the original bundle on the link, then the next hop fragmented it. Whether that's what you want for BSP (as opposed to fragmenting then adding BSP blocks), I don't know. On Mon, Feb 25, 2013 at 12:02 PM, Elwyn Davies wrote: > Looking at the two create_fragment methods, the second one is > essentially useless (that's the one with 'link' in its parameters - it > should probably be deleted as it is pointless copying the xmit blocks as > Amy discovered) and the first one needs some refinement to make it work > properly. If we actually generated a new recv_blocks list (and possibly > an api_blocks list - but that is probably not vital) the new fragments > would get transmitted properly without needing to fudge queue_bundles > and also without deleteing the original full size bundle (I believe). > However I think recording the MTU size to which the bundle has been > fragmented would help as we could avoid refragmenting the whole bundle > if it got tested on the same link again (as it might after a new link > opened). > --047d7b3a89e4270d4204d696796f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why is it pointless to copy the xmi= t_blocks? =A0They certainly need patching up, but I've been able to do = that AFAICT. =A0It ends up behaving as though you sent the original bundle = on the link, then the next hop fragmented it. =A0Whether that's what yo= u want for BSP (as opposed to fragmenting then adding BSP blocks), I don= 9;t know.


On Mon, Feb 25, 2013 at 12:02 PM, Elwyn = Davies <elwynd@folly.org.uk> wrote:
Looking at the two create_fragment methods, the second one is
essentially useless (that's the one with 'link' in its paramete= rs - it
should probably be deleted as it is pointless copying the xmit blocks as Amy discovered) and the first one needs some refinement to make it work
properly. If we actually generated a new recv_blocks list (and possibly
an api_blocks list - but that is probably not vital) the new fragments
would get transmitted properly without needing to fudge queue_bundles
and also without deleteing the original full size bundle (I believe).
However I think recording the MTU size to which the bundle has been
fragmented would help as we could avoid refragmenting the whole bundle
if it got tested on the same =A0link again (as it might after a new link opened).
=A0
--047d7b3a89e4270d4204d696796f-- From elwynd@folly.org.uk Tue Feb 26 04:35:08 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3DA21F8815 for ; Tue, 26 Feb 2013 04:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGRsMaxUYytO for ; Tue, 26 Feb 2013 04:35:05 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id 68D2F21F8814 for ; Tue, 26 Feb 2013 04:35:05 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1UAJkL-0006e4-TU; Tue, 26 Feb 2013 12:35:02 +0000 From: Elwyn Davies To: Amy Alford In-Reply-To: References: <20130224123309.GA19354@glow> <1361716256.4494.1191.camel@mightyatom> <1361811760.4494.1284.camel@mightyatom> Content-Type: text/plain Organization: Folly Consulting Date: Tue, 26 Feb 2013 12:33:56 +0000 Message-Id: <1361882036.4494.1350.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-users maillist Subject: Re: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:35:08 -0000 Hi, Amy. On Mon, 2013-02-25 at 20:21 -0500, Amy Alford wrote: > > Why is it pointless to copy the xmit_blocks? They certainly need > patching up, but I've been able to do that AFAICT. It ends up > behaving as though you sent the original bundle on the link, then the > next hop fragmented it. Perhaps pointless was the wrong word. The problem is that the Bundle structure that is created for each fragment is not properly 'valid'. Things will probably work out as long as it remains on the link for which the xmit blocks were created, but things will a.s. go very pear shaped if the daemon is shutdown and restarted because the bundle, as stored in persistent storage, will have no blocks since the storage is driven from recv_blocks and api_blocks which remain empty. The resulting bundle read back will be flagged as invalid because it has no primary or payload blocks - at best it will be flagged and discarded - but there is a good chance it will trigger an assert somewhere. A similar problem will occur if a new link is opened along which the fragment bundle could be routed - reroute_all_blocks will be called and the fragments may end up on other links. An attempt to create xmit_blocks for this new link will also barf. The same will happen if the the link is closed down and/or restarted. > Whether that's what you want for BSP (as opposed to fragmenting then > adding BSP blocks), I don't know. Right.. that depends on what sort of blocks you were adding. The hop-by-hop integrity checks might have to be different - I don't know whether BAB blocks for hop-by-hop would be verified at the next security destination before or after reassembly (or indeed whether fragmentation of such a bundle would be allowed). Generated metadata blocks could also be a problem although that is more of a theoretical problem at the moment because the generated metadata block capability is not really used at present (the BPQ stuff that I am working on is nearest to it AFAICS as it generates bundles in response to queries if it has a match in the bundle cache and these have metadata blocks). > > On Mon, Feb 25, 2013 at 12:02 PM, Elwyn Davies > wrote: > Looking at the two create_fragment methods, the second one is > essentially useless (that's the one with 'link' in its > parameters - it > should probably be deleted as it is pointless copying the xmit > blocks as > Amy discovered) and the first one needs some refinement to > make it work > properly. If we actually generated a new recv_blocks list (and > possibly > an api_blocks list - but that is probably not vital) the new > fragments > would get transmitted properly without needing to fudge > queue_bundles > and also without deleteing the original full size bundle (I > believe). > However I think recording the MTU size to which the bundle has > been > fragmented would help as we could avoid refragmenting the > whole bundle > if it got tested on the same link again (as it might after a > new link > opened). > From elwynd@folly.org.uk Tue Feb 26 11:59:54 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11721F86D8 for ; Tue, 26 Feb 2013 11:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54T+ePfxqdLL for ; Tue, 26 Feb 2013 11:59:53 -0800 (PST) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 448F321F8732 for ; Tue, 26 Feb 2013 11:59:53 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1UAQgp-0001qD-BU; Tue, 26 Feb 2013 19:59:51 +0000 From: Elwyn Davies To: Amy Alford In-Reply-To: <1361882036.4494.1350.camel@mightyatom> References: <20130224123309.GA19354@glow> <1361716256.4494.1191.camel@mightyatom> <1361811760.4494.1284.camel@mightyatom> <1361882036.4494.1350.camel@mightyatom> Content-Type: text/plain Organization: Folly Consulting Date: Tue, 26 Feb 2013 19:58:44 +0000 Message-Id: <1361908725.4494.1353.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-users maillist Subject: Re: [dtn-users] bundle fragmentation X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:59:54 -0000 PS If the recv_blocks were copied instead of the xmit_blocks, the dictionary takes care of itself. /E On Tue, 2013-02-26 at 12:33 +0000, Elwyn Davies wrote: > Hi, Amy. > > On Mon, 2013-02-25 at 20:21 -0500, Amy Alford wrote: > > > > Why is it pointless to copy the xmit_blocks? They certainly need > > patching up, but I've been able to do that AFAICT. It ends up > > behaving as though you sent the original bundle on the link, then the > > next hop fragmented it. > Perhaps pointless was the wrong word. The problem is that the Bundle > structure that is created for each fragment is not properly 'valid'. > Things will probably work out as long as it remains on the link for > which the xmit blocks were created, but things will a.s. go very pear > shaped if the daemon is shutdown and restarted because the bundle, as > stored in persistent storage, will have no blocks since the storage is > driven from recv_blocks and api_blocks which remain empty. The > resulting bundle read back will be flagged as invalid because it has no > primary or payload blocks - at best it will be flagged and discarded - > but there is a good chance it will trigger an assert somewhere. A > similar problem will occur if a new link is opened along which the > fragment bundle could be routed - reroute_all_blocks will be called and > the fragments may end up on other links. An attempt to create > xmit_blocks for this new link will also barf. The same will happen if > the the link is closed down and/or restarted. > > > Whether that's what you want for BSP (as opposed to fragmenting then > > adding BSP blocks), I don't know. > Right.. that depends on what sort of blocks you were adding. The > hop-by-hop integrity checks might have to be different - I don't know > whether BAB blocks for hop-by-hop would be verified at the next security > destination before or after reassembly (or indeed whether fragmentation > of such a bundle would be allowed). > > Generated metadata blocks could also be a problem although that is more > of a theoretical problem at the moment because the generated metadata > block capability is not really used at present (the BPQ stuff that I am > working on is nearest to it AFAICS as it generates bundles in response > to queries if it has a match in the bundle cache and these have metadata > blocks). > > > > On Mon, Feb 25, 2013 at 12:02 PM, Elwyn Davies > > wrote: > > Looking at the two create_fragment methods, the second one is > > essentially useless (that's the one with 'link' in its > > parameters - it > > should probably be deleted as it is pointless copying the xmit > > blocks as > > Amy discovered) and the first one needs some refinement to > > make it work > > properly. If we actually generated a new recv_blocks list (and > > possibly > > an api_blocks list - but that is probably not vital) the new > > fragments > > would get transmitted properly without needing to fudge > > queue_bundles > > and also without deleteing the original full size bundle (I > > believe). > > However I think recording the MTU size to which the bundle has > > been > > fragmented would help as we could avoid refragmenting the > > whole bundle > > if it got tested on the same link again (as it might after a > > new link > > opened). > > > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From James.R.Wright@colorado.edu Wed Feb 27 14:00:21 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6268321F884B for ; Wed, 27 Feb 2013 14:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYQzEfcHCqIp for ; Wed, 27 Feb 2013 14:00:20 -0800 (PST) Received: from ipmx5.colorado.edu (ipmx5.colorado.edu [128.138.128.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9869021F8838 for ; Wed, 27 Feb 2013 14:00:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgLAJyALlHAqBGb/2dsb2JhbABCA4JmhQO7UXOCJm4DGgEMOzkUEgEEE4gTAaBomDqJCI8sgk5hA4hqnkGDKA X-IronPort-AV: E=Sophos;i="4.84,750,1355122800"; d="scan'208,217";a="22397963" Received: from omr-raz-2-priv.int.colorado.edu ([192.168.17.155]) by ironport5-priv.int.colorado.edu with ESMTP; 27 Feb 2013 15:00:19 -0700 Received: from exhub1-pub.colorado.edu (EHLO exhub1.ad.colorado.edu) ([128.138.123.207]) by omr-raz-2-priv.int.colorado.edu (MOS 4.1.10-GA FastPath queued) with ESMTP id KAW28836; Wed, 27 Feb 2013 15:00:16 -0700 (MST) Received: from exc4.ad.colorado.edu ([fe80::34e1:313d:54f:f797]) by exhub1.ad.colorado.edu ([::1]) with mapi; Wed, 27 Feb 2013 15:00:16 -0700 From: Jim Wright To: dtn-users maillist Date: Wed, 27 Feb 2013 15:00:15 -0700 Thread-Topic: DTN2 and oasys tests Thread-Index: Ac4VNdK/+UWbGxMiSsKOKL/h0yu8XA== Message-ID: <7B23C357-CC4C-4438-A030-CBDDEB8E4104@colorado.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7B23C357CC4C4438A030CBDDEB8E4104coloradoedu_" MIME-Version: 1.0 Subject: [dtn-users] DTN2 and oasys tests X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:00:21 -0000 --_000_7B23C357CC4C4438A030CBDDEB8E4104coloradoedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm beginning to use DTN2. I am setting up a single DTN2 node to emulate a = configuration which will be in use with our experiments onboard ISS. Our gr= ound equipment and payloads run ION and will be communicating through a NAS= A DTN2 node. Because of my focus on interoperability testing, I am using DT= N2 2.8.0 hg revision 14ffb2a3aa16 and oasys 1.5.0 hg revision 2a143c1f5eea.= I realize this is not the most recent code, but it is what our partners at= NASA recommend using. We will be following their update schedule. I need to run this with as few local modifications as possible. I have crea= ted RPM spec files for DTN2 and oasys and that is working fine. I have ever= ything building and packaging well. I'd like to run the tests included with= both the oasys and DTN2 code to verify that all is working. My concern is = that while there are a number of tests present, there appears to be no way = to systematically run them. Is anyone actually using these tests? Here are some specifics: * In oasys, running the tests by hand in the test directory, I find that 4 = of the tests fail: berkeley-db-test, filesys-db-test, memory-store-test, st= ack-trace-test. Is this expected behavior, or should I be concerned that my= setup has problems? * In dtn2, running the tests by hand in the test/unit-test directory, I fin= d that 1 of the tests fails: prophet-bundle-core-test. Actually, two tests = failed using just the code from the mercurial pull, but one of my patches a= ppears to have fixed one of them. * In dtn2, there are a great many tcl scripts intended to run tests. I stil= l can't figure out how to get any of them to execute. Help!?! Thanks for any assistance. I've been following the DTN2 mailing lists for n= early a year, and I haven't seen these tests discussed. Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 --_000_7B23C357CC4C4438A030CBDDEB8E4104coloradoedu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm beginning to use DTN2.= I am setting up a single DTN2 node to emulate a configuration which will b= e in use with our experiments onboard ISS. Our ground equipment and payload= s run ION and will be communicating through a NASA DTN2 node. Because = of my focus on interoperability testing, I am using DTN2 2.8.0 hg revision&= nbsp;14ffb2a3aa16 and oasys 1.5.0 hg revision 2a143c1f5eea. I realize = this is not the most recent code, but it is what our partners at NASA recom= mend using. We will be following their update schedule.

I need= to run this with as few local modifications as possible. I have created RP= M spec files for DTN2 and oasys and that is working fine. I have everything= building and packaging well. I'd like to run the tests included with = both the oasys and DTN2 code to verify that all is working. My concern is t= hat while there are a number of tests present, there appears to be no way t= o systematically run them. Is anyone actually using these tests?
=
Here are some specifics:

* In oasys= , running the tests by hand in the test directory, I find that 4 of the tes= ts fail: berkeley-db-test, filesys-db-test, memory-store-tes= t, stack-trace-test. Is this expected behavior, or should I be co= ncerned that my setup has problems?

* In dtn2, run= ning the tests by hand in the test/unit-test directory, I find that 1 of th= e tests fails: prophet-bundle-core-test. Actually, two tests fail= ed using just the code from the mercurial pull, but one of my patches appea= rs to have fixed one of them.

* In dtn2, there are= a great many tcl scripts intended to run tests. I still can't figure out h= ow to get any of them to execute. Help!?!

Thanks f= or any assistance. I've been following the DTN2 mailing lists for nearly a = year, and I haven't seen these tests discussed.

Ji= m Wright
BioServe Space Techn= ologies
303-492-1579

= --_000_7B23C357CC4C4438A030CBDDEB8E4104coloradoedu_-- From elwynd@folly.org.uk Wed Feb 27 15:20:05 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7521F87AD for ; Wed, 27 Feb 2013 15:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38J9gIEkNLfw for ; Wed, 27 Feb 2013 15:20:01 -0800 (PST) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 11C9421F874E for ; Wed, 27 Feb 2013 15:20:01 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1UAqHz-00089x-EI; Wed, 27 Feb 2013 23:19:55 +0000 From: Elwyn Davies To: Jim Wright In-Reply-To: <7B23C357-CC4C-4438-A030-CBDDEB8E4104@colorado.edu> References: <7B23C357-CC4C-4438-A030-CBDDEB8E4104@colorado.edu> Content-Type: text/plain Organization: Folly Consulting Date: Wed, 27 Feb 2013 23:18:43 +0000 Message-Id: <1362007123.4494.1468.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-users maillist Subject: Re: [dtn-users] DTN2 and oasys tests X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 23:20:05 -0000 Hi, Jim. Have you grabbed the test_utils component from the Sourceforge site? That has scripts for running multiple tests. Alex McMahon (TCD) is the expert on the tests. We run nightly compilation and test runs on the most up to date code on one of the machines at TCD. I'll let him give you the low down on what does and does not work. A small warning: The ODBC/SQLite persistent storage mechanism in 2.8.0 is only marginally stable and it is conceivable that you may encounter problems with forwarding logs and opportunistic or manually configured (i.e. not setup by the config file) links after restarts because the link names may change after restarts leading to inconsistent forwarding logs. This was not handled correctly by changeset 3518. Also considerable work has been done on the LTP implementation since 2.8.0 to ensure that it interoperates with ION - Stephen Farrell can give you chapter and verse on this one. Regards, Elwyn Davies On Wed, 2013-02-27 at 15:00 -0700, Jim Wright wrote: > I'm beginning to use DTN2. I am setting up a single DTN2 node to > emulate a configuration which will be in use with our experiments > onboard ISS. Our ground equipment and payloads run ION and will be > communicating through a NASA DTN2 node. Because of my focus on > interoperability testing, I am using DTN2 2.8.0 hg > revision 14ffb2a3aa16 and oasys 1.5.0 hg revision 2a143c1f5eea. I > realize this is not the most recent code, but it is what our partners > at NASA recommend using. We will be following their update schedule. > > I need to run this with as few local modifications as possible. I have > created RPM spec files for DTN2 and oasys and that is working fine. I > have everything building and packaging well. I'd like to run the tests > included with both the oasys and DTN2 code to verify that all is > working. My concern is that while there are a number of tests present, > there appears to be no way to systematically run them. Is anyone > actually using these tests? > > > Here are some specifics: > > > * In oasys, running the tests by hand in the test directory, I find > that 4 of the tests > fail: berkeley-db-test, filesys-db-test, memory-store-test, stack-trace-test. Is this expected behavior, or should I be concerned that my setup has problems? > > > * In dtn2, running the tests by hand in the test/unit-test directory, > I find that 1 of the tests fails: prophet-bundle-core-test. Actually, > two tests failed using just the code from the mercurial pull, but one > of my patches appears to have fixed one of them. > > > * In dtn2, there are a great many tcl scripts intended to run tests. I > still can't figure out how to get any of them to execute. Help!?! > > > Thanks for any assistance. I've been following the DTN2 mailing lists > for nearly a year, and I haven't seen these tests discussed. > > > Jim Wright > BioServe Space Technologies > james.r.wright@colorado.edu > 303-492-1579 > > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users