Subject: comp.protocols.ppp frequently wanted information

From: [email-masked] (Ignatios Souvatzis)
Date: Mon, 2 Aug 1993 18:14:08 GMT

Archive-name: ppp-faq/part1
Version: $Revision: 2.21 $
Last-modified: $Date: 93/07/26 20:10:01 $

0.0 Important Announcement:

An alpha-release html version of this document can be found at URL
"http://cs.uni-bonn.de/ppp/faq.html".

0.1 Introduction

I took the Information in Ed Vielmetti's FAQ files, my personal experience,
and lots of stuff from comp.protocols.ppp, and built a new one for them.
This posting will be reposted fortnightly, as soon as it is fairly stable,
and weekly till then. Changed sections are marked in the index with a ! or
+ for something got added or - for something got deleted.

The major sections start with a ^L, so hit the spacebar on the --more--
prompt.

0.2 Information wanted:

If you have experience with anything mentioned here, or know of newer
versions, or of versions of software for other hardware/OS, or ...

send me mail. I'll include it and possibly mention your name, if you don't
express otherwise.

 1. INDEX TO THE FAQ:

 2. What is PPP?

 2.1 Introduction
 2.2 PPP features which may or may not be present
 2.3 PPP glossary
 2.4 PPP-relevant RFC's

 3. How to: (configuration recipes and the like)

 3.0 complain about missing or incorrect information in the FAQ list 
 3.1 connect a single host to a network without needing a new subnet.
 3.2.1 configure KA9Q PPP and it's Unix counterpart
 3.2.2 configure the new KA9Q dialer
 3.2.3 configure JNOS
 3.3 configure NCSA with the merit ppp driver and its unix counterpart
 3.4 work BOOTP over protocols such as SLIP or PPP
 3.5 configure free ppp for sun to interoperate with MacPPP 1.0b1
 3.6 get SCO TCP 1.2 to connect to Ethernet LANs by a PPP link
 3.7 use PPP through a X.25 PAD
+3.8 use SunLINK PPP 1.0 to a CISCO through a sync line

 4. Real PPP questions with answers
 4.1 Does somebody have a patent on PPP? [no]
 4.2 Is it possible to use PPP as link layer in ISDN? [yes]
 4.3.1 My ppp does infinite configuration negotiation. What's wrong? [cable]
 4.3.2 My ppp does infinite ... What's wrong? [IP address configuration]
 4.4 What is Asychronous HDLC? [read rfc1331]

 5. Free PPP software packages.

 5.1 free PPP FOR SunOS 4.1.x:
 5.1.1 ppp-1.2.tar.Z, works also on BSD (386BSD: 0.1)
 5.1.1.2 pppd-1.01.tar.Z
!5.1.2 dp-2.3.tar.Z
!5.1.3 Perkins/Clements/Fox/Christy PPP for SunOS

 5.2 free PPP for BSD:
 5.2.1 ppp-1.2.tar.Z, see 5.1.1

 5.3 free PPP for SVR4:

 5.4 FREE PPP FOR MSDOS:

 5.4.1 WG7J NOS ppp additions:
 5.4.2 PPP for NCSA telnet:

 5.5 free PPP for AmigaOS:
 5.5.1 AmigaNOS (KA9Q NOS for Amiga):

 5.6 free PPP for NeXT:

 5.7 free PPP for Macintosh:

 6. ftp sites for PPP stuff, docs etc.

 7. Commercial PPP software packages.
 7.1 Amiga Inet:
 7.2 Commercial PPP packages for MS-DOS and MS-Windows
 7.2.1 MSDOS with and without MSWindows

 7.2.1.1.  LAN WorkPlace for DOS 4.1 beta (see also 7.2.2)
 7.2.1.2.  PC/TCP 2.11
 7.2.1.3.  Distinct TCP/IP 3.0 beta
 7.2.1.4.  Super-PPP for Windows 1.0 beta
 7.2.2 MSDOS/Novell:

 7.3 386/486 PC's with SCO Unix:

 7.4 for lots of computers running some Unix derivate:

 7.5 for SUN computers running SunOS

 7.5.1 Morning Star PPP. see 7.4
 7.5.2 Brixton PPP
 7.5.3 SUNlink PPP 1.0

 7.6 for NeXT
 7.6.1 Morning Star PPP see 7.4
 7.6.2 Marble Teleconnect

 8. PPP hardware.
 8.1 Hardware that does async PPP
 8.2 Hardware that supports sync PPP
 8.3 Recent summaries stuff from the net, will be merged with the rest later

 9. (incomplete) Acknowledgements

2. What is PPP?

2.1 Introduction
PPP is the Internet Standard for transmission of IP packets over serial
lines. PPP supports async and sync lines. For a general discussion of PPP,
and of the PPP vs. SLIP question, look at the paper

ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (paper) and
		sug91-cheapIP.shar.Z (overhead projector slides)

2.2 PPP features which may or may not be present

Above and beyond compatibility with basic PPP framing, note whether
the software implements the following features.  Not all features are
needed or even desired in every product.

- "demand-dial".  Bring up a PPP interface and dial the phone when
  packets are queued for delivery; bring the interface down after some
  period of inactivity.

- "redial".  (For lack of a better term).  Bring up a PPP
  interface whenever it goes down, to keep a line up.

- "scripting".  Negotiate through a series of prompts or intermediate
  connections to bring up a PPP link, much like the sequence of events
  used to bring up a UUCP link.

- "parallel".  Configure several PPP lines to the same destination and
  do load sharing between them.  (Not standardized, usually only seen
  in SLIP implementations, noted there as "parallel-slip".)

- "filtering".  Select which packets to send down a link or whether to
  bring up a "demand-dial" link based on IP or TCP packet type or TOS,
  e.g. don't dial the phone for ICMP ping packets.

- "header compression".  TCP header compression according to RFC 1144.
  Marginally useful on high speed lines, essential for low speed lines.

- "server".  Accept incoming PPP connections, which might well also
  include doing the right things with routing.

- "tunneling". build a virtual network over a PPP link across a TCP stream
   through an existing IP network

- "extra escaping". byte-stuffing characters outside the negotiated
  asyncmap, configurable in advance but not negotiable

2.3 PPP glossary

~From: [email-masked] (Edward Vielmetti) [and others]
~Subject: PPP glossary

Every new technology breeds its own set of acronyms.  PPP is no
different.  Here is a glossary of sorts.
	
ack	Acknowledgement.
AO	Active open [state diagram] (no lonter part of the FSM as of RFC 1331)
C	Close [state diagram]
CHAP	Challenge-Handshake Authentication Protocol (RFC 1334)
D	Lower layer down [state diagram]
DES	Data Encryption Standard
DNA	Digital Network Architecture
IETF	Internet Engineering Task Force.
IP	Internet Protocol
IPCP	IP Control Protocol.
IPX	Internetwork Packet Exchange (Novell's networking stack)
FCS	Frame Check Sequence [X.25]
FSA	Finite State Automaton
FSM	Finite State Maschine
LCP	Link Control Protocol.
LQR	Link Quality Report.
MD4	MD4 digital signature algorithm
MD5	MD5 digital signature algorithm
MRU	Maximum Receive Unit
MTU	Maximum Transmission Unit
nak	Negative Acknowledgement
NCP	Network Control Protocol.
NRZ	Non-Return to Zero bit encoding. (SYNC ppp default because of
	availability) 
NRZI	Non-Return to Zero Inverted bit encoding. (SYNC ppp preferred
	alternative to NRZ)
OSI	Open Systems Interconnect
PAP	Password Authentication Protocol (RFC 1334)
PDU	Protocol Data Unit (i.e., packet)
PO	Passive open [no longer part of state diagram]
PPP	Point to Point Protocol (RFC 1331, 1332, 1333, 1334, 1362, 1376, 
	1377, 1378)
RCA	Receive Configure-Ack [state diagram]
RCJ	Receive Code-Reject [state diagram]
RCN	Receive Configure-Nak or -Reject [state diagram]
RCR+	Receive good Configure-Request [state diagram]
RER	Receive Echo-Request [no longer part of state diagram]
RFC	Request for Comments (internet standard)
RTA	Receive Terminate-Ack [state diagram]
RTR	Receive Terminate-Request [state diagram]
RUC	Receive unknown code [state diagram]
sca	Send Configure-Ack [state diagram]
scj	Send Code-Reject [state diagram]
scn	Send Configure-Nak or -Reject [state diagram]
scr	Send Configure-Request [state diagram]
ser	Send Echo-Reply [no longer part of state diagram]
sta	Send Terminate-Ack [state diagram]
str	Send Terminate-Request [state diagram]
ST-II	Stream Protocol
TO+	Timeout with counter > 0 [state diagram]
TO-	Timeout with counter expired [state diagram]
VJ	Van Jacobson (RFC 1144 header compression algorithm)
XNS	Xerox Network Services

2.4 PPP relevant RFC's:

Here's a list with descriptions.  Note some of these are obsolete.

1378  PPP AppleTalk Control Protocol (ATCP). Parker, B.  1992 November; 16 p. 
      (Format: TXT=28496 bytes)

1377  PPP OSI Network Layer Control Protocol (OSINLCP). Katz, D.  1992 
      November; 10 p. (Format: TXT=22109 bytes)

1376  PPP DECnet Phase IV Control Protocol (DNCP). Senum, S.J.  1992 November;
      6 p. (Format: TXT=12448 bytes)

1362  Allen, M.  Novell IPX Over Various WAN Media (IPXWAN).  1992 September;
      18 p. (Format: TXT=30220 bytes)

1334  PPP authentication protocols. Lloyd, B.; Simpson, W.A.  1992 October; 
      16 p. (Format: TXT=33248 bytes)

1333  PPP link quality monitoring. Simpson, W.A.  1992 May; 15 p. (Format: 
      TXT=29965 bytes)

1332  PPP Internet Protocol Control Protocol (IPCP). McGregor, G.  1992 May; 
      12 p. (Format: TXT=17613 bytes)  (Obsoletes RFC 1172)

1331  Point-to-Point Protocol (PPP) for the transmission of multi-protocol 
      datagrams over point-to-point links. Simpson, W.A.  1992 May; 66 p. 
      (Format: TXT=129892 bytes)  (Obsoletes RFC 1171, RFC 1172)

1220  Point-to-Point Protocol extensions for bridging. Baker, F.,ed.  1991 
      April; 18 p. (Format: TXT=38165 bytes)

1172  Point-to-Point Protocol (PPP) initial configuration options. Perkins, 
      D.; Hobby, R.  1990 July; 38 p. (Format: TXT=76132 bytes)  (Obsoleted by
      RFC 1331, RFC 1332)

1171  Point-to-Point Protocol for the transmission of multi-protocol datagrams
      over Point-to-Point links. Perkins, D.  1990 July; 48 p. (Format: 
      TXT=92321 bytes)  (Obsoletes RFC 1134; Obsoleted by RFC 1331)

1134  Point-to-Point Protocol: A proposal for multi-protocol transmission of 
      datagrams over Point-to-Point links. Perkins, D.  1989 November; 38 p. 
      (Format: TXT=87352 bytes)  (Obsoleted by RFC 1171)

[email-masked] (Bob Sutterfield) wrote in comp.protocols.ppp
(Message-ID: <[email-masked]>):

All of 1134, 1171, and 1172 (and 1055, for that matter :-) have been
obsoleted.  They're interesting only if you want to debug a connection
with an ancient PPP implementation, and you're wondering why (e.g.) it
asked you for IPCP option 2 with a length of only 4, and
Compression-Type 0x0037.

(There's a lot of that still running around - be careful out there.)


3. HOW TO (configuration recipes)

3.0 complain about missing or incorrect information in the FAQ list

E-mail to [email-masked] (Ignatios Souvatzis), and add
information I'll need to think about it. That is:

- In case of incorrect information, send me the correct information and the
   source of it.
  
- In case of missing information, send me the information which is missing and 
  the source of it.

3.1 connect a single host to a network without needing a new subnet.

~From: [email-masked] (Ignatios Souvatzis)

If you have only one single machine on the other side, the easiest way
is to give it a IP address belonging to the local ethernet/IP subnet,
and to tell the ppp gateway machine to advertise (proxy arp) its own
ethernet address as the other machines'. Works like a charm here. Of
course, for a large group or complicated network on the other side,
you would get more management problems. 

On the gateway do:

arp -s othermachinesipaddress myownethernetaddress permanent public
ifconfig pppNUMBER myipaddress othermachinesipaddress [other params] up

on remote machine:

ifconfig pppNUMBER gatewaysipaddress [other params] up
route add default gatewaysipaddress 1

pppNUMBER might be spelled as dpNUMBER for dialup IP.

Of course, if you use routeing daemons, you could also propagate the
route via routed / gated etc. to other machines, but it's more painful
because every machine has to do it (and might choose not to do it),
and every machine doing IP on a Ethernet HAS to talk arp.

On intermittently connected demand-dialed links, you may need to edit
/etc/gateways to define the destination of the PPP or SLIP connection
as a "passive" link.  Otherwise, routed will remove routes from the
kernel's routing table that use that link, because it won't hear RIPs
coming from hosts or routers across the wire.  Since it doesn't hear
anything from hosts or routers on the far side of the wire, routed
assumes that the link is dead forever.

3.2.1 configure KA9Q PPP and it's Unix counterpart

~Newsgroups: comp.protocols.ppp
~From: [email-masked] (Kim Toms)
~Subject: Re: PPP for DOS? (good info for FAQ)
~Date: Wed, 9 Dec 1992 06:26:28 GMT

I have been able to use the ka9q software on my PC to call my Suns at
work.  This is available from merit.edu:/pub/ppp/ka9q.zip. I had to
tell our Sun product [that would be Morning Star PPP, see below. I.S.]
"nolqm" in order to prevent it from hanging up because of an lqm
failure, but other than that, I have had no trouble.

Below, I include the configuration I use on my pc.  I unpacked the
ka9q distribution into \ka9q.  All the configuration files are located
there.

I have also been able to use the NCSA telnet packet driver, however, I
could not use ftp with that, so I gave it up some months ago.

Here's what I use on the PC:

In a file called "doit2.bat";
net -d \ka9q dialup.net

In a file called "dialup.net";
ip address 137.175.2.42
attach asy 0x3f8 4 ppp pp0 1024 256 9600
dialer pp0 dialup.ppp
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
route add default pp0
ip ttl 32
tcp mss 1460
tcp window 2920
domain addserver 137.175.2.11
domain suffix MorningStar.Com
domain cache clean on
start echo
start discard
start telnet
start ftp
start finger
start ttylink

In a file called "dialup.ppp";
control down
wait 1000
control up
wait 1000
wait 2000
send "at\r"
wait 3000 "OK"
send "atdt4515016\r"
wait 60000 "login: "
send "<username>\r"
wait 5000 "word:"
wait 1000
send "<password>\r"

3.2.2 configure KA9Q PPP (with new dialer) and it's Unix counterpart 

~Date: Wed, 3 Feb 93 17:18:02 +0100
~From: [email-masked] (Swa Frantzen)
To: [email-masked] (Ignatios Souvatzis)
~Subject: Re: comp.protocols.ppp frequently wanted information

I'm using ka9q for slip dialup. (ppp will follow soon) Being a novice to
it, I relied heavily on the ppp documentation the frequently wanted
information posting provides.

One thing has changed (somewhere) in the way the dailer command works.
The syntax has changed and the file(s) it uses have changed to.

I got my ka9q from simtel20 (actually a mirror: oak.oakland.edu) 
-> the file with the source was name s920603.zip,
the executable e920603.zip. All the documentation
I could find was at least a year older !

After sniffing through the sources, this is what I came up with:

In a file called "dialup.net";
...
dialer <interface> <timeout> <up_script> <down_script>
...

eg:

dial pp0 1000 dial.up dial.dwn

In a file called "dialup.dwn";
control down

In a file called "dialup.up";
control up
wait 100
send "at\r"
wait 3000 "OK"
send "atdt<number>\r"
wait 90000 "ogin:"
send "<username>\r"
wait 5000 "word:"
wait 100
send "<password>\r"

This will cause call on demand ->
If the link is idle (for some time), the thing will hang up
If you need the link the link will be established
I put in a bigger wait for the login prompt as it takes
a rather long time to synchonise using V32 and V32bis modems.

Since I had to go through the sources to find it out,
I figure others will be intersted in it too.

3.2.3 configure JNOS

I have jnos1.08 up and running. [that is, 'version 911229 (WG7J v1.08)'].
For a sample configuration and demonstration of operation, get the
configuration you can ftp from idefix.cs.uni-bonn.de, user ftp, directory
/pub. [i.s.]

3.3 configure NCSA with the merit ppp driver and its unix counterpart

~From: [email-masked] (Ignatios Souvatzis)

I had at least partial success using the parameters, to the public ppp for
SUNOS (dp-2.3, but I suspect any of dp-2.1 or dp-2.2* or pppd-1.01beta or
ppp-1.1 would have the same behaviour) -ac -pc vjmode draft. The latter
would be called in ppp-1.1 'vjmode rfc1331'.

3.4 work BOOTP over protocols such as SLIP or PPP

~Newsgroups: comp.protocols.ppp
~From: [email-masked] (Steven L. Johnson)
~Subject: Re: Tech?: BOOTP over SLIP or PPP
~Date: Wed, 2 Dec 1992 03:14:37 GMT

[email-masked] (John F. Moehrke (414-284-5559)) writes:

>Does anybody know if there is a description of how to work BOOTP over
>protocols such as SLIP or PPP. It seems this should work but the problem
>is that there is a field in the BOOTP header that contains the physical
>layer type, and these numbers are defined as the hardware types for ARP.
>Since SLIP and PPP do not use ARP, they do not have numbers.

I haven't looked very far, and would appreciate a pointer to any
previous work or concensus.  I've used a type 0 but only with a cisco
terminal server.  I don't know if this causes problems on other
implementations.

>The second problem is that the BOOTP header also contains a field
>for the physical layer address (i.e. Ethernet address). PPP and SLIP do
>not have an physical layer addresses. What does the BOOTP server have
>to base it's IP address suggestion on?

It's my understanding that PPP can itself negotiate the IP address
and that this is the preferred method.  If the IP address is included
in the bootp request then the remaining configuration is done based
on that IP address and not the hardware address.  With SLIP there
isn't this option, so the IP address must be assigned by knowing the
physical port on which the request was received.  Again, I used an
address of 0 (with a address length of 0, I think) and this didn't
seem to cause a problem.

On a terminal server that contained only a minimal implementation
of bootp, it was necessary to send two requests.  The first request
was satisfied by the terminal server and configured only the IP
address.  A subsequent request (that contained the IP address provided
by the first request) was forwarded by the terminal server to a
bootp server on the ethernet and provided the rest of the configuration
from a standard bootptab.

-Steve

3.5 configure free ppp for sun to interoperate with MacPPP 1.0

~From: [email-masked] (Guy K Hillyer)
Comments-by: Ignatios Souvatzis, marked with [comments... I.S.]
~Subject: Success with MacPPP
~Date: Wed, 20 Jan 1993 02:02:08 GMT

After many travails, I finally got MacPPP to work for me.  This is the
story of how I got it to work.  This account is purely anecdotal.  I
don't claim to know what is the best configuration, just what worked
for me.

I submit this for the benefit of other poor suckers who might
otherwise spend days getting a Mac/Sun PPP link to work, like I did.
I'm a happy camper now, and thanks to Larry Blunk @ merit.edu for
making his implementation freely available.  Now all I need is a T1
line to my house and I'll be all set. 

[I'm not sure MacPPP works on T1 lines, I'm pretty sure the Perkins et al.
 PPP doesn't work over T1 lines. I.S.]

After working with the beta release for a while, I picked up the
latest and greatest MacPPP at merit.edu.  The file is named
/pub/ppp/macppp1.0.sit.hqx.  I don't think there's any big difference
between that and the beta version, but the docs did have two or three
new sentences that helped to clarify matters.

The ppp I'm using on the UNIX side is the one identified as
`Perkins/Clements/Fox/Christy PPP for SunOS' in the comp.protocols.ppp
FAQ.  During the course of debugging my connection, I installed the
package identified in that document as dp-2.2, but it behaved in
exactly the same way as the other one did with regard to the problems
I was having, so I only tried it briefly.  It has some more advanced
capabilities so I may switch to it in the future, but for now I'm just
glad to have a working configuration.

Mac configuration:

    One mistake I made was ignoring the point made in the MacPPP docs
    about configuring MacTCP for server addressing.  I thought that
    "server addressing" implied that the mac would get its IP address
    from some kind of server on my network, using RARP or something
    like that.  I thought that didn't make sense in my situation, so I
    configured MacTCP for manual addressing.  In fact, I now believe
    that "server addressing" means that TCP gets the address from
    the IP layer.  I'm not an ISO networking model savant, so this

    [must be wrong... the IP layer gets its address from the PPP layer,
     which can do an address negotiation.]

    notion should be taken with a grain of salt.

    I also set MacTCP to have a "class C" network address.  I think
    this only matters for broadcast packets, because it sets the
    netmask.  Again, I'm treading on thin ice here.

    I set the IP addresses in the MacPPP control panel's IPCP
    configuration window.  This probably isn't necessary, but I
    wanted to make sure that I got a particular address.  If you set
    the addresses on the Mac side, you'll want to specify the
    addresses and disable IP address negotiation on the UNIX side
    ("-ip" option to ppp).

    I first got things working with VJ header compression disabled on
    both sides.  You may want to try it this way if you have any
    trouble.  This is set in the IPCP window.  If you disable VJ
    header compression on the Mac side, you'll want to disable it on
    the UNIX side as well ("-vj" option to ppp).

    [You probably need only to set it to 'draft'. The configuration
     negotiation should do the rest. The only reason you need a 'vjmode'
     option is that the format of the configuration option has changed and
     the older ones don't understand the format of the aug91draft or
     rfc1331 ones (which should be the same) I.S.]

    Once I got things working I turned on VJ header compression.  It
    only worked for me if I selected "draft" mode on the UNIX side
    ("vjmode draft" option to ppp).

Sun configuration:

    I configure the ppp interface like this:

	ifconfig ppp0 <Sun's IP addr> <Mac's IP addr> netmask 0xffffff00 down

    Then I start ppp like this:

	ppp -p vjmode draft -ip <Sun's IP addr>:<Mac's IP addr>

    [which is also about the configuration of dp-2.x, on the login line.
     You have to specify PPP_OPTIONS=vjmode,draft in the configuration file
     for the network interface used by the mac. For ppp-1.1/2.tar.Z, use
     'vjmode rfc1331' I.S.]

    The "-p" means passive, so the Sun waits for the Mac to start the
    handshaking.  My experience was that without -p, there was a very
    brief window during which the Mac could enter the negotiation, and
    if it missed window, then all was lost.

    "vjmode draft" means to use the new version of negotiation
    specified in the August 1991 Draft RFC for IPCP.  This is
    apparently the only version MacPPP knows how to deal with.  If
    you've disabled VJ header compression on the Mac, you should give
    "-vj" instead.

    "-ip" disables IP address negotiation.  It probably would work
    fine without this; I just haven't tried it that way.

3.6 get SCO TCP 1.2 to connect to Ethernet LANs by a PPP link

~From: [email-masked] (Bob Sutterfield)
~Subject: Re: PPP on SCO between different networks

In article <[email-masked]> [email-masked] (Peter Miles)
writes:
   I need to set up a UNIX system which is on an ethernet LAN (with
   its own IP address), so it can call up a PPP link to another
   network, and use a different IP address on the remote network.

There's a bug in SCO TCP 1.2 (but not in 1.1.3) that prevents this scenario
with SCO's PPP, and with any other PPP or SLIP software you might try to
use on your SCO system.  You can get the fix from
ftp.morningstar.com:pub/tools/SCO-route-fix, or through SCO's normal
support channels.

3.7 use PPP through a X.25 PAD

~From: [email-masked] (Markus Kuhn)
~Subject: Re: PPP or SLIP through PAD (X.29/X.25)
~Date: Mon, 5 Apr 1993 19:30:17 +0200
Organization: Regionales Rechenzentrum Erlangen, Germany

>Does anybody have experience with "tunneling" PPP and SLIP through the
>PAD-service (X.29 over X.25)? What I want is to let people dial up
>their PAD-service and send their PPP/SLIP packets across the X.25 network
>into the PAD-login of my UNIX-machine.
>This should be possible, but I guess the PAD-parameter configuration is critical??

Yes, that's of course possible, because that's the way I use PPP. Use
the PAD parameters for the following settings:

   - no escape character 1:0
   - local echo off 2:0
   - flow/control: RTS/CTS 5:2 (this is perhaps not a standard X.3 parameter)
   - PAD should not react on XON/XOFF signals 12:0

Other important values might be 3:0 4:1 9:0 10:0 13:0 14:0 15:0.

You need a PAD that supports CTS/RTS flow control, because I don't know about
PPP software that supports XON/XOFF (although this would be possible with
the right async map).

Markus

3.8 use SunLINK PPP 1.0 to a CISCO through a sync line

~Date: Fri, 23 Jul 93 11:40:10 +0200
~From: [email-masked] (Alain Mellan)

To connect successfully a Sun running 4.1.x and Sunlink PPP 1.0 to a Cisco, you
have to get patch 100941-02. Once it it installed, everything works smoothly,
as written in the documentation !

My sun is an SS2, running 4.1.2 (sun4c architecture). We have a 'Transfix'
digital leased line. That is: synchronous serial line, 64kbps.

The problem without the patch is that everything seems to be OK, except that
the MTU given by a 'netstat -in' on device ppp0 is set to 0.

-- Alain Mellan <[email-masked]>


4. Real PPP questions with answers

4.1 Does somebody have a patent on PPP?

~From: [email-masked] (Edward Vielmetti)
~Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386,comp.protocols.ppp
~Subject: Re: Public domain PPP for SCO 2.0??
~Date: 8 Dec 1992 06:04:52 GMT

[Somebody] wrote:
: 
: Doesn't matter.  I just read (in another newsgroup) that DEC has a
: patent on PPP, and is asking $5000 for a license.  That means no
: public domain PPP, and a rapidly increasing reluctance to support it
: from OEMs.  Stick with SLIP until something better comes along.

This is *not* true.

DEC has a patent application outstanding for the negotiation of a 48 bit
checksum which might be used in one of the option negotiation phases.  It
is not an essential part of PPP; many implementations currently do not
use this little tiny algorithm in the way they work, and they work just
fine.

There is no indication that the 48 bit FCS will be accepted or standardized
on by the IETF - from my reading of the  mailing lists traffic that is
unlikely at this point.

There are free PPPs and there will continue to be free PPPs.  You will
also more likely buy PPPs as part of hardware you buy.

...

4.2 Is it possible to use PPP as link layer in ISDN?

~Newsgroups: comp.protocols.ppp
~From: [email-masked] (Bob Sutterfield)
~Subject: Re: PPP in different subnets
~Date: Tue, 8 Dec 1992 22:03:56 GMT

In article <[email-masked]> [email-masked]
(Terje Dalen) writes:

   1. Is it possible to use PPP as link layer in ISDN?  If yes, what
      about signalling? Do you need to combine PPP with the I.451 for
      basic call control?

Yes, PPP is one of the optional encapsulations specified for use over
ISDN networks.  It's particularly useful where end-to-end out-of-band
negotiation facilities are unavailable.  Write to [email-masked]
or [email-masked] for details.

~From: Ignatios Souvatzis 1993 April 7

There are (at least) two drafts about IP over ISDN links.
1) nnsc.nsf.net:internet-drafts/draft-ietf-iplpdn-multi-isdn-00.txt
	  The Transmission of Multi-protocol Datagrams 
                    over Circuit-mode ISDN
by Keith Sklower, Computer Science Department,University of California,
Berkeley

promotes Frame Relay as the primary encapsulation for IP over ISDN, but
mentions PPP and X.25 as alternatives for specific needs.

nnsc.nsf.net:internet-drafts/draft-ietf-pppext-isdn-00.txt
                             PPP over ISDN

by W A Simpson, Network Working Group  

promotes PPP over ISDN.

4.3 My ppp does infinite configuration negotiation. What's wrong?

4.3.1 [cable problem]

Exclusively for the ppp-faq Ignatios Souvatzis ([email-masked]) 
writes:

Each other month somebody posts a question which essentially is the one
above. It could, of course, be some very strange set of configurations
options which get the ppp to never terminate the negotiation process
[typical situations listed in {4.3.x|x>1}. One other possibility was seen
many times on the derivatives of public ppp for suns, namely pppd-1.01beta
and dp-2.x.

Detailed symptoms (from a posting on the net, I saw similar logfiles some 
months ago):

  Typical debugging log output:

  Dec 18 16:11:01 pppd[1694]: Starting ppp daemon version 1.0beta patchlevel 1
  Dec 18 16:11:01 pppd[1694]: warning... not a process group leader
  Dec 18 16:11:01 pppd[1694]: pgrpid = 1694
  Dec 18 16:11:01 pppd[1694]: popped stream module : ttcompat
  Dec 18 16:11:01 pppd[1694]: popped stream module : ldterm
  Dec 18 16:11:01 pppd[1694]: Using unit ppp0
  Dec 18 16:11:01 pppd[1694]: hostname = Riga
  Dec 18 16:11:01 pppd[1694]: connect: ppp0 /dev/ttya
  Dec 18 16:11:01 pppd[1694]: fsm_sconfreq(c021): Sent id 1.
  Dec 18 16:11:01 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  Dec 18 16:11:01 pppd[1694]: Setting itimer for 3 seconds.
  Dec 18 16:11:04 pppd[1694]: Alarm
  Dec 18 16:11:04 pppd[1694]: fsm_sconfreq(c021): Sent id 2.
  Dec 18 16:11:04 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
  Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
  Dec 18 16:11:07 pppd[1694]: Alarm
  Dec 18 16:11:07 pppd[1694]: fsm_sconfreq(c021): Sent id 3.
  Dec 18 16:11:07 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.
  Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.

  ... [lots of repetitious logging deleted] ...

  Dec 18 17:02:24 pppd[1694]: Alarm
  Dec 18 17:02:24 pppd[1694]: fsm_sconfreq(c021): Sent id 254.
  Dec 18 17:02:24 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
  Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
  Dec 18 17:02:26 pppd[1694]: Hangup
  Dec 18 17:02:26 pppd[1694]: Untimeout 6194:16b38.
  Dec 18 17:02:26 pppd[1694]: Setting itimer for 0 seconds.
  Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ldterm
  Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ttcompat
  Dec 18 17:02:26 pppd[1694]: fcntl(F_SETFL, fdflags): Bad file number

  The above final is caused by sending a SIGHUP to the pppd process
  (however three successive SIGKILL's seem to be necessary to really
  get rid of it).

  The warning "not a process group leader" appears to be the
  innocent result of a subtle coding bug, with no later effects,
  but I haven't tried fixing it (variable "pid" uninitialized).

  During all this, there seems to be no activity on the serial line, as
  evident from an Interfaker(tm) breakout patch box.  I was desperate
  enough to lower the speed to 50 bps in order to verify this.

  At the same time, "netstat -i" does show increasing figures for the
  ppp0 interface in the "Opkts" column, but in no other column.  

Solution: in all cases I could solve, it was a case of missing modem
control lines in the cables, leading to 'cts' floating to 'false'. The LCP
FSM happily sent configuration requests (they went to the serial line
driver buffer (and not out)), waited for an answer, got none, timed out,
and retried. After lots more of retries, especially on a big machine, the
send buffer finally does overflow, and ppp stops with an error message.

You just have to connect 2,3,4,5,6,7,8 and 20 to the modem to repair it, or
to wire a reasonably complete null-modem cable. No, there is no software
hack, except when you patch the sources yourself. And that would be a bad
idea in my opinion. Even a small Sparcstation SLC can overload any modem on
a serial line, and you would get lots of unnecessary packet drops because
of that.

4.3.2 [address configuration error]

~From: Wolfgang Rupprecht <[email-masked]>
~Date: Tue, 1 Jun 1993 09:01:52 -0700

>Each other month somebody posts a question which essentially is the one
>above. It could, of course, be some very strange set of configurations
>options which get the ppp to never terminate the negotiation process, but
>this seems unlikely. 

This does happen under dp-2.3 [and probably others, i.s.] when both sides
of the link have differing opinions as to what the 2 IP addresses should
be.  If the remote-address offered from the remote side doesn't match the
locally configured version then dp-2.3 will send back an REJ packet.  The
remote side will then resend the original address again and the loop will
continue.

To see if this is the case check the log for address REJ's.  Then decode
the two hex addresses and print it out in the normal dot notation.  This is
the IP address pair of what dp-2.x expected and what it got.  Now either
reconfigure dp-2.x to expect this address or change the address that the
other side is sending.

-wolfgang

4.4 What is Asychronous HDLC?

~From: [email-masked] (Ignatios Souvatzis)
~Subject: Re: Asynchronous HDLC, what is it?
~Date: Wed, 3 Feb 1993 11:25:21 GMT

It's HDLC with a character-by-character encapsulation, rather than
a bit-by-bit encapsulation. The details are discussed in the RFC1331,
appendix A. Basically, the flag character, the escape character and
(possibly) control characters are escaped by prepending the escape
character and XORing them with 0x20, while sync hdlc transparently
inserts '0' bits after sequences of 5 '1' bits to be sure to never
transmit the flag character in the frame.

A short description of the part of ISO 3309:1991 that describes async
(ISO calls it start/stop mode) HDLC is available with anonymous ftp from
ftp.uni-erlangen.de in pub/doc/ISO/english/async-HDLC.
   

5. free PPP software packages.

5.1 free PPP FOR SunOS 4.1.x:

5.1.1 ppp-1.2.tar.Z
  Author: Brad Parker <[email-masked]>
  Public ftp archives:
	ftp.coe.montana.edu:/tmp/ppp-1.2.tar.Z
	agate.berkeley.edu:
		pub/386BSD/386bsd-0.1/unofficial/drivers/net/ppp-1.2.tar.Z
  Comments: 
	"I've made some minor enhancements (very minor) and made it work
	with 386bsd 0.1 (with patchkit 0.1).
	It also runs under SunOS 4.1.x as a modloadable driver." (Brad Parker)

5.1.2 dp-2.3.tar.Z

  Author: Kirk Smith <[email-masked]>,
  	[email-masked], and others
  Features: demand-dial, filtering, header compression, server, scripting,
	   SunOS loadable modules partially supported
  Comment: basically is dp-2.2-beta with a few typos corrected and non-sun4c
           kernel architecture support #ifdef'd in. Tested also on sun3 and
	   sun4m machines.
	   dp-2.3 has a configuration file, which tells where the other
	   configurations files are.
	   Currently works at cs.uni-bonn.de. Loadable modules work fine
           as long as you don't unload them. Survives even talk(1) without
           crashing the machine. If you see older versions, especially
           dp-2.0.tar.Z, toss them immediately!
  Plans:   solaris 2.1 (sunos 5.1) support scheduled for version 3.0. :-)
  Mailing-list: [email-masked].
  Mailing-list-maintainer: Kirk Smith <[email-masked]>
  FTP Archives:
        [email-masked]:pub/ [primary ftp server]
        [email-masked]:pub/ppp/SOFTWARE/DIALUPPPP/ [for Europe]

5.1.3 Perkins/Clements/Fox/Christy PPP for SunOS
  Version: patch level 6 of 1991-10-04
  Anonymous FTP: [not cited to protect the innocent]
  E-mail: [email-masked] (Greg Christy)
  Newsgroups: comp.protocols.ppp
  Supported systems: Sun 4, SunOS 4.1.1
  Comments: should be considered out of date. You need a special patch to
	   fix most of a memory leak, and might have lot of other problems.
	   Successor packages are ppp-1.2 and dp-2.3/dp-3.0.

5.2 free PPP for BSD:
5.2.1.1 ppp-1.2.tar.Z, see 5.1.1

5.3 free PPP for SVR4:

[[email-masked] (Derek Terveer) was] "... contacted by the author of
the PPP for SVR4 package that I was distributing from my
[email-masked] and asked to stop.  This package was an early
beta version that wasn't intended for general consumption. ..."

5.4 FREE PPP FOR MSDOS:

5.4.1 WG7J NOS ppp additions:

  Johan Reinalda (WG7J) did a lot of additions/improvements to the KA9Q for
  MSDOS.  One of them seems to be that PPP is working, finally.  Get
  version 1.08 and up.

  Authors: Phil Karn (KA9Q), Johan Reinalda (WG7J), with additions from
	   lots of others. PPP code written by Katie Stevens of UC Davis,
	   based on the original implementation by Drew Perkins of CMU.
	   Updated by Bill Simpson and Glenn McGregor of the University of
	   Michigan.

  Public FTP site: wg7j.ece.orst.edu:/public/108/ 
	   ucsd.edu:hamradio/packet/tcpip/wg7j/ 
	   idefix.cs.uni-bonn.de:/pub/pppnos.exe [Executable]	

  Comment: see 3.2.3

5.4.2 PPP for NCSA telnet:
  Public ftp archive: merit.edu:pub/ppp/ncsappp.zip
  Comment: [email-masked] (Kim Toms) wrote in comp.protocols.ppp:
	   "I have also been able to use the NCSA telnet packet driver,
	   however, I could not use ftp with that, so I gave it up some months
	   ago."

	   [I, for myself, had no problems with the same packet driver, but
	   see 3.3 for the solution to an interoperability problem. i.s.]

5.5 FREE PPP FOR AmigaOS:

5.5.1 AmigaNOS (KA9Q NOS for Amiga):

  Mailing-list-maintainer: [email-masked]
  Mailing-list: [email-masked]
  Faq-posting: in comp.sys.amiga.datacomm, every 21 days.
  Author: [email-masked] (John Heaton)
  Public ftp archive: ftp.demon.co.uk:
	/pub/amiga/setup/setupv4.lha  419364 bytes (Setup for newcomers;
		Note that this contains some information which is quite
		specific for the demon.co.uk site only)
	/pub/amiga/anos/anos29k.lha  196742 bytes (If you already have an
		earlier version of setup and just need AmigaNOS 2.9k)
	Anos2.9k is also on
		wuarchive.wustl.edu:/mirrors3/ka9q/amiga/anos29k.lha 
  Help-File: 
	wuarchive.wustl.edu:/systems/amiga/incoming/text/AmigaNOS-help-V2.lha
	ftp.demon.co.uk:/pub/amiga/setup/AmigaNOS-help-V2.lha
  Comments: AmigaNOS2.9k.lha contains PPP as well as SLIP. Seems to be a
	    rfc1171 like implementation, enhanced with a few rfc1331/2
	    features (like most other implementations I know of)

5.6 FREE PPP FOR NeXT:
  Public ftp archive: merit.edu:pub/ppp/next-ppp0.2.tar.Z
  Author: [email-masked] (Miron S. Cuperman)
  Comment: The author claimed: "I heard that it doesn't work with 3.0.
	   I haven't looked at it myself.
	   It's just a straight port of ppp-1.1.  It works with NeXTStep
	   2.1.  It is based on the BSD part of ppp-1.1, but with header
	   compression integrated.
           I'm not currently supporting (or even using) it."

           But [email-masked] (Dave Strout via MacPPP and
           Eudora) claims that: "I have gotten the next-ppp0.2 to work just
           fine under NeXTStep 3.0.  I have only tried MacPPP running
           against it, but telnet, eudora, and GopherApp all work fine.
           FTP does not work at 2400bps, but does at 9600.
	   dave."

5.7 free PPP for Macintosh:
- MacPPP 1.0 beta from Merit Network, Inc.
  author: [email-masked] (Larry Blunk)
  Public ftp archive: merit.edu:pub/ppp/macppp1.0.sit.hqx
  Status: This is the final release of MacPPP 1.0, a LAP (mdev) driver for
	  MacTCP. The current version does not support Appletalk over PPP.
	  The driver requires System 6.0.5 or higher. (Note: the PPP LAP
	  requires MacTCP 1.1 or higher.  MacTCP 1.1 and 1.1.1 both have
	  problems with slow links.  In particular, they do not adapt the
	  timeouts on retrys and resets very well for slow data rates.
	  This causes problems when using large windows on a TCP session.
	  Most notably, you may experience problems when using Xferit.
	  Fetch and the NCSA Telnet 2.5 FTP client/server seem to work okay.) 


6. ftp sites for general PPP stuff, docs etc.

try also the ftp sites mentioned above in the 'packages' section.

- Merit PPP collection at merit.edu:/pub/ppp/

- Ohio PPP collection at archive.cis.ohio-state.edu:/pub/ppp/

- KA9Q NOS collection at ucsd.edu:...

- in Europe, try theory.cs.uni-bonn.de:pub/ppp for a very selected
  collection.

7. Commercial PPP software packages.

7.1 Amiga Inet:

A version, which will support SLIP (but, alas, not PPP), is expected to
be distributed with AmigaOS 3.1 in spring 93

7.2 MSDOS with and without MSWindows

7.2.1 Commercial PPP packages for MS-DOS and MS-Windows

  This information orignally appeared in the December 7th, 1992 issue
of "Open Systems Today", a newspaper published by CMP Publications,
(516) 562-5882. 

  Each of these packages costs around $400 not including volume or other
discounts. Call the vendor for details.

  Each of the packages is a complete TCP/IP stack with assorted client
programs, ftp, telnet, etc.., that run under MS-DOS and/or MS-Windows. 
The TCP/IP client programs included in each package vary. Some use the 
DOS command line (even under MS-Windows) while others have full Windows 
GUI interfaces.  A PPP client (but not server) is included with each of 
these packages.

7.2.1.1.  LAN WorkPlace for DOS 4.1 beta (see also 7.2.2)
    Novell
    USA: (801) 429-5588

  Summary: This is an MS-DOS TSR (Terminate and Stay Ready) solution so it 
  runs under either MS-DOS or MS-Windows. It includes a program called
  "DIALUP" that only allows connections at 8 bits, no parity. You can use
  the public domain "kermit" program instead if you need 7 bits, parity 
  connections.

7.2.1.2.  PC/TCP 
    FTP Software
    USA: (508) 685-4000
    Contact: [email-masked]

  Summary: PC/TCP is an MS-DOS TSR solution that had PPP long before it
  was fashionable. Not surprisingly, it was the only non-beta product 
  available for this review.

  Comment: PC/TCP 2.2 was shipped 24/25 March 1993 (information indirectly
     through one of their customers.) I copy parts of the feature list:

    1. Autoinstall/Autoconfig (graphical interface, easy install)
    2. PCTCPNET (mount InterDrives from File Manager)
    3. PCNFSD Print Support (multiple print redirection through PCNFSD)
    4. Router Discovery - RFC 1256
    5. 8K UDP Writes
    6. WMSG (Demonstrates IP Multicast)
    7. NFS/TCP Support
    8. International Character Set Support / Names in InterDrive
    9. International Character Set Support / Directory in InterDrive
    10. MVSLogin Support for InterDrive
    11. TN Mouse and light pen Support
    12. VI Compression for both SLIP and PPP
    13. WinSockAPI Meets Final Revision
    14. Interdrive EMM Caching Support - use EMM for buffers
    15. Inet - Serial line additions debug SLIP and PPP connections
    16. Kerberos/Ktelnet
    17. Kernel/Netbios Interactions imporved support for LANtastic, LAN MAN

7.2.1.3.  Distinct TCP/IP 3.0 beta
    Distinct Inc.
    USA: (408) 741- 0781

  Summmary: This is a Windows DLL solution so it only runs under MS-Windows.
  Nice scripting features and built-in support (stored configuration 
  strings, basically) for various modems. 

7.2.1.4.  Super-PPP for Windows 1.0 beta
    Frontier Technologies Corp
    USA: (414) 241-4555

  Summary: This is a Windows DLL solution that is an optional component of
  their Super-TCP for Windows product. Super-TCP comes in both TSR and
  DLL flavors but the Super-PPP product is strictly DLL. Very configurable.

  Performance notes: If you run PPP under MS-Windows, your performance will
  suck (it might not work at all!) unless you have 16550A UARTs in your PC. 
  If you have an extra card slot, you can add two 16550A ports with the
  DSP 550 card from STB Systems, (214) 234-8750. To find out what kind
  of UARTs are in your PC, use the program "msd.exe" in your MS-Windows 3.1
  install directory or retrieve the program 
  /published/open-systems-today/uarttype.zip from ftp.uu.net . 
  Older UARTs are the 8250 or the 16450.  These UARTs will work ok under
  MS-DOS. A fast CPU helps, though. No performance tests were run because
  three of the four packages above are still in beta. 

  For more information, read the Open Systems Today article and stay 
  tuned to this FAQ.

7.2.2 MSDOS/Novell:

    Novell now offers PPP support (asynchronous) in LAN WorkPlace for DOS
    version 4.1, and PPP support for synchronous and T1 connections on 
    NetWare v3.11 servers in the MultiProtocol Router WAN Links option.  
    NetWare server support for the routing of IP and IPX protocols over 
    asynchronous dialup lines will be available sometime around mid-1993.

    This is an excerpt from LWP41.TXT, a document describing LAN
    WorkPlace for DOS v4.1 (the entire text can be found on
    sjf-lwp.sjf.novell.com in ~/lwp4dos/lwp41.txt):

       *  SLIP (Serial Line Internet Protocol) and PPP (Point to Point
          Protocol) support.  SLIP and PPP support is provided in the form
          of a custom ODI driver for LAN WorkPlace: SLIP_PPP.COM.  This
          driver allows the Novell TCP/IP Transport for DOS v4.1 to use
          asynchronous connections for IP services required by DOS and
          Windows applications.  It supports the following:
           -  SLIP
           -  Compressed SLIP (C-SLIP) using Van Jacobson TCP/IP header
              compression (as described in RFC-1144).
           -  PPP with support for Van Jacobson TCP/IP header compression
              option negotiation and PAP (Password Authentication
              Protocol) as described in RFC-1334.
           -  Support for National Semiconductor's 16550, 16550A, 16450
              and 8250 UARTs (Universal Asynchronous Receiver
              Transmitter).  Use of a 16550 UART is strongly recommended
              (and is required for use with Windows at speeds of 9600bps
              or greater).  NOTE: One can use the Microsoft Diagnostics
              program supplied with Windows v3.1 (MSD.EXE) to determine
              which type of UART is installed in a PC.
           -  Interface speeds up to 57,600 bps when used with a
              V.32bis/V.42bis modem and 16550A UART.

	[email-masked] (Brian Meek) clarified on my request, that:

	IP is the only protocol supported directly by the LAN
    WorkPlace SLIP_PPP driver in this initial release.  One can use
    the IPTUNNEL LAN driver (also included in LAN WorkPlace) to
    encapsulate IPX in UDP/IP and attach to a NetWare v3.11 server
    running a similar driver.  This "IP Tunneling" mechanism is
    described in RFC 1234.

	Direct IPX support for this PPP driver will be added later,
    but the current tunneling mechanism is presently more widely
    applicable... since few (if any) PPP implementations are presently
    available with support for IPX.

7.3 386/486 PC's with SCO Unix:

7.3.1 SCO Unix ODt2.0 and later for 386/486 PC's contains PPP.
7.3.2 Morning Star PPP runs under SCO UNIX and ODT (see 7.4)

7.4 for lots of computers running some Unix derivate:

- Morning Star PPP
  Price: $795 (40% discount for .edu)
  Supported systems: Sun 4, Sun 3, NeXT, DECstation, RS/6000, SCO UNIX, ISC
	UNIX, and Silicon Graphics 

  Features: demand-dial, scripting, filtering, redial, header compression,
	client, server, tunneling, extra escaping, the ability to work with
	various keycard access systems that require user interaction during
	the script 
  
	Morning Star claims that their async PPP and SLIP run fine over
	UNIX systems' native serial ports, with no additional hardware
	required.  For better performance, they recommend that users of
	PC-based UNIX systems install either a serial interface card based
	on the NS16550AFN UART, or a multiport "smart" card. They claim to
	do async PPP and SLIP/CSLIP as fast as the underlying UNIX supports
	(usually 38400), and to do sync PPP up to T1 (1.544Mb/s) or E1
	(Euro-T1, 2.048Mb/s) over their SnapLink. They provide
	dynamically-loadable modules for SunOS 4.1.* and NeXTStep 2.1 and
	3.0, so users needn't even reboot during the installation process.

  FTP: ftp.morningstar.com
       ftp.uu.net:/vendors/MorningStar/
  E-mail: [email-masked]

7.5 for SUN computers running SunOS

7.5.1 Morning Star PPP. see 7.4

7.5.2 Brixton PPP
  Supported systems: Sun 4
  Features: demand-dial

7.5.3 SUNlink PPP 1.0
  was announced in SunFLASH Vol 49 # 1 (January 1993)
  Requires: SPARC(R) system running Solaris(R) 1.x operating environment
            and either SunLink HSI/S or SunLink MCP. 
  Features: supports only synchronous up to 2MB/s lines, load-sharing,
            dynamic routing. Only the obsolete RFC1171/2 standard, but
            should interoperate with newer implementations.
  Price:    $1,225 (media, doc, and RTU) [in the USA only]
  Comment:  for a needed patch see 3.8.

7.6 for NeXT
7.6.1 Morning Star PPP see 7.4


8. PPP hardware.

8.1 Hardware that does async PPP
~From: [email-masked] (Edward Vielmetti)
~Newsgroups: comp.protocols.ppp

This is a list of hardware that supports async PPP, in the form
of a terminal server or terminal server / router combination.

- Telebit Netblazer
  ftp information from ftp.telebit.com
  N2-1-ES	1 ethernet + 1 56K +  2 RS-232
  N10-1-ES	1 ethernet + 1 56K + 10 RS-232

- Livingston Portmaster PM-11
  ftp information from gator.netcom.com:/pub/livingston/

8.2 Hardware that supports sync PPP
~Newsgroups: comp.protocols.ppp
~From: [email-masked] (Edward Vielmetti)

Note that sync PPP is rather well established and it's not surprising
to see lots of vendors using it as their only sync serial line
protocol.  Various folks do various of the configuration options,
anywhere from a full implementation to very bare bones.

The price point is arbitrary.  These are list prices for the cheapest
box that has at least 1 sync PPP port that runs at 56 kb/sec plus one
ethernet.  Prices approximate, your milage may vary, contact your
vendor for details.

- Cisco
  E-mail: [email-masked]

- Telebit Netblazer
  Phone: +1 800 TELEBIT
  E-mail: [email-masked]
  N2-1-ES	1 ethernet + 1 56K +  2 RS-232
  N10-1-ES	1 ethernet + 1 56K + 10 RS-232

- Livingston
  E-Mail: [email-masked]
  IR-4		1 ethernet + 4 56K +  1 RS-232

- Morning Star SNAPlink
  E-Mail: [email-masked]
  SnapLink	SCSI-attached serial interface for Unix systems
		1 T1 + 2 56K, RS-232 or RS-449
  HDLC driver for sun4c ttya and ttyb included with PPP software. Works
  only with SunOS <= 4.0.3c. Morning Star "haven't been able to extract the
  information from Sun that we need to make it work under SunOS 4.1.* or
  Solaris 2.*. 

  The HDLC driver works on NeXTs under NeXTStep 2.[12], but because of
  NeXTStep's interrupt structure, we can only get it up to 19200 sync.

  It's also available from ftp.morningstar.com:pub/tools/sun-hdlc.tar.Z.
  It started as something from one of Torben Nielsen <[email-masked]>'s
  grad students, and we're required to pass along any changes we make to
  it.  We hope that if someone gets it working under 4.1.*, they'll be nice
  enough to pass their changes along too."

8.3 Recent summaries stuff from the net, will be merged with the rest later

~From: [email-masked] (Peter Galbavy)
~Newsgroups: comp.protocols.ppp
~Subject: [SUMMARY]: PPP Capable Terminal Servers (Interim)
~Date: 27 Nov 92 12:13:35 GMT
Organization: MicroMuse Limited, London, England.

I got lots of very helpful replies to my request for terminal servers
that are capable of PPP. [...]

Xylogics MicroAnnex XL		(8-16 ports - release 7.0 firmware)
Xylogics Annex 3		(8-64 ports - release 7.0 firmware)
Livingston Portmaster		( ??? )
3com CS/2100			(10 lines max)
Datability VCP 200/300		( ??? )
Telebit NetBlazer		( limited... I don't think of this a a TS )

The number I got were:

Xylogics US: +1 617 272 8140 <[email-masked]>
Xylogics UK: +44 908 222112 <[email-masked]>
Livingston Enterprises, Inc: +1 510 426 0770

The most suggestions were for Xylogics. I have not got any further info yet.
I will let you all know if you want later...

~Newsgroups: comp.protocols.ppp
~From: [email-masked] (Brian J. Smith)
~Subject: Re: [SUMMARY]: PPP Capable Terminal Servers (Interim)
~Date: Fri, 27 Nov 92 23:35:18 GMT

In article <peter.722866415@hilly> [email-masked] (Peter
Galbavy) writes:

>Xylogics Annex 3		(8-64 ports - release 7.0 firmware)

I have been *VERY* happy with my Xylogics terminal servers I have to Annex II's
and a Annex 3.  They were designed for the Unix type person, and take 2 mins to
get working on the network.  Port configuration will take longer, but normally
you only have a few sets of configurations "modem dialin high speed" etc.  
Two thumbs up to this company, now if they didn't cost so much. :) :)

>Datability VCP 200/300		( ??? )

I tested one of these, they come in 8-16 port configurations, a TCP or LAT or
TCP/LAT version.  Very VMS like, I would guess a off spring of DECservers.  
Cheaper than the Xylogics in Price.  Didn't fit my feel due to the VMSish
help and commands.

>Telebit NetBlazer		( limited... I don't think of this a a TS )

A NetBlazer works flawlessly for remote site PPP/SLIP links.  As a term server
it doesn't fit the bill.  And a bit costly.

~Newsgroups: comp.protocols.ppp
~From: [email-masked] (Samuel Lam)
~Subject: Re: [SUMMARY]: PPP Capable Terminal Servers (Interim)
~Reply-To: [email-masked] (Samuel Lam)
~Date: Sun, 29 Nov 1992 07:21:07 GMT

In article <peter.722866415@hilly>, [email-masked] (Peter Galbavy) wrote:
>Livingston Portmaster		( ??? )

They have 10-, 20- and 30-port configurations.  List prices
ranging from ~US$2.7K to ~US$3.8K.  Contact <[email-masked]>
for more information.

9. Acknowledgements:

Thanks for their contributions to:

Edward Vielmetti <[email-masked]> (for the first Version, called 0.1)
Bob Sutterfield <[email-masked]> (lots of contributions, not only
	about Morningstar PPP)

[email-masked] (RFC descriptions)
Helmut Heller <[email-masked]> (more NeXT information)
[email-masked] (Peter Galbavy) (for a PPP terminal server summary)
[email-masked] () (for contributing to a PPP term. server summary)

[email-masked] (Michael Davis) (for Abbreviations)
Dan Pritts ([email-masked]) (for MacPPP information)
[email-masked] (Brian Meek) (for much Information about Novell PPP)
[email-masked] (Jason Martin Levitt) (for reviewing an
	Open Systems Today review about tcp/ip with ppp packages for 
	MSDOS/MSWINDOWS)
[email-masked] (Guy K Hillyer) (for his solution to his problem of
	interoperation between free ppp for SunOS and MacPPP 1.0beta.)
[email-masked] (Daniel H. Lannom) (for information about
	AmigaNOS2.9k)
[email-masked] (Richard Akerman) (for his amiganos+ppp help file)

Local Variables:
mode: text
fill-column: 75
eval: (auto-fill-mode 1)
End:
-- 
-- 
	Ignatios Souvatzis
	[email-masked] [email-masked]
Cute quote: "You should also consider that the ST comes fully equipped with a 
             text adventure. It's called ST Basic." [email-masked]