🚀 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:

   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.