From owner-freebsd-net Mon May 15 18:42:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 27B2737B5E4 for ; Mon, 15 May 2000 18:42:54 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id VAA04858; Mon, 15 May 2000 21:42:37 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200005160142.VAA04858@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alexander Langer Cc: Barney Wolff , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: socket programming References: <3920178a0.244e@databus.databus.com> <20000515182635.A408@cichlids.cichlids.com> In-reply-to: Your message of "Mon, 15 May 2000 18:26:35 +0200." <20000515182635.A408@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 21:42:37 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Thus spake Barney Wolff (barney@databus.com): > > > Sigh. Quoting RFC 857: > > Either you are right and all telnet-clients I can use atm (Linux, > Windows9x, FreeBSD) have implemented things wrong or maybe you are > wrong. > If you are right, I suggest you rewrite things and shout at the guys > that they have implemented the protocol wrongly and send them patches. > In this case, I was also right, since I said the things have the same > effect (on clients _I_ know, also, if this violates the RfC). I think Barney is correct. When I wrote my first telnet server in 1982, telnet worked that way, and it still works this way. Telnet option negotiation has been well understood for decades now. My personal experience with this was on a big, horrible mainframe computer which presumed half-duplex printing terminals and which didn't echo what you typed. (This is actually the default state when a telnet sessions begins; UNIX telnet servers negotiate WILL ECHO so that the local client doesn't echo what you type.) So, in my case, when the OS told me it was prompting for a password though a mechanism I won't describe to you here in case you're eating, my telnet server would claim to peform remote echoing, and then wouldn't during the duration of the password prompt. It then negotiated WONT ECHO with the telnet client, so that the local echoing resumed. Note that to really get this right, when the telnet server sends a WILL ECHO, you should wait for the client to respond with DO ECHO before sending the prompt to ensure that the client's local echo was been disabled. While you can probably get away with just jamming the various telnet control sequences into the TCP connection (e.g., IAC WILL ECHO), there really is a state machine on both sides, as well as byte-stuffing of the IAC (binary value 0xff) going on too. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message