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

[Ian Lepore]

On Tue, 2013-07-23 at 16:48 -0700, Ronald F. Guilmette wrote:
> 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.
> 

I don't think this accurately summarizes things.  The view of the remote
server isn't just "EOF arrives" it's "can't read anymore" and "can't
write anymore" which have to be handled separately.

> 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.
> 

Here you seem to be talking about the inability to send more data to the
remote side.  If you exit immediately when that happens, even if you
could still read from the remote side, then you may miss the incoming
data that would tell you why you can't send anymore.  In this case the
thing to do would be to stop reading stdin, but continue to read the
remote side and copy it to stdout until you get EOF reading the remote
side.

Conversely, you can't exit immediately when the remote side has no more
to send you and shuts down that half of the connection, you still have
to read from stdin and send it to the remote until EOF on stdin or the
remote shuts down that half of the connection.

How all this applies to netcat's ability to do connectionless (UDP)
stuff probably makes the whole thing that much more interesting.

BTW, earlier in the thread you asserted more or less that telnet is for
interactive and nc for scripting.  I virtually never use nc in any way
except interactively, and I use it that way every day, all day long.

-- Ian

> 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
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"