On the gateway do:
arp -s othermachinesipaddress myownethernetaddress permanent public ifconfig pppNUMBER myipaddress othermachinesipaddress [other params] upon remote machine:
ifconfig pppNUMBER gatewaysipaddress [other params] up route add default gatewaysipaddress 1pppNUMBER 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)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 GMTI 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.netIn 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 ttylinkIn 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"
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
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 GMTAfter 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 downThen 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 networksIn 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:
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>
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 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. dsc@cac.washington.edu (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 <tom@dtint.dtint.com>