Nmap Development mailing list archives
Re: [PATCH] [Ncat] Fix EOF handling
From: David Fifield <david () bamsoftware com>
Date: Sun, 19 Apr 2009 22:37:35 -0600
On Sun, Apr 19, 2009 at 10:56:50PM +0200, Daniel Roethlisberger wrote:
David Fifield <david () bamsoftware com> 2009-04-19:In some cases quitting on EOF is the right behavior, as in your tar cvf - somedir | ncat server 1234 But in other cases, staying alive until the remote end closes the connection is correct. Consider echo -e 'GET / HTTP/1.0\r\n\r\n' | ncat scanme.nmap.org 80 With current Ncat you get a web page printed to the screen, and Ncat exits. With the EOF patch, you get nothing (and Ncat exits).Doh, what an oversight. So looking only at the client side, we have two cases. In one case, we want Ncat to quit on EOF on stdin, since communication is one-way. In the other case, we want to wait for the server to close the connection before we quit, since we are interested in the response. We should be able to differentiate the two cases based on the already existing --send-only switch. Would you agree with the following behaviour: - when using --send-only, Ncat should close the socket and quit after EOF on stdin, and - when not using --send-only, Ncat should always wait on the server to close the connection before quitting?
That sounds very reasonable.
So it's hard to pick a good default. The documentation at http://nc110.sourceforge.net/ has not quitting on EOF as a feature: You may be asking "why not just use telnet to connect to arbitrary ports?" Valid question, and here are some reasons. Telnet has the "standard input EOF" problem, so one must introduce calculated delays in driving scripts to allow network output to finish. Then there is a -w <secs> option to quit after some period of inactivity. I don't have experience with earliers Netcats so I don't know what's best. I guess my bias would be to leave connections running by default, and add a switch to close on stdin EOF, the reason being that in case of user error it's better to receive extra data than to potentially throw data away.Current default behaviour actually seems to *loose* data on SIGINT because of buffering. I tried sending an odd number of bytes to an Ncat listener piping into hexdump (hd). The last few bytes never made it to hexdump after pressing Ctrl+C. Same thing with other consumers such as tar.
I'll look into that. You're not at all obligated to do this, but it would help if you could write a failing test for this in test/ncat-test.pl. Then we can demonstrate when it's fixed and avoid reintroducing it in the future. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- [PATCH] [Ncat] Fix EOF handling Daniel Roethlisberger (Apr 18)
- Re: [PATCH] [Ncat] Fix EOF handling bensonk (Apr 18)
- Re: [PATCH] [Ncat] Fix EOF handling Daniel Roethlisberger (Apr 19)
- Re: [PATCH] [Ncat] Fix EOF handling David Fifield (Apr 19)
- Re: [PATCH] [Ncat] Fix EOF handling Daniel Roethlisberger (Apr 19)
- Re: [PATCH] [Ncat] Fix EOF handling David Fifield (Apr 19)
- Re: [PATCH] [Ncat] Fix EOF handling (client-side) Daniel Roethlisberger (May 02)
- Re: [PATCH] [Ncat] Fix EOF handling (client-side) David Fifield (May 03)
- Re: [PATCH] [Ncat] Fix EOF handling (server side) Daniel Roethlisberger (May 02)
- Re: [PATCH] [Ncat] Fix EOF handling (server side) David Fifield (May 03)
- Re: [PATCH] [Ncat] Fix EOF handling Daniel Roethlisberger (Apr 19)
- Re: [PATCH] [Ncat] Fix EOF handling bensonk (Apr 18)
- Re: [PATCH] [Ncat] Fix EOF handling David Fifield (Jun 01)
- Re: [PATCH] [Ncat] Fix EOF handling Daniel Roethlisberger (Jun 02)
- Re: [PATCH] [Ncat] Fix EOF handling David Fifield (Jun 07)
- Re: [PATCH] [Ncat] Fix EOF handling Kris Katterjohn (Jun 07)
- Re: [PATCH] [Ncat] Fix EOF handling Daniel Roethlisberger (Jun 07)
- Re: [PATCH] [Ncat] Fix EOF handling David Fifield (Jun 08)