Bug 1004939

Summary: nmap-ncat: nc does not exit when remote server closes connection
Product: [Fedora] Fedora Reporter: tkil
Component: nmapAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 18CC: athmanem, mhlavink, psabata
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-10 14:40:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
strace output for 6.01
none
strace output for 6.40 none

Description tkil 2013-09-05 19:31:40 UTC
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 19:32:22 UTC
Created attachment 794462 [details]
strace output for 6.40

Comment 2 Michal Hlavinka 2013-09-10 14:40:53 UTC
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 17:49:28 UTC
(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 20:26:03 UTC
(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.