[dtn-users] Fwd: A problem with dtntunnel

"ssireskin@gmail.com" <ssireskin@gmail.com> Wed, 12 December 2012 11:10 UTC

Return-Path: <ssireskin@gmail.com>
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 314C021F897F for <dtn-users@ietfa.amsl.com>; Wed, 12 Dec 2012 03:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.272, 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 W9AOu7Zi-1U7 for <dtn-users@ietfa.amsl.com>; Wed, 12 Dec 2012 03:10:18 -0800 (PST)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6521F894F for <dtn-users@irtf.org>; Wed, 12 Dec 2012 03:10:18 -0800 (PST)
Received: by mail-pb0-f54.google.com with SMTP id wz12so454527pbc.13 for <dtn-users@irtf.org>; Wed, 12 Dec 2012 03:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UCnv54pFAWMQCe0Voj4KPvwkzpNYQdY0Ak4iNBIDSik=; b=W+Z7jsfTtUwXquIeQaKNiiD7KbQoMO7WqxEhVTnq9Xa2CtI8yzF71OOYzjHHX/TRwn J+X7sScKoJ+JSo08dflRhGnKBLKwbV2JP588nzM2U+/wfysQFyU1yHSN9LRokKAKmFa7 IdItI5kAmLQGikysy4uX/5vN/2HIUYaT3x/siXmAjzvCeu4K7J1ytXRxBclTSmi2CBme U4sRfQZtn3ZFV3i3qNkynIyN90+VadobUqJxTWttLM2Y6PV5bJ0PA+XJjlVXBkj05jWS dWWZ92iCAyAkcQVtHnTNjggxEap5/QH7OCmrer8X4JnC08KzdCjTuM+OwgfvTdBK+Olq fClw==
MIME-Version: 1.0
Received: by 10.68.134.232 with SMTP id pn8mr1719056pbb.47.1355310618553; Wed, 12 Dec 2012 03:10:18 -0800 (PST)
Received: by 10.68.18.172 with HTTP; Wed, 12 Dec 2012 03:10:18 -0800 (PST)
In-Reply-To: <CAJR8z98JoR2BGaSLer+u9k=Ok6iFroO0puqkDG2RpCzf=AxXng@mail.gmail.com>
References: <CAJR8z9--cVk67ac-aJ2haKpc=7LSVWHFXhTykaGcdpLQeevtiQ@mail.gmail.com> <04E3D99A62496240BCD6A576813E6E31E0BDBBA4FA@NDMSSCC05.ndc.nasa.gov> <CAJR8z98cbUhEPMyzR4Syp+Cd1xcg3Ei3u-UjykCQCGo2rBe9QA@mail.gmail.com> <04E3D99A62496240BCD6A576813E6E31E0BDBBA685@NDMSSCC05.ndc.nasa.gov> <CAJR8z98JoR2BGaSLer+u9k=Ok6iFroO0puqkDG2RpCzf=AxXng@mail.gmail.com>
Date: Wed, 12 Dec 2012 14:10:18 +0300
Message-ID: <CAJR8z9_sFMFW-E7Xg_zjR67uYLTjqSLDwABLV-mVuyDpAuE5-Q@mail.gmail.com>
From: "ssireskin@gmail.com" <ssireskin@gmail.com>
To: dtn-users@irtf.org
Content-Type: multipart/alternative; boundary="047d7b10c861faace404d0a5d727"
Subject: [dtn-users] Fwd: A problem with dtntunnel
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." <dtn-users.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-users>, <mailto:dtn-users-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-users>
List-Post: <mailto:dtn-users@irtf.org>
List-Help: <mailto:dtn-users-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2012 11:10:20 -0000

Hi David,

I have investigated that issue a little. I have found, that no matter
whether netcat is run with or without the -w1 option, something
strange happens. According to netstat -ntp on the sending node, dtntunnel
remains in CLOSE_WAIT state after nc finishes sending
data. I have run tcpdump on both sender and receiver, and it showed that
final FIN from the receiver doesn't reach the sender.
This looked like a bug in dtntunnel to me. I decided to re-check with
iperf, and again, tcpdump showed the same problem.

Here are the last lines of the tcpdump. Remember that in my setup all
outgoing TCP packets with destination port 9999 are redirected
with the help of IPTables to the local dtntunnel process, listening om port
19999. That is why I run tcpdump on loopback interface.

Receiver (192.168.4.1): tcpdump -nn -npi lo port 9999 or port 19999
15:05:02.496366 IP 192.168.4.1.34284 > 192.168.4.1.9999: Flags [P.], seq
123995:131097, ack 1, win 257, options [nop,nop,TS val 11163723 ecr
11163718], length 7102
15:05:02.496428 IP 192.168.4.1.9999 > 192.168.4.1.34284: Flags [.], ack
131097, win 1154, options [nop,nop,TS val 11163724 ecr 11163723], length 0
15:05:03.457421 IP 192.168.4.1.34284 > 192.168.4.1.9999: Flags [F.], seq
131097, ack 1, win 257, options [nop,nop,TS val 11164684 ecr 11163724],
length 0
15:05:03.497482 IP 192.168.4.1.9999 > 192.168.4.1.34284: Flags [.], ack
131098, win 1154, options [nop,nop,TS val 11164725 ecr 11164684], length 0
15:05:04.457762 IP 192.168.4.1.9999 > 192.168.4.1.34284: Flags [F.], seq 1,
ack 131098, win 1154, options [nop,nop,TS val 11165685 ecr 11164684],
length 0
15:05:04.457856 IP 192.168.4.1.34284 > 192.168.4.1.9999: Flags [.], ack 2,
win 257, options [nop,nop,TS val 11165685 ecr 11165685], length 0

Sender (192.168.2.1): tcpdump -nn -npi lo port 9999 or port 19999
15:05:02.433755 IP 192.168.4.1.9999 > 192.168.1.2.43360: Flags [.], ack
127449, win 386, options [nop,nop,TS val 11172887 ecr 11172875], length 0
15:05:02.433776 IP 192.168.1.2.43360 > 192.168.1.2.19999: Flags [.], seq
127448:130344, ack 1, win 46, options [nop,nop,TS val 11172887 ecr
11172887], length 2896
15:05:02.433783 IP 192.168.1.2.43360 > 192.168.1.2.19999: Flags [P.], seq
130344:131096, ack 1, win 46, options [nop,nop,TS val 11172887 ecr
11172887], length 752
15:05:02.444839 IP 192.168.4.1.9999 > 192.168.1.2.43360: Flags [.], ack
131097, win 386, options [nop,nop,TS val 11172898 ecr 11172887], length 0
15:05:03.421915 IP 192.168.1.2.43360 > 192.168.1.2.19999: Flags [F.], seq
131096, ack 1, win 46, options [nop,nop,TS val 11173875 ecr 11172898],
length 0
15:05:03.461742 IP 192.168.4.1.9999 > 192.168.1.2.43360: Flags [.], ack
131098, win 386, options [nop,nop,TS val 11173915 ecr 11173875], length 0

I believe that the cause of why the sending netcat without -w1 option
doesn't exit, is that it doesn't receive the final FIN from the dtntunnel.
Can this issue be fixed with a small amount of work?

Best regards,
Sergey

 2012/12/5 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <
david.a.zoller@nasa.gov>

> Hi Sergey,****
>
> I would not even call this a problem. netcat is designed to be extremely
> flexible and by default the sender keeps its connection open as long as the
> other end does. On the other hand the receiver by default terminates after
> receipt of an EOF but there is a switch to keep listening if that is the
> desired behavior. ****
>
> ** **
>
> With DTN, your sending nc may do its thing while the destination node is
> not even on line and then an hour later it becomes available and completes
> the transmission to the receiving nc. In this scenario, the sender would
> still be “hung up” possibly indefinitely waiting for a terminating signal.
> ****
>
> ** **
>
> I am not the DTN2 authHi ority, but, I don’t see a change to dtntunnel for
> this as it would assume a specific usage that would probably break someone
> else’s usage (like mine J).****
>
> ** **
>
> Best regards,****
>
> DZ****
>
> ** **
>
> David Zoller****
>
> COLSA Corporation****
>
> Marshall Space Flight Center****
>
> ** **
>
> *From:* ssireskin@gmail.com [mailto:ssireskin@gmail.com]
> *Sent:* Wednesday, December 05, 2012 2:56 AM
> *To:* Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> *Cc:* dtn-users@irtf.org
> *Subject:* Re: [dtn-users] A problem with dtntunnel****
>
> ** **
>
> Hi David,
>
> Thanks for your help, nc -w1 did the trick. But shouldn't dtntunnel
> behavior be changed? The receiving dtntunnel could signal the sending
> dtntunnel, that the listening nc has disconnected, so that the sending
> dtntunnel close its connection to the sending nc. Or is this solely the
> problem of nc?****
>
> 2012/12/5 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <
> david.a.zoller@nasa.gov>****
>
> Hi Sergey,****
>
> On RHEL 5.7, I am running dtn-2.9.0 plus modifications that should not
> impact the behavior of dtntunnel.****
>
> I just ran your test without the iptables redirect and I see the same
> behavior.****
>
> I believe that the sender exits if you go directly from nc to nc because
> the receiver exits when it gets an end of file.****
>
> You can add a “-w 1” option to the sender nc so that it will timeout and
> exit after stdin is idle for 1 second.****
>
> Best regards,****
>
> DZ****
>
>  ****
>
> David Zoller****
>
> COLSA Corporation****
>
> HOSC / C107  ****
>
> (Office: (256) 544-1820
> *EMail: david.a.zoller@nasa.gov****
>
>  ****
>
> *From:* dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] *On
> Behalf Of *ssireskin@gmail.com
> *Sent:* Tuesday, December 04, 2012 11:13 AM
> *To:* dtn-users@irtf.org
> *Subject:* [dtn-users] A problem with dtntunnel****
>
>  ****
>
> Hello all!
>
> I am using dtn-2.9.0 on a RHEL 6 based Linux distro and I am having a
> problem when using netcat (nc) with dtntunnel.
> On the sender node I run "cat /etc/passwd | nc receiver_ip". On the
> receiver node I run "nc -l 9999". With the help
> of Iptables port 9999 gets redirected to the port 19999, which is listened
> by dtntunnel.
>
> The file /etc/passwd is successfully delivered to the receiver and is
> shown on the screen. After this the receiving nc exists.
> No problem here. However, nc on the sender node doesn't exit after it
> sends the file. It continues to run forever. When I
> run nc in the opposite direction, I get the same problem - the sending nc
> doesn't exit.
>
> My configuration on both nodes is symmetric:
> iptables -t nat -A OUTPUT -d $REMOTE_HOST -p tcp --dport 9999 -j DNAT --to
> $LOCAL_HOST:19999
> dtntunnel -T $LOCAL_HOST:19999:$REMOTE_HOST:9999 $REMOTE_NODE/dtntunnel/nc
> -d
> dtntunnel -L --local-eid $LOCAL_NODE/dtntunnel/nc -d
>
> dtnping works ok in both directions.
>
> Please give me any advice.
>
> With best regards,
> Sergey Sireskin ****
>
>