Re: [PATCH] [Ncat] Fix EOF handling (server side)

[David Fifield <david () bamsoftware com>]

On Sat, May 02, 2009 at 07:54:23PM +0200, Daniel Roethlisberger wrote:
> David Fifield <david () bamsoftware com> 2009-04-19:
> > > > 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.
>
> ncat-test.pl gives me a lot of failed tests with r13157 already.
> Is this expected or am I missing something?

Several tests fail because of uninplemented features. Some of them fail
occasionally because of timing issues with subprocess communication.
Someone who knows interprocess communication in Perl better than I might
be able to fix those. The main problem is trying to read output that a
process wrote before it died. That probably accounts for most of the
"Read timeout" errors you got.

These are the errors I get, all of them known defects:

FAIL Connection persistence (UDP)
     Server got "", not "abc\n" at ./ncat-test.pl line 308.
FAIL HTTP CONNECT client hides proxy server response
     Proxy client sent "HTTP/1.0 200 OK

" to the user stream at ./ncat-test.pl line 496.
FAIL HTTP proxy server auth challenge (SSL)
     Read timeout at ./ncat-test.pl line 727.
FAIL HTTP proxy server correct auth (SSL)
     Read timeout at ./ncat-test.pl line 742.
FAIL HTTP proxy server wrong user (SSL)
     Read timeout at ./ncat-test.pl line 755.
FAIL HTTP proxy server wrong pass (SSL)
     Read timeout at ./ncat-test.pl line 768.
FAIL HTTP proxy server correct auth, different case (SSL)
     Read timeout at ./ncat-test.pl line 781.
FAIL HTTP proxy server LWS (SSL)
     Read timeout at ./ncat-test.pl line 795.
FAIL HTTP proxy server LWS (SSL)
     Read timeout at ./ncat-test.pl line 808.
FAIL HTTP proxy server no auth (SSL)
     Read timeout at ./ncat-test.pl line 821.
FAIL HTTP proxy server broken auth (SSL)
     Read timeout at ./ncat-test.pl line 834.
FAIL HTTP proxy server extra auth (SSL)
     Read timeout at ./ncat-test.pl line 847.
FAIL --max-conns 10 (UDP)
     --max-conns 10 server did not accept client #2 at ./ncat-test.pl line 177.
FAIL --max-conns 1 with exec (SSL)
     --max-conns 1 server did not accept client #1 at ./ncat-test.pl line 177.
FAIL --max-conns 10 with exec (SSL)
     --max-conns 10 server did not accept client #1 at ./ncat-test.pl line 177.
15 failures in 141 tests.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org