Date: Fri, 11 Aug 95 11:58:54 MDT From: terry@cs.weber.edu (Terry Lambert) To: kallio@jyu.fi (Seppo Kallio) Cc: questions@FreeBSD.org Subject: Re: Some serious problems with telnet in FreeBSD 2.0.5 R ... more Message-ID: <9508111758.AA07856@cs.weber.edu> In-Reply-To: <v0151011aac50e53c88fc@[130.234.41.39]> from "Seppo Kallio" at Aug 11, 95 04:36:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508111758.AA07856>