Re: [dtn-users] A problem with dtntunnel

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

Hi David,

I meant exactly the same position before the end of the while loop, just
described it incorrect.

Please let me know if you find the solution for this problem.

Best regards,
Sergey

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

> Hi Sergey,****
>
> I was narrowing in on the same track... The FIN results in a returned
> length of zero on the read and errno is also zero so you have to key on the
> return length which is already in the code.****
>
> ** **
>
> You may have added a couple of lines of debug code and it should be
> inserted just before the end of the while(1) loop at line 491 in the latest
> version on Sourceforge.****
>
> ** **
>
> I am seeing the sending socket stay in the TIME_WAIT mode even if I add a
> call to sock_.shutdown(SHUT_RDWR) before closing the socket;****
>
> Getting close I think.****
>
> ** **
>
> The 0.0.0.0 was because I did not have anything at the other end of the
> tunnel and just stuck some easy numbers in there.****
>
> Thanks,
> DZ****
>
> ** **
>
> David Zoller****
>
> COLSA Corporation****
>
> Marshall Space Flight Center****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]]
> *Sent:* Wednesday, December 12, 2012 11:06 AM
>
> *To:* Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> *Cc:* [e-mail]
> *Subject:* Re: [dtn-users] A problem with dtntunnel****
>
> ** **
>
> 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
>
> ****
>



-- 
Best regards,
Sergey Sireskin