From owner-freebsd-questions Fri Aug 11 11:06:21 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA00191 for questions-outgoing; Fri, 11 Aug 1995 11:06:21 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id LAA00184 for ; Fri, 11 Aug 1995 11:06:20 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA07856; Fri, 11 Aug 95 11:58:55 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508111758.AA07856@cs.weber.edu> Subject: Re: Some serious problems with telnet in FreeBSD 2.0.5 R ... more To: kallio@jyu.fi (Seppo Kallio) Date: Fri, 11 Aug 95 11:58:54 MDT Cc: questions@FreeBSD.org In-Reply-To: from "Seppo Kallio" at Aug 11, 95 04:36:00 pm X-Mailer: ELM [version 2.4dev PL52] Sender: questions-owner@FreeBSD.org Precedence: bulk Ah, some nice, concisely written and very specific questions! > The commercial software is called "PCTCP Software" (not TCP Software): > > - I cannot understand why Linux does not care if Enter == cr+lf or cr > I can change the setting in a emacs session an it has no effect. > But FreeBSD does not work correctly with cr+lf or with cr By default, Linux will negotiate non-binary mode. BSD negotiates binary mode, when in fact it should be negotiating 8bit but non-binary. It remains to be seen (read on) whether this is BSD's fault or not. BSD does this negotiation because it is the only way to cleanly support non-7-bit locale information across a Telnet session. The BSD negotiation is RFC compliant, so I think perhaps the client isn't responding with "DONT X" for BSD's "WILL X" for values of "X" not known to the client (this behaviour is mandated by RFC, and option definition is further mandated such that default is "WONT X". This means that it's either a WILL/DONT for an option all clients are required to know about or a WONT/DO for an option the client doesn't know about, but is turning on anyway. The first is a bug in the client operation and the second is an actual RFC violation (which is why I tend to beleive the first). The EOL character sequence is translated to a common line format for 8-bit non-binary mode, and is translated on both ends. A non-binary connection will correctly handle differing end-of-line characters. On the other hand, it will not allow SLIP tunneling using a PTY, so hacking BSD to support your broken client isn't really a good option (unless BSD is offering a WILL on a non-default option/extension -- a BSD bug). > The WinQVT/Net software seems to work fine. This implies a client bug again. WinQVT/Net will use EOL characters of CR/LF in non-binary mode which would result in two line-end characters instead of one. Unless the difference is that WinQVT supports binary mode correctly and PCTCP is responding incorrectly to option negotiation. > More problems in Macintosh NCSA Telnet 2.6 and DOS NCSA Telnet > > - in emacs Control-X Control-C seems to be same as Control-X Control-G. > Control-C alone is acting like Control-G: it beeps. > Control-C is showing C-c on the last line of emacs screen, > but why beep? > ** This is not the problem with "setup keys"! I have dissabled > Interrupt Process! ** Most likely, this is an incorrect assumption that the server is a 4.2BSD TCP/IP with the known bugs in out of band data. That it beeps in an emacs session is not indicative of "control-G"-ness; it is indicative of an Emacs command error. You should run "hd" or "od -hc" instead of emacs and send your keys. This will dump the incoming characters back to you as hex and character values a line (16 characters) at a time until you enter a ^D ("control-D"). This will allow you to see what is actuall being sent from your end (unless it's a ^D). > - in pine Control-Z and after fg it returns > to pine with redrawing the screen as it should. > What is the difference between pine (pico) and emacs+vi? > Why pico is making it correctly but emacs is not? The screen redraw is a result of one of two things: (1) a termcap based page flip using the termcap initialization/deinitialization string. This is the default mode of operation for X. Or (2), the program is catching the start signal and dealing with it (or setting a flag on the stop signal) and treating it as a redraw request by the user. There are several reasons you might want to do this in an editor, not the least of which is that you may want to see the results of your shell escape to determine your next edit. > - I have no problems with NCSA Telnet if I first login to > some other node (Linux, SunOS) and then make telnet into the > FreeBSD node. Only a direct NCSA Telnet into the FreeBSD node > dees not work. Seems a very obvious unitialized datum for the Binary mode option negotiation flag. NCSA Telnet should be corrected, one way or the other. Either it's a BSD bug for the initial negotiation and an NCSA bug for subsequent negotiations, or vice versa. I believe vice versa. > Related to DOS NCSA Telnet: > > It seems that after I one time try to connect with NCSA Telnet > all sessions seem to hang about 1-2 minutes from all PC:s and > Macintoshes with all emulatrors. It is hanging about 1-2 minutes > after the message "You have mail". The DOS terminal emulator does not react correctly to partial escape sequences. It also does not trap cursor relocation address ranges. Most probably, you are unconditionally running "resize" in your .cshrc or .profile or .bashrc, etc. You should only run "resize" for a terminal type of "xterm" to be sure to not confuse some terminals. If you want to "live on the edge", you can check only for the explicit terminal type sent in by the offending emulator. Basically, an untrapped screen position causes the emulator to start writing whatever memory follows the emulation screen memory. It is also possible that the emulation does not correctly handle partial escape sequences while allowing commands from the user to be sent to the remote system prior to the completion of the sequence. This is a bug in the I/O queueing model in the emulator. Finally, it's possible that the telnet is incorrectly negotiating line mode for something other than a tty connection (ie: the type of connection you would get for a mud or irc if they were propoerly wrapped with telent option negotiation on the line -- most aren't). > One more question: Whereis terminfo? Man terminfo is saying > /usr/lib/terminfo but that is not correct. Is there terminfo in FreBSD? Terminfo is non-default. When linking with the correct libraries, a terminfo database per se is not required. The default under BSD is termcap. For more information, you should read the terminfo man page in detail. If you have a source tree, you should also take a look at: /usr/src/lib/mytinfo /usr/src/lib/ncurses Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.