$ wjm 12-nov-1996:	PPP for CMU-IP V0.1$ wjm 25-nov-1996:	PPP for CMU-IP V0.2  4 	This is a rather crude & unpolished set of programs2 	that allow my home VAX (which runs CMU-IP 6.6-5A)2 	to communicate via IP over PPP, tested with a few0 	PPP partners that happen to be available to me.1 	(NOTE: this started as a "long weekend" project, . 	 based on nothing but the RFCs. I've seen the1 	 featureful UNIX `pppd' since, and warn everyone / 	 that I neither intend to port `pppd' to VMS,  - 	 nor to re-create all of its functionality).   0 	Some pieces of the code (MBDRV, VJ compression)0 	are based on Don Stokes' CSDRV kit; the rest is 	all home-grown.  0 	Most of the required code is there, but as yet . 	there's no configurability at all (except by + 	modifying the source), nor any "tools" for 4 	managing it. Nonetheless, it's hoped to be generic 3 	enough that some people (assumed to be experienced 4 	with using CSDRV and/or SLDRV) could have a try ...   	Things implemented:. 	- IP with Van Jacobson TCP header compression- 	- PAP authorisation ("client" function only)    	Restrictions:3 	- out of the PPP authorization protocols, only PAP / 	  (the most primitive) is provided (I have no  / 	  PPP "server" available that could use more). 0 	  Other fancy PPP stuff, like data compression, 	  isn't provided either.   5 	- PPP often does dynamic assignment of IP addresses; 9 	  there's no "technology" yet to tell CMU-IP the outcome : 	  except by re-starting the IPACP with an INTERNET.CONFIG< 	  created on the fly (just the same as with SLDRV & CSDRV).  4 	- as it stands, V0.2 will not accept a partner that7 	  during negotiation insists on receiving PPP packets  5 	  shorter than the default length of 1500 (I have no 9 	  idea if CMU-IP even knows about shorter IP fragments). 9 	  Maybe it shouldn't take the request seriously, the RFC  	  seems to allow for this.   : 	- operation of multiple PPP lines ought to work, but onlyC           in principle (by playing logical name tricks, or patching 7 	  the source to use different mailbox names per line).   5 	- [likely some more that I'm not aware of right now]     
 Installation: = 	SET DEFAULT to the directory where you've unpacked PPP02.ZIP   , 	Create MBDRV.EXE (takes nothing but MACRO): 		$ @MAKE_MBDRV   ? 	Copy MBDRV.EXE to CMUIP_ROOT:[SYSLIB] (that's where SLDVR.EXE  , 		and maybe CSDRV.EXE are to be found, too).   	Create PPP.EXE : ( 		Depending on the C compiler available,  * 		$ @MAKE		! with GNU CC V2.7 [used by me]6 		$ @MAKE VAXC	! with VAXC V3.2 [quite likely to work]$ 		$ @MAKE DECCV4	!! ... not sure ...$ 		$ @MAKE DECCV5	!! ... not sure ...  B 	Make sure the (dynamic) SYSGEN parameter MAXBUF is at least 3013,? 	and while you're at it, set TTY_ALTYPAHD to a reasonably large ; 	value, like 1000..2000 (maybe that's not really required).   ! Usage ("client" connection test): < 	PPP.EXE runs in a process separate from IPACP. This process< 	also has to take care of establishing the connection to theB 	PPP "server", so at first it sure ought to be an interactive one.  # 	Acquire SYSPRV & PRMMBX privilege.  	 < 	Get hold of some [outgoing] TTY port (LAT ought to be fine,@ 	others will work provided they're transparent to all characters8 	except XON & XOFF). Better enable ALTYPAHD on that line/ 	(can be done only via SET TERMINAL/PERMANENT).   ; 	Allocate the TTY port, by a logical name of "TTY", and set @ 	terminal characteristics (TTY3.COM is an example for my Vs3100,. 	use /[no]TTSYNC/[no]HOSTSYNC as appropriate).  9 	Somehow establish connection to the PPP "server" via the 0 	TTY line (using KERMIT or SET HOST/DTE or ...).? 	In my experience, once you have successfully connected to PPP, ? 	the server will start outputting PPP data (starting with "~"). < 	Quickly escape out of KERMIT or whatever, and RUN PPP.EXE .  B 	Magic messages will be output, indicating that a PPP negotiation > 	is going on. If all is well (no gurarantees!), 	PPP.EXE will  	finally output a line like   7 	"===== ready to start IP - lcl= n.n.n.n  rem= n.n.n.n"   : 	indicating that an IP connection with the addresses shown9 	(lcl = your system, rem = the "server" you connected to) 7 	is waiting to be established. Usually the PPP "server" ; 	will dictate these (PPP.EXE happily accepting anything but < 	all zeroes), otherwise PPP.EXE provides hard-coded defaultsA 	of 192.168.2.45 for itself, and 192.168.2.145 for the remote end 9 	(in case it's just a PC, or so). Don't hesitate to kill  8 	PPP.EXE if you don't like the outcome (and don't forget( 	to hang up the modem by some means :-).  9 	Anything may happen if the negotation fails, but usually < 	PPP.EXE will exit cleanly. Given a screenfull of PPP.EXE's 6 	output should allow me to diagnose what's going on...  8 	Anyway, if the above message shows, all should be well;9 	now is the time to remember how you set up SLDRV/CSDRV - 7 	and probably you indeed want to repeat the sequence up - 	to this point a few times in order to check   		- if things work reliably < 		- if the PPP "server" is handing out the same IP addresses. 		  each time, or doing "dynamic" assignments.  8 	As you're experienced with SLDRV/CSDRV, you're aware of- 	how you configured CMU-IP for SLIP/CSLIP ...   ; 	Instead of e.g. configuring CSLIP via (in INTERNET.CONFIG)   @ 	    Device_Init:CSDRV:TTA2:rem.ip.ad.dr:lcl.ip.ad.dr:ne.t.ma.sk   	now use  C 	    Device_Init:MBDRV:PPP_MBX:rem.ip.ad.dr:lcl.ip.ad.dr:ne.t.ma.sk   = 	(with the IP addresses matching the PPP negotiation result). E 	With respect to the netmask, and possibly a "gateway" configuration, = 	there's absolutely no difference between PPP and SLIP/CSLIP.   = 	If you can predict the IP addresses that PPP will negotiate, 7 	you can start CMU-IP any time with this configuration; : 	otherwise you'll have to wait for the addresses to become7 	known (from running PPP.EXE), modify the configuration ' 	on the fly, and only then start IPACP.   : 	Once IP packets do get exchanged on the PPP link, PPP.EXE< 	will log a short line for each, telling you the packet sizeC 	(not too useful, I admit). CTRL-O has proven very useful here :-).   O Wolfgang J. Moeller, Goettingen, F.R.Germany      <moeller@gwdvms.dnet.gwdg.de> 