Date: Mon, 15 May 2000 21:42:37 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Alexander Langer <alex@big.endian.de> Cc: Barney Wolff <barney@databus.com>, freebsd-net@FreeBSD.ORG Subject: Re: socket programming Message-ID: <200005160142.VAA04858@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 15 May 2000 18:26:35 %2B0200." <20000515182635.A408@cichlids.cichlids.com> References: <3920178a0.244e@databus.databus.com> <20000515182635.A408@cichlids.cichlids.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005160142.VAA04858>