Date: Fri, 17 Mar 95 13:02:16 MST From: terry@cs.weber.edu (Terry Lambert) To: mycroft@ai.mit.edu (Charles M. Hannum) Cc: peter@bonkers.taronga.com, hackers@FreeBSD.org, tech-net@NetBSD.ORG Subject: Re: Batch Telnet (Re: diskless and 3Com 509) Message-ID: <9503172002.AA29797@cs.weber.edu> In-Reply-To: <199503171758.MAA28775@duality.gnu.ai.mit.edu> from "Charles M. Hannum" at Mar 17, 95 12:58:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The message returned is "Connection closed by remote host.", not > "Connection closed." > > And you actually believed that message? It's wrong. Yep; silly me, it appears. 8-). > Not at all. If you actually look at the packets on the wire, you'll > see: > > 1) The client sends a FIN. > > 2) The server sends some data. > > 3) The client responds to the data with a RST. > > tcpdump(8) leaves no doubt that the problem, if any, is in the client. > > Actually, I misspoke about TCP. The client can close the write side > by sending a FIN. However, the telnet client is currently closing > both sides of the connection when it gets an EOF on stdin. This is > really easy to fix. In fact, I just did it. Charles wins the prize; apparently, I was misled by the message and foolishly believed telnet was describing the situation. I see a problem with the fix, however, in that an attempt to disconnect a telnet client from a remote server that has gone away may fail unless the fix was made to only apply to EOF on input instead of applying to both EOF on input and <escape><close>. I think you still want <escape><close> to cause the client program to exit immediately. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503172002.AA29797>