bin/176713: [patch] nc(1) closes network socket too soon

Ronald F. Guilmette rfg at tristatelogic.com
Tue Jul 23 23:48:41 UTC 2013


In message <CAJ-Vmonk-8v9ej0w4qycNNBkieOeE9dL3BTVp6VqipxKH2jSUA at mail.gmail.com>
Adrian Chadd <adrian at freebsd.org> wrote:

>Right, and your patch just stops the shutdown(), right?

The shutdown that occurs when EOF is encountered on stdin, yes.

>Rather than
>teaching nc to correctly check BOTH socket states before deciding to
>close things.

In effect, nc *is* currently "checking both sockets" and that is exactly
the problem.  It terminates (prematurely in some cases) whenever it sees
an EOF _either_ from the remote host _or_ from stdin.

My patch casuses nc to wait for EOF from the remote server before exiting,
EVEN IF prior to the time it sees that EOF from the remote server it sees
an EOF (first) on stdin.

This code change demonstratably makes the functionality of nc better and
more pragmatically useful in typical use cases.

You appear to be proposing something else, but I'm sorry to say that
I cannot decypher what, exactly you are attempting to propose.

I have proposed specific code changes.  If you have some different ones
that you would like to propose, then I feel sure that everyone on the
hackers list, including myself, would be interested to take a look at
what you have in mind, and also what problem you are solving.

>I'd personally rather see nc taught to check to see whether it can
>possibly make ANY more progress before deciding to shut things down.

I believe that that is exactly what the patch that I proposed does.
I'm not sure why you feel otherwise.

Look, there are only two scenarios... either (a) EOF arrives from stdin
first or else (b) EOF arrives from the remote server first.

My patch causes nc to continue gathering data from the remote server
(and copying it all to stdout) in case (a).

In case (b) there is no point in nc continuing to run (and/or continuing
to read from stdin) if the remote server has shut down the connection.
In this case, the data that nc might yet gather from its stdin channel
has noplace to go!  So whenever nc has sensed an EOF from the remote
server it can (and should) immediately shut down... and that is exactly
what it is _already_ programmed to do.

So, what problem do you want to solve that is not solved by the patch
that I already proposed?

Also, with respect, if you think there really is some other problem,
then proposing actual concrete patches to solve that other problem
would perhaps allow folks, including myself, to better understand what
it is that you are driving at.


Regards,
rfg


More information about the freebsd-hackers mailing list