Nmap Development mailing list archives
Re: Possible bug in ncat 6.01?
From: Alex Weber <alexwebr () gmail com>
Date: Tue, 4 Sep 2012 00:14:03 -0500
I believe I have the problem worked out (the sending socket is non-blocking, when it really should be blocking) and I have a simple patch to fix this issue. I'll clean the patch up and send it to the list shortly. -Alex On 2012-09-03 7:21 PM, "Alex Weber" <alexwebr () gmail com> wrote:
Hi, thanks for the report. I can reproduce this behaviour on the loopback interface as well, with the IPv4 address. I'm not familiar with the Ncat code, but I'm doing some soak testing now to figure out exactly at what stream size Ncat misbehaves. -Alex On 2012-08-28 5:07 PM, "Jonas Wielicki" <nmap-dev () sotecware net> wrote:Hi folks, We tried to use our favourite local network file transfer mechanism (tar | ncat), when we noticed the following odd behaviour. It seems like ncat is randomly dropping data. To reproduce, it is sufficient on my machine to do the following: 1. Open two shells, A and B. 2. On shell A, run: dd if=/dev/zero bs=1024k count=128 2>/dev/null | \ tee >(wc -c) | \ ncat --listen 1337 --send-only 3. On shell B, run: ncat ::1 1337 | wc -c 4. Notice how the lengths differ. Not only that, you'll get different lengths on the receiving side on each run, making ncat a nice PRNG. Maybe you need to increase the count parameter of dd, we found that the effect is more prominent on huge data sizes, although we were able to consistently observe it with 1 MByte of data via a gigabit link. On loopback the effect does not occur stablely with 1 MByte or even 16 MBytes of data, the transfer is successful sometimes. Running wireshark on the connection reveals that the packets did not get emitted by the interface initially (tested using the gbit link, wireshark being on the sender site). The same test runs fine and reliable using a small C program (source attached; sender-side only, as receiving sides ncat seems to work) or python script doing the same task, which is why I would exclude kernel, firewall and/or hardware issues for now (that is, if ncat isn't doing something fancy). Actually, I was able to find out that if ncat is not listening but only connecting, no loss happens either. However, there is no correlation between the time ncat has been idle before accepting the connection and the amount of data loss. $ ncat --version Ncat: Version 6.01 ( http://nmap.org/ncat ) $ nmap --version Nmap version 6.01 ( http://nmap.org ) Platform: x86_64-redhat-linux-gnu Compiled with: liblua-5.1.4 openssl-1.0.0j libpcre-8.12 libpcap-1.1.1 nmap-libdnet-1.12 ipv6 Compiled without: $ uname -a Linux zion 3.4.9-1.fc16.x86_64 #1 SMP Wed Aug 15 20:45:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux If any further information is needed, don't hesitate to ask back! best regards, Jonas Wielicki _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Possible bug in ncat 6.01? Jonas Wielicki (Aug 28)
- Message not available
- Re: Possible bug in ncat 6.01? Alex Weber (Sep 03)
- Message not available
- Message not available
- Re: Possible bug in ncat 6.01? Alex Weber (Sep 03)
- Re: Possible bug in ncat 6.01? Henri Doreau (Sep 04)
- Re: Possible bug in ncat 6.01? Alex Weber (Sep 04)
- Re: Possible bug in ncat 6.01? Jonas Wielicki (Sep 04)
- Re: Possible bug in ncat 6.01? Henri Doreau (Sep 05)
- Re: Possible bug in ncat 6.01? David Fifield (Sep 06)
- Re: Possible bug in ncat 6.01? Jonas Wielicki (Sep 08)
- Re: Possible bug in ncat 6.01? Alex Weber (Sep 03)
- Re: Possible bug in ncat 6.01? David Fifield (Sep 06)