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

Ronald F. Guilmette rfg at tristatelogic.com
Mon Jul 22 02:02:27 UTC 2013


In message <CAJ-VmomyAi51VDzFh=QzbtT4EBsvsP4BocoE9-7Ca44Z1tcCGA at mail.gmail.com>
Adrian Chadd <adrian at freebsd.org> wrote:

>Wait a second. What's going on under the hood?
>
>You _should_ be able to shutdown the write side of the socket and have
>it not affect reading.

It has been some time now since I filed my PR but I think that the bottom
line is that you need to look at the code (of nc) to understand how it is
reacting to EOF on stdin.

My recollection is that it exits as soon as it sees that (i.e. EOF on
its own stdin).  My proposed patch corrects this unfortunate behavior.

>It's a broken server if it does a read(), find
>that the socket is returning EOF, and then not waiting for the write()
>to fail before closing.

The server(s) is/are not at fault in this instance.  It is the *client*,
i.e. nc, which is broken in its behavior.

With respect to that, I *do* 100% agree with you that nc's current behavior
is absolutely and unambiguously broken.  What nc is currently doing is
goofy and also provably counterproductive for most applications where one
can envision nc being used, i.e. specifically in *non-interactive*
scripting applications.  In all such applications of nc it is essentially
100% likely that the input stream which will be given to nc will be coming
from either (a) some disk file or else (b), more likely via a pipe from
some other commands/scripts/programs.  In all such cases, nc is likely to
see the EOF on its stdin well before the remote server is finished sending
down its reply, and thus, as has been demonstrated, nc will incorrectly
truncate the server's reply.

Note also that if you accept my premise, i.e. that nc is used, and that
it will be used always (or virtually always) within non-interactive
scenarios/contexts... leaving telnet for people who need a more inter-
actively oriented tool... then there really is no need to accompany the
change I have propsed with a new "-q" option, and instead the current
behavior of nc can simply be changed from "exit-on-stdin-EOF" to
"exit-on-remote-server-EOF", with no further or additional code changes.


Regards,
rfg


More information about the freebsd-hackers mailing list