[nos-bbs] JNOS <-> WL2K forwarding over telpac connection -

[Barry Siegfried]

[Jay Nugent <jjn at nuge.com> wrote]:

> Telnet has been a problem in many ways.  Some telnet servers and
> clients fail to properly support "NVT" Network Virtual Terminal, and/or
> fail to negotiate the 'proper' terminal settings when the telnet session
> is first established.  This has been most prevelent in M$ products.

Boy is *that* ever true!  :(

> More, below...
>
> On Tue, 7 Mar 2006, Barry Siegfried wrote:
>
> > Hi, Maiko (et al)...
> >
> > > It needs work, more later.
> > >
> > > > This should also give us telpac if we can handle the various
> > > > transparent modes and CR/LF options.
> > >
> > > That's what I'll have to figure out. The CR/LF options are not a
> > > big deal now that I know about the CR only (like early XFBB).
> >
> > I don't know if this will help you, but back in the days when I
> > was a mere lad, there was a short thread on the old nos-bbs list
> > about the JNOS telnet dropping the first character of a line.  I
> > don't know much about "telpac" or what its EOL protocol is (I am
> > extrapolating by your discussion that it is a CR-only protocol),
> > but the following exchange might help you with ASCII-style socket
> > EOL translation which always seems to have been difficult to get
> > working under <all> circumstances.  If you would like, I can make
> > the algorithm and the code available to you which solved this EOL
> > translation problem in recvchar().
> >
> > Here is the original short thread:
> >
> > Date: Wed, 27 May 1998 04:02:29 -0400
> > Message-Id: <12141.bgs at k2mf.ampr.org>
> > From: "Barry Siegfried" <bgs at k2mf.ampr.org>
> > Subject: Re: telnet dropping first character
> >
> > [aa5mt at gate.kc5aug.ampr.org wrote]:
> >
> > > On some telnets, I drop the first character of every line.
> > > On others, all is ok.  I know it's somewhere in my setup.
> >
> > It is not.
> >
> > > I drop the first character at home and on the bbs using JNOS.  I
> > > tried telnetting from ucsd.edu and all is ok to the same site.
> > > Where should I begin looking?  It should be an easy fix I would think.
> >
> > Actually, it isn't an easy fix, but there is one.  The problem is not
> > really with NOS.  What is happening is that you are telneting to a site
> > at which the socket code there is not translating its application to use
> > the standard internet end-of-line sequence, which is CR-LF, over your
> > connection.  The site to which you are telneted is probably marking its
> > end-of-lines with only a CR instead.  NOS properly interprets the next
> > character received after the first end-of-line character in such cases
> > as the second end-of-line character and throws it away, even if it is
> > not.
> >
> > This is a typical problem at sites where the application you are using
> > formerly ran (or simultaneously runs) over a terminal modem connection,
> > where the use of only a CR to mark end-of-lines is commonplace.
> >
> > Selcuk Ozturk, N3YCO and I worked on this several years ago.  The
> > subfunction recvchar() in SOCKUSER.C must be modified to accommodate
> > these broken end-of-line sequences from these servers.  It can be done
> > but it requires the addition of another variable to the user socket
> > structure and some juggling of code inside recvchar().  Note also
> > that this change will also affect the "recording" of such sessions
> > into a disk file and the subfunction which handles that must also
> > be modified to accommodate the changed code in recvchar().

Maiko, the following is primarily for you if you want to try coding
my solution on your own.  In plain English, the algorithm would be:

First create two more variables in the usock struct, one to use
in place of the 'int c' variable in recvchar() and one to use as
a received flag to indicate that the last character received in
an input stream did not belong to the EOL sequence and the character
received immediately prior to it was the first character of a 2-
character EOL sequence.

1) Upon entering recvchar(), if both the socket mode is ASCII *and*
the received flag is set (which tells us that last character received
was the next character in the input stream that immediately followed
the first character of a 2-character EOL sequence and did not belong
to the EOL sequence itself) then clear the received flag and go
directly to step 6 (skip steps 2, 3, 4 and 5).

2) The socket mode is not ASCII *or* the received flag is clear so
call rrecvchar() normally to get the next character.  If the socket
mode is not ASCII *or* the next character is not the first character
of the EOL sequence then go directly to step 6 (skip steps 3, 4 and
5).

3) If the socket mode is ASCII *and* the next character is the first
character of a 2-character EOL sequence then call rrecvchar() again
immediately to get the next character.  If the next character after
the first character of a 2-character EOL sequence belongs to the EOL
sequence then go directly to step 5 (skip step 4).

4) The next character after the first character of a 2-character EOL
sequence does not belong to the EOL sequence.  Set the received flag.

5) Return a linefeed to the caller.  STOP here.

6) Return the next character to the caller.  STOP here.

> Per RFC-854:
> --------------------------------------------------------
> 1.  When a TELNET connection is first established, each end is
>    assumed to originate and terminate at a "Network Virtual Terminal",
>    or NVT.  An NVT is an imaginary device which provides a standard,
>    network-wide, intermediate representation of a canonical terminal.
>    This eliminates the need for "server" and "user" hosts to keep
>    information about the characteristics of each other's terminals and
>    terminal handling conventions.  All hosts, both user and server, map
>    their local device characteristics and conventions so as to appear to
>    be dealing with an NVT over the network, and each can assume a
>    similar mapping by the other party.  The NVT is intended to strike a
>    balance between being overly restricted (not providing hosts a rich
>    enough vocabulary for mapping into their local character sets), and
>    being overly inclusive (penalizing users with modest terminals).
> -----------------------------------------------------------
>
> This bites us in the butt every time a MicroShaft user attempts to
> telnet over the Internet to a JNOS box.  He either loses the first
> character of every line, is required to send TWO CR's at the end of
> every line, or has NO echo and has to type in the blind.

The awful M$ telnet client does have SET/UNSET options, two of which
are SEND CRLF and LOCAL ECHO.  Therefore you can set your M$ telnet
client to SEND CRLF which gets rid of the first problem and LOCAL ECHO
which gets rid of the second problem.  The local echo solution is not
the best but at least it works (since the telnet server in NOS variants
will not echo characters).

> I have always believed this to be a more recent MicroShaft problem,
> as it used to work in the Win3.1 and Win95 days, *may* have worked
> with Win98 as well (my memory is a bit crusty).  But it absolutely
> FAILS with the telnet client in WinXP-Pro :-(

The telnet client in WinXP-Pro is broken beyond belief.

> The solution has been to use "Putty" which DOES properly support
> NVT and/or negotiate the terminal parameters.

Or, if you must use a M$ telnet client, steal the one from Windows
2000 and replace the one in WinXP-Pro with it.

> So, to bring this back on topic:  Does the telnet server that WinLink
> is using (being M$ based) support NVT and the terminal parameter
> negotiation?  Or are they just as buggered up as the rest of the M$
> telnet tools?

We can guess.  :\

> Point is:  You will likely have to code around all the M$ mistakes in
> its implementation of TELNET as they obviously never read nor followed
> the RFCs.  But hey, they're big, they don't need no stinkin' rules...
> DOH!!!

Right.  And what is even worse is when M$ makes new rules and doesn't
tell anybody!

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at nnj.k2mf.ampr.org     |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+