🚀 go-pugleaf

In article <1ck9arINNjro@gap.caltech.edu> heirich@punisher.caltech.edu (Alan Bryant Heirich) writes:
>
>-- 
>I run PPP at home and at a remote machine "CIT".  I can connect
>to CIT three ways:
>
>1) direct dial a modem connected to the machine 
>2) dial a modem connected to a terminal server connected to the machine
>3) dial another machine on the internet, and connect via telnet.
>
>If I use (2) or (3), and can establish an 8 bit clean path, can I
>run PPP successfully?  I have been told the following:
>

I use the PPP for Sparc which comes with a little routine called CHAT.  Very
simple but it does the job.  Here are the ways I connect to other PPP "sides"

1) Call from my SS1+ to a Telebit Netblazer (NB), log into a NB login with
a password, then establish a PPP connection.  This works great.  The NB
setup up SLIP and other PPP links to other NB and ethernet segments.

2) Call from the SS1+ to a Sun 390 running PPP (same one), go though a
Datakit(r) Virtual Switch, to get to the 390, log in, then start PPP.


Both work well.  I use #1 most of the time because I spend most of
my time with PPP at home.


=============================
John Sottile                             "That Guy has to Oil his Brakes!"
AT&T Bell Labs                           #include <std/disclaimer/who-me?.h>
jjs@cblph.att.com

Alan Bryant Heirich writes:
>
>-- 
>I have been given conflicting answers to the following question,
>can anyone give me more?
>
>I run PPP at home and at a remote machine "CIT".  I can connect
>to CIT three ways:
>
>1) direct dial a modem connected to the machine 
>2) dial a modem connected to a terminal server connected to the machine
>3) dial another machine on the internet, and connect via telnet.
>
>If I use (2) or (3), and can establish an 8 bit clean path, can I
>run PPP successfully?  I have been told the following:
>
>a. not unless you use Morningstar PPP (public domain can't do it)
>b. yes, using dp-beta
>c. (your response?)
>

c) I run the PD version of PPP (for NeXT) from my home NeXT and
connect to a Sparc running the Sparc PD version of PPP.  I dial a
Telebit trailblazer, telnet to the sparc (since the PPP option on the
Telebit is disabled), and start PPP.  The only catch to make this work
is that you must set the telnet link to binary (passall) mode before
you start PPP. 

- Steve


-- 
====================================================================
Stephen Perkins                    |
Department of Computer Science     | perkins@cps.msu.edu
Michigan State University          |

Interesting, looks like you're stuck if you use rlogin.  Has anyone tried
an 8 bit clean version of telnet?

In article <1ck9arINNjro@gap.caltech.edu> heirich@punisher.caltech.edu (Alan Bryant Heirich) writes:
   I run PPP at home and at a remote machine "CIT".  I can connect to
   CIT three ways:

   1) direct dial a modem connected to the machine 
   2) dial a modem connected to a terminal server connected to the machine
   3) dial another machine on the internet, and connect via telnet.

   If I use (2) or (3), and can establish an 8 bit clean path, can I
   run PPP successfully?  I have been told the following:

   a. not unless you use Morningstar PPP (public domain can't do it)

I hope you didn't interpret that as simply a crass FUD-based attempt
to sell you Morning Star's software.  Here's a more fully elaborated
scoop:

We use rlogin paths all the time to carry PPP traffic.  We found that
the links would occasionally hang in mid-session, and diagnosed that
hang as being caused by the presence of a 0xff character in the user
data, which rlogin (RFC-1282) considers to be a magic cookie prefix
for in-band control sequences (e.g. to transmit a SIGWINCH).  Since
0xff is outside the range that can be negotiated using the LCP
Async-Control-Character-Map mechanism, some special means must be
exercised to keep it from being a part of the user data stream.  Our
PPP product has a special command-line option that can be used to
cause (almost) any character to be (unilaterally and without
negotiation) escaped before transmission.  I don't know of any other
PPP implementation with that capability; therefore no other PPP would
be completely safe to use across an rlogin stream.

If you never change a window size around a telnet or rlogin session,
causing transmission of a SIGWINCH, then your connection via method
(3) should work fine.  Unless, of course, your telnet wants to use
other magic cookies too.

If your method (2) traverses the network in something other than an
rlogin stream, then it should be fine.  If the terminal server is
"connected" to the destination machine via rlogin, then you need to be
careful about what user data crosses the link.

There's nothing magical about our product's "escape" command line
option.  Anyone else could implement it, with similar effects.

In article <BOB.92Nov3145722@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:

  Since
  0xff is outside the range that can be negotiated using the LCP
  Async-Control-Character-Map mechanism, some special means must be
  exercised to keep it from being a part of the user data stream.

Surely you're not serious.  The ppp folks provided an escape mechanism for
characters that can't be sent transparently, then limited the scope of that
mechanism?  That seems seriously stupid to me.  What could they possibly
have been thinking?

In article <5c5436cd.1bc5b@pisa.citi.umich.edu> rees@pisa.citi.umich.edu (Jim Rees) writes:
   In article <BOB.92Nov3145722@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
     Since 0xff is outside the range that can be negotiated using the
     LCP Async-Control-Character-Map mechanism, some special means
     must be exercised to keep it from being a part of the user data
     stream.

   Surely you're not serious.  The ppp folks provided an escape
   mechanism for characters that can't be sent transparently, then
   limited the scope of that mechanism?  That seems seriously stupid
   to me.  What could they possibly have been thinking?

The escaping mechanism isn't limited, only the negotiation mechanism.

Since the initial asyncmap is 32 "1" bits for guaranteed transparency,
LCP negotiations (including negotiations regarding the eventual
operational asyncmaps) progress with all the async control characters
escaped into two-byte pairs, each consisting of a 0x7D flag followed
by a byte that's the original byte XOR'd with 0x20.  Each byte of any
resulting escaped pair is thus outside the range of the asyncmap.

If the initial asyncmap were 256 "1" bits, what byte range would you
use for negotiations?  Everything would need to be escaped, but even
those escaped results would need to be escaped before transmission.
What would they transform into?  If you wanted to leave some
"printable" characters out of the 256-bit wide all-ones initial
asyncmap so that they'd be available for negotiation, how would you
know which ones to leave out, without first negotiating them somehow?

Only the negotiation mechanism is so limited, but the escaping
mechanism can be used on (almost) any character without in-band
negotiation.  This breaks the general philosophy of "no a-priori
configuration", but no good general solution has been proposed, and
this workaround is at least pragmatic, though ugly.

(Actually, the escaping mechanism is also limited, but not as badly as
the negotiation mechanism.  You can't escape 0x5E, 0x7D or 0x7E
because their XOR-with-0x20 results would collide with PPP's HDLC
framing character, the escape leadin, and with each other, resulting
in unresolvable ambiguities.)

In article <BOB.92Nov13105133@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:

  If the initial asyncmap were 256 "1" bits, what byte range would you
  use for negotiations?

Obviously, the initial negotiation should be done using nothing but 7-bit
printing ascii characters.  Certainly it shouldn't depend on being able to
send 7f or ff transparently!