Path: news1.ucsd.edu!ihnp4.ucsd.edu!agate!usenet.kornet.nm.kr!news.postech.ac.kr!news.kigam.re.kr!usenet.seri.re.kr!news.cais.net!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!ignatios
From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
Newsgroups: comp.protocols.ppp,news.answers,comp.answers
Subject: comp.protocols.ppp part1 of 8 of frequently wanted information
Supersedes: <ppp-faq/part1_835122009@cs.uni-bonn.de>
Followup-To: poster
Date: 2 Jul 1996 18:20:07 GMT
Organization: computer science department, university of Bonn, Germany
Lines: 132
Approved: news-answers-request@MIT.Edu
Expires: 30 Jul 1996 18:20:07 GMT
Message-ID: <ppp-faq/part1_836331607@cs.uni-bonn.de>
NNTP-Posting-Host: theory.cs.uni-bonn.de
Summary: This document contains information about the Internet Point-to-Point
Protocol, including a bibliography, a list of public domain and
commercial software and hardware implementations, a section on
configuration hints and a list of frequently asked questions and
answers on them.
It should be read by anybody interested in connecting to Internet
via serial lines, and by anybody wanting to post to
comp.protocols.ppp (before he/she does it!)
Xref: news1.ucsd.edu comp.protocols.ppp:13634 news.answers:62095 comp.answers:15565
Archive-name: ppp-faq/part1
Version: $Revision: 3.20 $
Last-modified: $Date: 1995/09/11 20:10:06 $
URL: http://cs.uni-bonn.de/ppp/part1.html
PPP FWI Letter from the editor
1. LETTER FROM THE EDITOR
Important Changes
Introduction
Information wanted
CD-ROM policy
DISCLAIMER
1.0 Important Changes
1995-JULY
Started to implement explicit CD-ROM policy.
Updated once again part about NeXT PPP.
Updated some commercial products from my email backlog.
OLDER CHANGES
none.
VERY OLD CHANGES
Updated part about SVR4 ppp (5.3.1).
(5.6.3) added blurb about ISPA, a msdos computer "packet driver" which
- among other de facto used protocols - also supports PPP over ISDN,
hopefully as of the RFC.
few days or weeks ago added some vendors of PPP soft- and hardware in
part7/part8. I want to express, that that list, as any other information
in this postings/document, can't contain all products available, as I
can't possibly read all publications/advertisements all over the world
and put them in; I only include what people tell me or I stumble about.
See the disclaimer.
switched to another PPP relevant RFC search machine. It is still
situated in Europe (this time in Germany), so ppl. shouldn't use it at
regular intervals if from abroad.
1.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
document. Later, lots of people contributed at one or the other place.
This document will be reposted fortnightly, as soon as it is fairly
stable, and weekly till then. Changed sections should be marked in the
Table of Contents with a ! or + for something got added or - for
something got deleted.
1.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.
The last paragraph applies explicitly to the authors themselves! Keep me
informed, please. If you send me complete entries, consider to get the
HTML version from http://theory.cs.uni-bonn.de/ppp/part?.html and send
me an edited version.
CD-ROM policy
This sample of documents was collected by me from the various sources,
including the Usenet news and direct contributions from others. I
started with it before the outbreak of the CD ROM plague, so the special
issue of ppl. collecting machine readable data, storing them to master
disks and selling copies thereof never occured.
Personally, I think that pressing higly dynamic data collections (like
FAQ lists) to write-once media is a very stupid thing to do. However,
there might be reasons to include the PPP-FAQ with other data; e.g.,
when preparing a NetBSD distribution on CD-ROM, an off-line readable
copy of the PPP FAQ might be helpful for those wanting to set up a PPP
connection from their newly aquired NetBSD for the first time... how
could they access the online copy without having a working PPP
connection?
In the last few years I got lots of requests to allow the PPP FAQ to be
added to such CD-ROMs. As I never had asked for such permissions from
the contributors, I was not able to say "yes", even if I would have
given the permission for my own work.
If you contribute s.th., please state clearly if you would allow
inclusion of the information to CD-ROM collections.
At the moment, I can't give the permission to copy this stuff to CD-ROMs
which are sold afterwards, even if I would like to, for the stated
reasons.
DISCLAIMER
I want to express that any information in this posting or its follow-ups
is provided on an "AS-IS" basis as a service to my colleagues at other
Universities, without any implied or explicit warranties.
To be more precise:
I don't promise that all freely available programs are contained, or
that programs described here are (still) available, or ar suited for
anything useful better or worse than others. If you wan't me to
include s.th., tell me about it; but I don't promise that I'll
include it the same day or week or at all.
I don't promise that commercial products contained here exist, that
all commercial products in existance are contained here, or that
products contained here are suited for anything useful better or
worse than others. If any vendors feel their product should be
included, and tells me about it, I probably would do it; but I don't
promise that I'll include it the same day or week or at all.
After all, doing this FAQ isn't my primary duty at work.
Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
--
--
----------------------------------------------------------------------
Path: news1.ucsd.edu!ihnp4.ucsd.edu!agate!usenet.kornet.nm.kr!news.postech.ac.kr!news.kigam.re.kr!usenet.seri.re.kr!news.cais.net!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!ignatios
From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
Newsgroups: comp.protocols.ppp,news.answers,comp.answers
Subject: comp.protocols.ppp part2 of 8 of frequently wanted information
Supersedes: <ppp-faq/part2_835122009@cs.uni-bonn.de>
Followup-To: poster
Date: 2 Jul 1996 18:20:08 GMT
Organization: computer science department, university of Bonn, Germany
Lines: 253
Approved: news-answers-request@MIT.Edu
Expires: 30 Jul 1996 18:20:07 GMT
Message-ID: <ppp-faq/part2_836331607@cs.uni-bonn.de>
NNTP-Posting-Host: theory.cs.uni-bonn.de
Summary: This document contains information about the Internet Point-to-Point
Protocol, including a bibliography, a list of public domain and
commercial software and hardware implementations, a section on
configuration hints and a list of frequently asked questions and
answers on them.
It should be read by anybody interested in connecting to Internet
via serial lines, and by anybody wanting to post to
comp.protocols.ppp (before he/she does it!)
Xref: news1.ucsd.edu comp.protocols.ppp:13635 news.answers:62096 comp.answers:15566
Archive-name: ppp-faq/part2
Version: $Revision: 3.15 $
Last-modified: $Date: 1994/11/28 20:10:10 $
URL: http://cs.uni-bonn.de/ppp/part2.html
What is PPP?
2. WHAT IS PPP?
Introduction
PPP features which may or may not be present
PPP glossary
PPP-relevant RFC's
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. Please note also that not every free
or commercial product description in this document has a complete list
of all features includes.
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. (sometimes called camping)
camping (on a line) see redial
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.
(In process of getting standardized.)
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 RFC1144.
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
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 RFC1331)
C Close [state diagram]
CHAP Challenge-Handshake Authentication Protocol
(RFC1334)
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 (RFC1334)
PDU Protocol Data Unit (i.e., packet)
PO Passive open [no longer part of state diagram]
PPP Point to Point Protocol (
RFC1548 /
RFC1549,
1332,
1333,
1334,
1551,
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 (RFC1144 header compression algorithm)
XNS Xerox Network Services
2.4 PPP relevant RFCs
Here's a list with descriptions. Note some of these are obsolete. You
might also want to search for recent RFCs or internet drafts in an
up-to-date RFC archive.
1717 Sklower, K.; Lloyd, B.; McGregor, G.; Carr, DThe
PPP Multilink Protocol (MP). 1994 November; 21 p.
(Format: TXT=46264 bytes)
1663 Rand, DPPP Reliable Transmission. 1994 July; 8 p.
(Format: TXT=17281 bytes)
1662 Simpson, W.,edPPP in HDLC-like Framing. 1994 July;
25 p. (Format: TXT=48058 bytes) (Obsoletes RFC
1549)
1661 Simpson, W.,edThe Point-to-Point Protocol (PPP).
1994 July; 52 p. (Format: TXT=103026 bytes)
(Obsoletes RFC 1548)
1638 Baker, F.; Bowen, R.,edsPPP Bridging Control
Protocol (BCP). 1994 June; 28 p. (Format:
TXT=58477 bytes)
1619 Simpson, WPPP over SONET/SDH. 1994 May; 4 p.
(Format: TXT=8893 bytes)
1618 Simpson, WPPP over ISDN. 1994 May; 6 p. (Format:
TXT=14896 bytes)
1598 Simpson, WPPP in X.25. 1994 March; 7 p. (Format:
TXT=13835 bytes)
1570 Simpson, W.,ed. PPP LCP Extensions. 1994 January;
18 p. (Format: TXT=35719 bytes) (Updates RFC 1548)
1553 Mathur, S.; Lewis, M. Compressing IPX Headers Over
WAN Media (CIPX). 1993 December; 23 p. (Format:
TXT=47450 bytes)
1552 Simpson, W. The PPP Internetwork Packet Exchange
Control Protocol (IPXCP). 1993 December; 14 p.
(Format: TXT=29174 bytes)
1551 Allen, M. Novell IPX Over Various WAN Media
(IPXWAN). 1993 December; 22 p. (Format: TXT=54210
bytes) (Obsoletes RFC 1362)
1549 Simpson, W.,ed. PPP in HDLC Framing. 1993
December; 18 p. (Format: TXT=36353 bytes)
(Obsoleted by RFC 1662)
1548 Simpson, W. The Point-to-Point Protocol (PPP).
1993 December; 53 p. (Format: TXT=111638 bytes)
(Obsoletes RFC 1331; Obsoleted by RFC 1661; Updated
by RFC 1570)
1547 Perkins, D. Requirements for an Internet Standard
Point-to-Point Protocol. 1993 December; 21 p.
(Format: TXT=49811 bytes)
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 RFC1172)
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 RFC1171, RFC1172;
obsoleted by RFC 1548)
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
RFC1331, RFC1332)
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 RFC1134; Obsoleted by RFC1331)
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
RFC1171)
1144 Compressing TCP/IP headers for low-speed serial
links. Jacobson, V. 1990 February; 43 p.
(Format: TXT=120959 PS=534729 bytes)
In comp.protocols.ppp (Message-ID:
<BOB.92Dec3145948@volitans.MorningStar.Com>)
bob@MorningStar.Com (Bob Sutterfield)
wrote :
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.)
--
--
----------------------------------------------------------------------
Path: news1.ucsd.edu!ihnp4.ucsd.edu!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!Germany.EU.net!howland.reston.ans.net!gatech!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!ignatios
From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
Newsgroups: comp.protocols.ppp,news.answers,comp.answers
Subject: comp.protocols.ppp part3 of 8 of frequently wanted information
Supersedes: <ppp-faq/part3_835122009@cs.uni-bonn.de>
Followup-To: poster
Date: 2 Jul 1996 18:20:09 GMT
Organization: computer science department, university of Bonn, Germany
Lines: 433
Approved: news-answers-request@MIT.Edu
Expires: 30 Jul 1996 18:20:07 GMT
Message-ID: <ppp-faq/part3_836331607@cs.uni-bonn.de>
NNTP-Posting-Host: theory.cs.uni-bonn.de
Summary: This document contains information about the Internet Point-to-Point
Protocol, including a bibliography, a list of public domain and
commercial software and hardware implementations, a section on
configuration hints and a list of frequently asked questions and
answers on them.
It should be read by anybody interested in connecting to Internet
via serial lines, and by anybody wanting to post to
comp.protocols.ppp (before he/she does it!)
Xref: news1.ucsd.edu comp.protocols.ppp:13636 news.answers:62097 comp.answers:15567
Archive-name: ppp-faq/part3
Version: $Revision: 3.10 $
Last-modified: $Date: 1995/11/13 20:10:17 $
URL: http://cs.uni-bonn.de/ppp/part3.html
PPP configuration recipes
3. HOW TO (CONFIGURATION RECIPES)
complain about missing or incorrect information in the FAQ list
connect a single host to a network without needing a new subnet.
configure free ppp for sun to interoperate with MacPPP 1.0
get SCO TCP 1.2 to connect to Ethernet LANs by a PPP link
use PPP through a X.25 PAD
use SunLINK PPP 1.0 to a CISCO
through a sync line
use MacPPP 2.0.1 on non-US
System 6 MACs
stop MacPPP to dial without being told to
3.0 complain about missing or incorrect information in the FAQ list
E-mail to
ignatios@theory.cs.uni-bonn.de (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.
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 at our site.
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.
ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
3.2 configure KA9Q PPP and it's Unix counterpart
Newsgroups: comp.protocols.ppp
From: kim@MorningStar.Com (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
deleted, becausy to my knowledge, there is no KA9Q with new dialer and
working PPP.
3.2.3 CONFIGURE JNOS
I have jnos1.08 up and running. [that is, 'version 911229 (WG7J
v1.08)']. For a sample configuration, get the configuration and
executable you can ftp from speckled.mpifr-bonn.mpg.de, user ftp,
directory /pub/rhein.de or /pub/incoming. The remarks in 3.3 about
'vjmode draft' or 'vjmode 1331' apply here, too.
ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
3.3 configure NCSA with the merit ppp packet driver and its unix
counterpart
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 (and up) 'vjmode rfc1331'.
ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
3.4 work BOOTP over protocols such as SLIP or PPP
Newsgroups: comp.protocols.ppp
From: johnson@tigger.jvnc.net (Steven L. Johnson)
Subject: Re: Tech?: BOOTP over SLIP or PPP
Date: Wed, 2 Dec 1992 03:14:37 GMT
[Somebody on the net] 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: guy@world.std.com (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 do
wn
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: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: PPP on SCO between different networks
In some news message, somebody asked:
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: unrza3@cd4680fs.rrze.uni-erlangen.de (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
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 <amellan@acri.fr>
3.9 use MacPPP 2.0.1 on non-US System 6 Macintoshes
The current MacPPP Version (2.0.1) works on System 6 only if the system
folder is called "System Folder". On non-US systems (e.g. German
systems, where it is called "Systemordner"), MacPPP doesn't find some
file it needs. On System 7 Macs this problem isn't there.
The workaround is, to rename the system folder to "System Folder". Other
programs will ask the system, how the system folder is named, and
continue to work.
Thanks to hn277pk@unidui.uni-duisburg.de (Peter Koch) for summarizing
this information to me, who never used a Macintosh (with the exception