ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/ppp-faq/part3

Text File | 1996-10-09 | 19KB | 459 lines

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news-peer.gsl.net!news.gsl.net!howland.erols.net!news.sprintlink.net!news-peer.sprintlink.net!uunet!in1.uu.net!fu-berlin.de!uniol!news.uni-stuttgart.de!news.ruhr-uni-bochum.de!news.rhrz.uni-bonn.de!ignatios
From: [e-mail] (Ignatios Souvatzis)
Newsgroups: comp.protocols.ppp,news.answers,comp.answers
Subject: comp.protocols.ppp part3 of 8 of frequently wanted information
Supersedes: <ppp-faq/[e-mail]>
Followup-To: poster
Date: 8 Oct 1996 19:18:17 GMT
Organization: computer science department, university of Bonn, Germany
Lines: 435
Approved: [e-mail]
Expires: 5 Nov 1996 19:20:02 GMT
Message-ID: <ppp-faq/[e-mail]>
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: senator-bedfellow.mit.edu comp.protocols.ppp:17580 news.answers:83879 comp.answers:21647

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

                        [e-mail] (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.

                               [e-mail] (Ignatios Souvatzis)

3.2 configure KA9Q PPP and it's Unix counterpart


Newsgroups: comp.protocols.ppp
From: [e-mail] (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.

                               [e-mail] (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'.

                               [e-mail] (Ignatios Souvatzis)

3.4 work BOOTP over protocols such as SLIP or PPP


Newsgroups: comp.protocols.ppp
From: [e-mail] (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: [e-mail] (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: [e-mail] (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: [e-mail] (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 <[e-mail]>

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 [e-mail] (Peter Koch) for summarizing
   this information to me, who never used a Macintosh (with the exception
   of playing Shufflepack CafΘ once).

3.10 stop MacPPP to automagically dial without being asked to

   In article <x@y>, somebody@somewhere wrote:


> MacPPP is launching when I boot up my Mac. I've checked the 'Startup
> items' folder and it's not in there.  Does anyone know why?

   A couple of things to check for are 1) some of the snmp agents will
   cause macppp (at least older versions) to try and dial up the selected
   server - the solution is to disable the snmp manager extension. 2) you
   might have network time selected to set the clock at boot up - turn off
   this option and instead set it for once an hour or something like that.

                                       [e-mail] (David Comay)

   Anything that opens the IP driver will cause MacPPP to dial up it's
   target. Particularly you will see this problem with ZapTCP. It will open
   the IP driver at boot time, as well as everytime a program quits.

                                          Tom Kimpton <[e-mail]>


--
--
--
Unsolicited junk e-mail will be proofread at US$50.- per page. By sending
such e-mail to my address, you accept these terms.