Bug 1004939 - nmap-ncat: nc does not exit when remote server closes connection
nmap-ncat: nc does not exit when remote server closes connection
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: nmap (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-05 15:31 EDT by tkil
Modified: 2013-09-10 16:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-10 10:40:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace output for 6.01 (28.99 KB, text/plain)
2013-09-05 15:31 EDT, tkil
no flags Details
strace output for 6.40 (18.52 KB, text/plain)
2013-09-05 15:32 EDT, tkil
no flags Details

  None (edit)
Description tkil 2013-09-05 15:31:40 EDT
Created attachment 794461 [details]
strace output for 6.01

Description of problem:

With nmap-ncat 6.01-8.fc18.x86_64, 'nc' would quit after the remote socket closed.  With version 6.40-1.fc18.x86_64, it seems to just hang, and remote socket won't close even after it has sent all the data.

Version-Release number of selected component (if applicable):

6.01-8.fc18 works.
6.40-1.fc18 hangs.

How reproducible:

100%

Steps to Reproduce:

1. On remote machine, start listening socket:

  nc -l -p 3000 < data.txt

2. On Fedora machine, try to read that data:

  nc remote 3000 > data.txt

Actual results:

6.01-8.fc18 transfers file and then quits.
6.40-1.fc18 transfers file and hangs.

Expected results:

Expected both to transfer then quit.

Additional info:

A quick look at the strace (which I'll attach in a moment) shows that 6.01 uses epoll, while 6.40 uses select -- that surprises me.

More surprisingly, it looks like 6.40 is stuck because it has /dev/urandom open.  I have no idea why.
Comment 1 tkil 2013-09-05 15:32:22 EDT
Created attachment 794462 [details]
strace output for 6.40
Comment 2 Michal Hlavinka 2013-09-10 10:40:53 EDT
unfortunately, that's not a bug, it's a bug fix and known difference from original nc

after transfer in one direction, you can still send data in opposite direction

if you want nc to terminate, modify your command to look like this:
nc remote 3000 --recv-only > data.txt 

6.40 does not use epoll, because epoll support is incomplete and does not work correctly when input is file
Comment 3 tkil 2013-09-10 13:49:28 EDT
(In reply to Michal Hlavinka from comment #2)
> unfortunately, that's not a bug, it's a bug fix and known
> difference from original nc after transfer in one direction,
> you can still send data in opposite direction
> 
> if you want nc to terminate, modify your command to look like this:
> nc remote 3000 --recv-only > data.txt 

That seems a little insane, especially as stdin should be at eof at that point, no?  Where else would 'nc' be getting data to send?

> 6.40 does not use epoll, because epoll support is incomplete and does not
> work correctly when input is file.

Ok.
Comment 4 tkil 2013-09-10 16:26:03 EDT
(In reply to tkil from comment #3)
> That seems a little insane, especially as stdin should be at eof at that
> point, no?  Where else would 'nc' be getting data to send?

Nevermind, I understand now.  stdin is of course not at EOF; I might still type something into the terminal.

Still a little grumpy that the *default* behavior changed, but I can live with it.  (How often is it bidirectional vs one-way?  Maybe a "--bi-dir" flag would have been better...)

Sorry for the noise, and thanks for the patient explanation.

Note You need to log in before you can comment on or make changes to this bug.