Re: [dtn-users] A problem with dtntunnel

["[e-mail]" <[e-mail]>]

Hi David,

I added the following code at the line 492 of TCPTunnel.cc and it seems
that it helped.

    if (sock_eof) {
        sock_.close();
        goto done;
    }

The senders, both nc and iperf, exit after having finished sending the
data. There are
no more sockets in CLOSE_WAIT state. However I am completely unsure whether
my code is correct and is in correct place.

Now I have encountered another problem. When iperf test is run with 100
parallel flows,
some dtntunnel connections are not removed from dtntunel's connection
table, and the
related sockets are not closed. I suppose this happens because my code
addition is far
from perfect.

And one more question, what does 0.0.0.0 mean in -T tunnel specification?
Is it just an
example host, or 0.0.0.0 has some special meaning for dtntunnel?

2012/12/12 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <
[e-mail]>

> Hi Sergey,****
>
> I have duplicated what you are reporting and have to retract my earlier
> statement saying that this is the netcat design and not a problem J****
>
> The sender netcat attempts to close the socket when it gets the [EOF] and
> not in response to the receiver closing its end.****
>
> ** **
>
> ** **
>
> *netcat sender:*
>
> cat /etc/passwd | nc x.x.x.x 12345****
>
> ** **
>
> *scenario 1 - netcat receiver with the keep listener option:*
>
>                 nc -k -l 12345****
>
> **·         **Sender terminates and receiver stays alive and listening
> for a re-connect****
>
> **·         **FIN is sent in both directions initiated by the sender****
>
> ** **
>
> *scenario 2 - dtntunnel receiver:*
>
>                 dtntunnel -t -T 12345:0.0.0.0:54321 dtn://desteid/xxxx****
>
> **·         **Sender does not terminate****
>
> **·         **FIN is sent from sender to receiver but not the other way***
> *
>
> **·         **Sender socket is in state FIN_WAIT2****
>
> **·         **Receiver socket is in state CLOSE_WAIT****
>
> Kill the sender and repeat...****
>
> **·         **Sender does not terminate****
>
> **·         **FIN is sent from sender to receiver but not the other way***
> *
>
> **·         **New Sender socket is in state FIN_WAIT2 and the first one
> has timed out and died****
>
> **·         **Both Receiver sockets are in state CLOSE_WAIT****
>
> Kill the dtntunnel receiver…****
>
> **·         **2 FINs are sent from the receiver – 1 to each of the
> sockets (even though the other ends have expired)****
>
> ** **
>
> ** **
>
> I believe the issue would be in the oasys IPSocket or possibly the
> IPClient. I’ll have a look at it unless there is a low-level socket expert
> out there that wants to give it a go…****
>
> ** **
>
> Best regards,****
>
> DZ****
>
> ** **
>
> David Zoller****
>
> COLSA Corporation****
>
> Marshall Space Flight Center****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]]
> *Sent:* Wednesday, December 12, 2012 4:38 AM
>
> *To:* Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> *Subject:* Re: [dtn-users] A problem with dtntunnel****
>
> ** **
>
> 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?****
>
> 2012/12/5 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <
> [e-mail]>****
>
> 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:* [e-mail] [mailto:[e-mail]]
> *Sent:* Wednesday, December 05, 2012 2:56 AM
> *To:* Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> *Cc:* [e-mail]
> *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] <
> [e-mail]>****
>
> 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: [phone]
> *EMail: [e-mail]****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *[e-mail]
> *Sent:* Tuesday, December 04, 2012 11:13 AM
> *To:* [e-mail]
> *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 ****
>
>
>
>
> --
> Kindest Regards
>
> Sergey Sireskin
> FGUP CNII EISU****
>
>
>
>
> --
> Kindest Regards
>
> Sergey Sireskin
> FGUP CNII EISU****
>



-- 
Best regards,
Sergey Sireskin