Chip 2004 April

home *** CD-ROM | disk | FTP | other *** search

/ Chip 2004 April / Chip_2004-04_cd1.bin / tema / arachne / archn170.exe / DOSPPPD.TXT < prev next >

Wrap

Text File | 2000-07-21 | 57.6 KB | 1,321 lines

Note: I created this file by merging README.TXT and PPPD.MAN from DOSPPPD.ZIP archive. Forget CHAT.EXE - Arachne uses it's own dialer, called MINITERM.EXE, which reads ARACHNE.CFG and can be used both as terminal for manual login or as dialer with autologin. Arachne also automagicaly creates file PPPDRC.CFG used by PPPD.EXE, using values from ARACHNE.CFG configuration file. Please send any comments to ARACHNE+DOSPPPD solution to xchaos@arachne.cz --- Begin (original filename: README.TXT) --- PPPD for DOS 0.6 beta Copyright (c) 1997 Antonio Lopez Molero CONTENTS INTRODUCTION WHO AM I LICENSING CREDITS ACKNOWLEDGEMENTS FEATURES UNSUPPORTED FEATURES FILES INSTALLATION CONFIGURATION AND USE CONFIGURATION FILES PAP/CHAP AUTHENTICATION VJ HEADER COMPRESSION BOOTP PROTOCOL EMULATION PACKET DRIVER STATISTICS REMOVING THE DRIVER ABOUT THE VARIOUS DRIVER EXECUTABLES DEBUGGING CONNECTION PROBLEMS ABOUT CHAT AND CHAT0 UNIQUE DOS CHAT FEATURES CONFIGURING DOS INTERNET APPLICATIONS SITES WITH ADDITIONAL DOS INTERNET STUFF INTRODUCTION This is the second release of my DOS PPP packet driver. This work is derived from various sources. The bulk of the PPP code is taken from the ppp2.2.0f PPP daemon version, the serial port handling code is derived from the KA9Q network operating system, and the packet driver interface code is derived from the CRYNWR packet driver collection. I did the tedious work of joining all these pieces and making it work as a TSR under our old friend DOS. I learned a lot about DOS TSR programming and the PPP protocol internals. I was pushed into developing this driver by the necessity of having something more stable than, and not as memory hungry as, the available DOS PPP packet drivers. I also enjoy free software so I felt that contributing to it in some way would be a nice thing to do. DOS still alive and there are a number of applications for this driver. The most obvious is for surfing the NET, as there are a number of good DOS programs for that. I enclose a list of locations where you can find such applications later in document. Another interesting field of application is in embedded PC computers used in industrial systems. For some palmtop computers that can't run the Windows CE version, this driver is a good alternative when used in conjunction with DOS internet programs. WHO AM I My name is Antonio Lopez (Toni). I work at the R+D dept. of a Process Automation firm in Spain. You can contact me at the following e-mail addresses: tonilop@redestb.es tonilop@ibm.net My English is not as good as I would like; I apologize for that. This work was done at home, and has nothing to do with my actual job. I'm responsible for the entire project. Don't bother the authors of the original code with bug reports; ask me. LICENSING The TERMIN.COM and PKTSTAT.COM programs are copyrighted by Russell Nelson and are released under the GNU public license. I provided it only as a convenience for users. You can download it from many places. COMTOOL.COM and COMTOOL.DOC are copyright by K.H. Weiss. They are freely distributable for non commercial use. Again, I provide these files only as a convenience for users. The CHAT source code is in the public domain, so CHAT.EXE and CHAT0.EXE are in the public domain too. The PPP code on which my work is based holds the following copyright: *********************************************************************** * Copyright (c) 1989 Carnegie Mellon University. * * All rights reserved. * * * * Redistribution and use in source and binary forms are permitted * * provided that the above copyright notice and this paragraph are * * duplicated in all such forms and that any documentation, * * advertising materials, and other materials related to such * * distribution and use acknowledge that the software was developed * * by Carnegie Mellon University. The name of the * * University may not be used to endorse or promote products derived * * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. * *********************************************************************** I release the package under the following conditions: All products mentioned in this documentation which are patented, copyrighted or are trademarks are the property of their respective owners. The various source modules written from scratch for DOS support, the README.TXT, SAMPLES.TXT, DOSPPPD.FAQ, CHANGELO.TXT and VJCSTAT.EXE files are Copyright (c) 1997 by Antonio Lopez Molero. All applicable rights reserved. DOS PPPD can be freely distributed for NON COMMERCIAL use, provided you include this copyright notice in all the copies or derivative works. You can charge money for the process of copying/transferring the files, but not for the software itself. You can't include DOS PPPD as part of a commercial package without prior writen permission from the author. DOS PPPD IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the product is with the user. This documentation explicitly states that DOS PPPD will not work properly in some circumstances; the user assumes the cost of all necessary servicing, repair or correction. In no event will Antonio Lopez Molero be liable for damages, including any general, special, incidental or consequential damages arising out of the use of, or inability to use, DOS PPPD (including but not limited to loss of data or data being rendered inaccurate or losses sustained by the user or third parties or a failure of the product to operate with any other programs), even if the author has been advised of the possibility of such damages. You may use DOS PPPD only if you have read, understood and accepted all of the above conditions. Please contact me to report bugs or errors in the document (even minor ones). If you are an application developer or packet driver programmer and have constructive suggestions for improving the performance of DOS PPPD I'd be glad to hear from you. Although I have a real job, donations will be greatly appreciated if you feel the need to make them ;-) If you are going to use DOS PPPD in a bussines environment, then a donation is strongly encouraged, if only for ethic purposes. Please contact me for details. CREDITS Credit for the PPP code goes to Al Longyear and Mike Callahan, the creators of the ppp2.2.0f package. The original PPP code was created by: Drew Perkins, Brad Clements, Karl Fox, Greg Christy, Brad Parker and Paul Mackerras. Credit for the serial port code goes to Phil Kharn, the creator of the excellent KA9Q Network Operating System. Credit for the packet driver code goes to Russell Nelson, the creator and maintainer of the superb CRYNWR packet driver collection. Credit for the BOOTP code goes to Bruce Campbell, the creator of the BOOTP packet driver add-on. I must mention Frank Molzahn, the creator of PPPPKT06. I used his techniques for netmask calculation based in remote/local IP addresses. ACKNOWLEDGEMENTS Many people has provided feedback or even contributed to DOS PPPD development, The following is a partial list: Jeffrey L. Hayes, he was the first beta tester for 0.5 release and did a fine job making corrections to my poor written documentation. He also provided his site for hosting DOS PPPD before it was submitted to Simtelnet, and developed detailed instructions for use it with his ISP. John Lewis from the BOBCAT team, he trusted DOS PPPD enough for including it as part of BOBCAT browser package. Frank Molzhan, who provided insight into important DOS & Internet topics, and encouraged me for continuing DOS PPPD development. He recently developed a very efficient SLIP/CSLIP drivers, which are a very good alternative to DOS PPPD for users who still using that connection method. Look in the links section for a place where to find his drivers. Ralph Shnelvar, who provided feedback and bussines oportunities for other DOS TCP/IP tools development. Richard White, who trusted DOS PPPD so much, and do use it for serious applications. Nigel Gorry, who maintains a WEB page about DOS and Internet, he provided suggestions for a better DOS PPPD, has put links to DOS PPPD archives on his page and provided some brief instructions aswell. Alfredo J. Coole, the developer of the enclosed SETUP program. He also encouraged me and provided suggestions for DOS PPPD. Jeff Patterson, developer of the only IRC DOS client I can use every day. He provided interesting discussions about DOS PPPD. Karl-Heinz Weiss, developer of the UKA_PPP package, he trusted DOS PPPD enough for including it in the UKA_PPP package. Jim Casey, Sysop at the Internet Resources Forum on Compuserve, who invited me to a forum discussing the future of DOS in Internet. Lots of people, in no particular order: Carlos V. Gutierrez Fragosa, Matthew Grimm, Sam Bushman, Follower of the Clawed Albino ??, Krishnamurti Subramanian, Morten Johansen, Pablo Carboni, Paul Koukos, Kalle Pihlajasaari, Alberto Gonzalez Talavan, Kevin CN Tan, Modhav Gokhale, Chris Blazie, Rian Coutinho, Lars Wigrell, Michael Polak, Fernando Navarro Paez, Morgan Toal, Soichiro Ishizuka, Super Ted, Juan H. Koers, Ki var, Brad Hlista, Sean Doherty, Peter Bel, Jesus Barcelo, Andre LeClaire, Yury Semenov, David Bernal, Agustin Vega, Don Johnson, Keith Weisshar, Ian Smith, Rene Ludwig, Dave Mehler, Giancarlo Guareschi, ... I'm probably missing people from the list, but I can't remember every one who contacted me, so I apologize for that. FEATURES The code is compiled for an 8088 CPU, so it should run on XT class machines. I have no access to any XT machine, so I was unable to test it on one. However, users of the previous release reported success in using DOS PPPD on XT hardware. The 16550AFN UART is supported, allowing reliable communications up to 115200 baud speed. The chip is autodetected and the FIFO enabled with an 8 byte receiver threshold. The transmitter is set up for a 16 byte output FIFO. The drivers conforms to FTP packet driver specification 1.09, same as the ones in the superb CRYNWR packet driver collection. Both class 1 (ethernet) and class 6 (serial line) drivers are included in the package. The class 1 drivers emulate a BOOTP server, so automatic configuration of DOS applications through BOOTP is possible. A DOS batch file for setting environment variables with the actual TCP/IP data for the connection is created. Most of the original PPPD options are supported, including PAP/CHAP authentication and VJ header compression. The next section covers what is not supported. UNSUPPORTED FEATURES CCP (compression control protocol, used for negotiating data field compression), IPX style packets, authentication of the peer (we can authenticate ourselves using PAP, however), PPP server mode, PAP/CHAP password encryption, defaultroute option, proxyarp option, noipdefault option. FILES DOS PPPD is distributed as a single .ZIP file, containing: README.TXT This file. SAMPLES.TXT Some sample configurations for PPPD use. I use these to connect to my ISP. CHANGELO.TXT Summary of changes among versions. DOSPPPD.FAQ An atempt to make a recopilation of common problems with their solutions, based on users feedback. PPPD.MAN A plain ASCII version of the UNIX pppd man page, adapted for the DOS version. CHAT.MAN A plain ASCII version of the UNIX chat man page, adapted for the DOS version. PPPD.EXE Class 6 (serial line) PPP driver without debug capability, no CHAP support, smallest. PPPDD.EXE Class 6 (serial line) PPP driver with debug capability, no CHAP support. EPPPD.EXE Class 1 (ethernet emulation) PPP driver without debug capability, no CHAP support. Emulates ARP and BOOTP replies to help configure DOS applications. EPPPDD.EXE Same as above but with debug capability, no CHAP support, largest. VJCSTAT.EXE Utility for displaying VJ header compression statistics. PKTSTAT.COM Utility for displaying packet driver statistics. TERMIN.COM Packet driver terminator. CHAT.EXE Modem connection tool for use with the 'connect' option from PPPD. It can not be used standalone. CHAT0.EXE Modem connection tool for standalone use. COMTOOL.COM Tiny serial port manipulation utility. COMTOOL.DOC Documentation for COMTOOL. SPANISH.ZIP Archive containing spanish language documentation. CHAPSUPP.ZIP Archive containing driver executables with CHAP support compiled in. SETUP.ZIP Archive containing Alfredo J. Coole's DOS PPPD Setup program. INSTALLATION Create a directory of your choice, say C:\DOSPPP, and unzip the distribution file in it. If you are (or speak) spanish, unzip the SPANISH.ZIP in the same directory, all the documentation files will be overwritten by spanish language versions. If you do need CHAP support, unzip the CHAPSUPP.ZIP file in the same directory, PPP driver executables will be overwritten by ones with CHAP support compiled in. If you do want to use the helper SETUP application, unzip the SETUP.ZIP file in the same directory. After unziping the required files, you must configure DOS PPPD before being able to use it. For configuring DOS PPPD using the helper SETUP application, please read the SETUP.TXT file. If you want to manually configure it, please read the following sections of this document. It is a good idea to read them even if you are going to use SETUP. CONFIGURATION AND USE I tried to mimic the original PPPD version as much as possible, so any experience you might have with it may prove useful with this program. For a complete reference of PPPD and CHAT options, look at the files PPPD.MAN and CHAT.MAN. These files were adapted from the original man pages. The SAMPLES.TXT file contains detailed configuration examples, I will give an usage overview here. The process of establishing a PPP link can be divided into two clearly separate actions, connection of the physical serial line and execution of a PPP process responsible for the actual TCP/IP communications. The physical serial line connection would be different for modem links than for cable serial links. The former requires some mechanism for talking to the modem, making it dial and establishing a connection with the modem on the other end. The latter doesn't require that step, as the serial ports are directly attached via a cable. For modem links you have two ways of making the connection. One is to use some program prior to PPPD execution that interacts with the modem and leaves the connection open after exiting. You then run PPPD, which takes over the link and begins its negotiations. One such program is KERMIT, a general purpose terminal emulator for the PC. You can also use the enclosed CHAT0.EXE program to connect in that way. The second way is to use the 'connect' option from PPPD to specify a program that must be run for modem handling. At the moment you can only use the enclosed CHAT.EXE program for this, as the COM port is internally handled by PPPD, and there is a private interface between the two programs that allows CHAT to use whatever port PPPD is configured to use. That is necessary because you can't do the serial port stuff under DOS the same way you do under *NIX. When running under *NIX OS, CHAT uses stdin/stdout for its I/O. Those file handles are redirected by PPPD to the serial port before invoking the 'connect' script. In any case you specify the serial port to use and some other stuff via options to PPPD. Those options can be given on the command line or taken from an options file. CHAT only supports command line options, but the CHAT script can be in a file. A tiny sample usage of DOS PPPD with modem follows: pppd com1 38400 connect "chat '' AT&F OK ATDP055 CONNECT" In this sample we are using the enclosed CHAT.EXE program to talk to the modem using the port settings inherited from DOS PPPD. The DOS PPPD program sets up COM1 at 38400 baud speed and then invokes CHAT to establish the serial link. The chat script shown expects nothing, sends AT&F, expects OK, sends ATDP055 and expects CONNECT. If all of these expect/send pairs succeed, CHAT exits with a 0 exit code signaling to PPPD that it can proceed with PPP negotiations. If some error occured during the CHAT phase, the CHAT program returns a nonzero exit code that signals to DOS PPPD that something was wrong with the connection. Assuming CHAT succeeds, then DOS PPPD's next job is to negotiate IP link establishment. Only when that link is successfully negotiated will DOS PPPD stay resident in memory as a packet driver. In all other cases the program exits with a nonzero exit code and does not remain resident. A message showing the packet driver interrupt used by the driver will be displayed upon successful link establishment. If the driver can't establish a successful PPP link, an error message will be displayed. The DOS PPPD exit code may be checked in DOS batch files in order to trigger the appropiate actions based on whether the connection was successful or unsuccessful. For directly attached computers, one would simply do: pppd com1 38400 local The 'local' option forces DOS PPPD to ignore the CARRIER DETECT line, which may not be available for the cable connection. CONFIGURATION FILES The DOS PPPD program looks for options in several places besides the command line. The names and search order for the files are as follows: PPPD.CFG in the current directory. PPPD.CFG in the same directory PPPD.EXE is located. PPPDRC.CFG in the current directory. command line options pppd 'file' option full path given. PPPDCOM?.CFG in the current directory. PPPD.CFG can be viewed as a global options file, as it can be located under the same directory PPPD.EXE resides. PPPDCOM?.CFG completes its name based on the COM port used, so invoking 'pppd com1' will look for a PPPDCOM1.CFG file. All the files excluding the one given with the 'file' option are optional and don't need to exist for PPPD to operate. However, the use of configuration files is a practical necessity due to restrictions on the length of the the DOS command line. These files can be given hidden/system/read-only DOS attributes, as the PAP/CHAP passwords (if used) must be included in them. I know that that a very poor security implementation, but it is all that can be done under DOS until I implement password encryption. PAP/CHAP AUTHENTICATION These methods of authentication are supported by the driver. There is no /etc/pap-secrets nor /etc/chap-secrets file under DOS, so I took the approach of implementing a new PPPD option, 'passwd'. This one, in conjunction with the 'user' option, provides DOS PPPD with the necessary data for authenticating itself with the peer. Note that there is no way to specify a remote name, which original *NIX pppd uses for selecting a secret from one of the authentication files. In CHAP mode the remote adds its hostname to the CHAP challenge, so the local pppd can look in the /etc/chap-secrets file for a secret that matches a particular remote host. DOS PPPD always sends the same user/passwd secret regardless of the remote hostname. A typical use would be: pppd com1 38400 user self passwd blah connect "chat '' ATDP055 CONNECT" These options can be include in a configuration file that has the hidden attribute, for example the file myppp.cfg containing: com1 38400 modem asyncmap 0 connect "chat '' AT&F OK ATDP055 CONNECT" user someuser passwd blah2blah You can run PPPD with: pppd file myppp.cfg In fact, the above options could be in any of the automatic configuration files searched by PPPD and then you can forget the 'file' option. The 'user' and 'passwd' fields can be surrounded in double quotes in case there are embedded blanks or characters that may be interpreted by PPPD's options parser. An alternative source for PAP/CHAP authentication data can be given with the '+ua' option. You give the name of a file that contains the user id and the password, for example assume a file called AUTHEN.DAT: pppuser pppuser_password Then invoke PPPD as: pppd com1 38400 +ua authen.dat The file can have the hidden attribute set. VJ HEADER COMPRESSION This release supports VJ header compression, and the driver tries to use it by default unless the peer forbid it during IPCP negotiations. VJ compression reduces the length of TCP/IP headers, and theoretically boosts performance over slow lines and interactive connections like TELNET. I said theoretically because VJ compression involves some CPU overhead, that might be noticed on slow CPUs (i.e. 4.77 Mhz 8088). There are options for disabling it (-vj, DOS PPPD will not negotiate nor allow the peer to use it), consult PPPD.MAN for more information. BOOTP PROTOCOL EMULATION Some DOS Internet applications support a method for automatic TCP/IP configuration, called the BOOTP protocol. The Ethernet emulation versions of the DOS PPPD driver support this form of configuration, acting as fake BOOTP servers that generate a reply when they see a BOOTP request. In order to fully support the BOOTP protocol, I added an option that doesn't exist in the original DOS PPPD code. The option is 'namsrv' and is intended for specifiying up to two nameservers' IP addresses that will be sent to the application doing a BOOTP request. The rest of BOOTP information is generated from the local/remote IPs negotiated by DOS PPPD during the link establishment phase. The remote IP will be used for the gateway address and server address; the local IP will be used for 'your_ip' address. The netmask is calculated by the following method: First, a value is obtained based just on the class (i.e. class A, B or C) of the local IP, specifically: class A ==> 255.0.0.0 class B ==> 255.255.0.0 class C ==> 255.255.255.0 If this value is consistent with the gateway's IP number, that is, if: ( <netmask> & <gateway> ) = ( <netmask> & <localIP> ) [where & represents logical AND], then this value is used as the netmask. (See RFC 950.) Otherwise, a different netmask value is chosen: it is the largest number which (a) is consistent in the above sense, and (b) has a binary form of 1's followed by 0's. This method is the same used by Frank Molzahn's PPPPKT06 driver. This calculated value is then binary ORed with any user supplied value through the 'netmask' option. This netmask calculation method applies to both the class 6 and class 1 versions of the drivers, regardless of the BOOTP support. PACKET DRIVER STATISTICS Starting with version 0.6 beta, the drivers support the 'get_stats()' packet driver function call, so it is possible to make use of the CRYNWR PKTSTAT program for displaying number of received packets, number of transmit packets, number of receive errors, etc. Another utility specially developed for DOS PPPD is VJCSTAT, which displays statistics about VJ header compression. This one is DOS PPP specific, so it won't work with other packet drivers. Both utilities should be run from the command line, and accept an optional parameter for the packet driver vector to look at. If you don't provide a vector number, the first one found in the valid packet driver vector range is reported. These utilities are useful for determining the reliability of the PPP connection, and for debug purposes. For example, if PKTSTAT reports a large number of dropped packets, but the received packet error count is 0, then it means that some application that uses the packet driver is running out of buffers when packets arrive too fast. It can also mean that you are receiving unsupported PPP frame types, like CCP or some kind of Microsoft PPP protocol extensions. REMOVING THE DRIVER To remove the driver, use the enclosed TERMIN.COM program. This is a general purpose packet driver terminator, part of the CRYNWR packet driver collection. Call it as: TERMIN 0xnn Where nn is the hex number of the interrupt vector used by the installed driver, i.e. TERMIN 0x60. The PPPD driver will send a Terminate request to the peer before being removed, so the TERMIN return to the command line will be delayed a little. This delay can be of maximum of 10 seconds, depending on how fast the peer responds to the terminate request. ABOUT THE VARIOUS DRIVER EXECUTABLES As you noticed, there are four different DOS PPPD executables. The ones called PPPD.EXE and PPPDD.EXE are class 6 packet drivers (serial line), the later including some debug capabilities that can be used for troubleshooting connection problems. The ones called EPPPD.EXE and EPPPDD.EXE are class 1 packet drivers (Ethernet). EPPPDD.EXE contains additional code for debugging connection problems. These emulate the behavior of a real Ethernet driver, adding an Ethernet header to incoming packets and removing it from sent packets. The need for emulation comes from the fact that many DOS Internet applications were devised for Ethernet-only packet drivers, and can't handle class 6 packet drivers. The Ethernet emulation versions support BOOTP, a protocol used by TCP/IP networking code to auto-configure workstations via a centralized server. As noted in the installation section, a separate archive contains driver executables with CHAP support, but the names are the sames as the above ones. If you require CHAP authentication, simply replace the original (no CHAP support) drivers with the ones in CHAPSUPP.ZIP. I decided to provide it as separate executables for reducing memory requeriments in standar drivers if you do not require CHAP support, which is the most common case. DEBUGGING CONNECTION PROBLEMS The executables with debugging capability generate various kinds of messages on DOS standard output, and others on DOS standard error. You can use redirection to log the standard output to a file; standard error can be redirected with the help of some third party utilities. The debug level is affected by the 'debug' and 'kdebug' options, supported only by the PPPDD.EXE and EPPPDD.EXE executables. Look in the PPPD.MAN file for a deeper explanation. The debugging output stops as soon as the driver goes resident; supporting disk I/O under DOS TSRs is a difficult task that isn't worth the time wasted to implement it. ABOUT CHAT AND CHAT0 The CHAT program takes a series of strings called the CHAT script and executes an expect/send sequence until it consumes all the script or any of the expectations fails. The CHAT script can be given in the command line or through a file. In the DOS world where command line length is restricted, the script file is the recommended way unless your CHAT script is very short. As noted elsewhere in this document, two CHAT versions are enclosed in the package. CHAT.EXE is intended to be used with the 'connect' option from PPPD. It accesses the serial port through a private interface in PPPD.EXE, so it doesn't require options for COM port configuration. It uses the port for which DOS PPPD is configured. CHAT0.EXE can be used standalone, as it incorporates its own routines for COM access. Having two versions is convenient, because you can use CHAT0.EXE to test your CHAT script before you actually use it with CHAT.EXE and the DOS PPPD 'connect' option. CHAT0.EXE will leave the DTR line high upon successful termination, so the modem connection will be active, and you can run PPPD after that. This behavior is the same as if you were using some other dialing program - KERMIT, for example. UNIQUE DOS CHAT FEATURES After porting CHAT code to DOS, I realized that it might be useful to enhance it with additional features not found in the original *NIX version. I added two new functions, interactive terminal mode and string capture. Interactive terminal mode is useful when you log into systems which require convoluted prompts or/and menus, or when you don't know the required login sequence beforehand. Interactive mode can be entered at an arbitrary chat script location, so it can be used for completing selected parts of the login process, i.e. user id and password. The CHAT.MAN and SAMPLES.TXT files contain implementation details and examples of CHAT interactive mode. String capture provides a mechanism for "grabbing" selected parts of text sent by the remote system and assign them to DOS environment variables. You can capture IP numbers, decimal numbers or arbitrary strings; a DOS batch file is generated by CHAT, you can execute it for setting the DOS environment variables. This feature is most useful for SLIP dial out, where the local and remote IP are reported by the remote through the serial line as plain text. Both CHAT.EXE and CHAT0.EXE support interactive mode and string capture functions, althought these make more sense when using CHAT0.EXE as a standalone dialer for SLIP links, or non standar PPP implementations even. CONFIGURING DOS INTERNET APPLICATIONS There a number of different schemes used by DOS applications to configure the required TCP/IP parameters. Some of them support the BOOTP protocol, a feature that is supported by the EPPPD.EXE and EPPPDD.EXE drivers. WATTCP based applications will try BOOTP configuration if the WATTCP.CFG file (or equivalent) can't be found, or if you put a line: my_ip=bootp in such file. The POPMAIL and MINUET applications will use BOOTP if you leave the Network configuration dialog boxes blank. Consult the application documentation for more info about how to use BOOTP. If your application doesn't support BOOTP, or if you are using the PPPD.EXE or PPPDD.EXE drivers, the configuration must be done by another means. All the four drivers generate a .BAT file called IP- UP.BAT that is meant to be run after successful connection to set some DOS environment variables. Then you can use those variables inside a DOS batch file for generating text configuration files, for example the WATTCP.CFG file required by WATTCP applications. The IP-UP.BAT generated by the PPP drivers looks like: SET MYIP=xxx.xxx.xxx.xxx SET REMIP=yyy.yyy.yyy.yyy SET NETMASK=zzz.zzz.zzz.zzz SET PEERMRU=nnnn Some of the samples in SAMPLES.TXT file will make use of these variables to show how to configure WATTCP applications (DOSLYNX) using this technique. For MINUET and POPMAIL, the environment is searched for a variable called MYIP if the corresponding field in the Network configuration dialogs is blank. It the variable can't be found, these applications try the BOOTP method. If none of these methods is suitable, you are forced to enter the required configuration data every time you run the application. There are some cases in which command line arguments can be used for the TCP/IP configuration, like the PCGOPHER program (which supports BOOTP also). The file SAMPLES.TXT contains some examples derived from my actual DOS application configurations, including DOSLYNX and MINUET. SITES WITH ADDITIONAL DOS INTERNET STUFF The following sites hold lots of good DOS Internet stuff, these are the places to go if you are looking for WEB browsers, mailers, etc. TVDog's DOS Internet page: http://www.agate.net/~tvdog/internet.html Frank Molzahn's SLIP/CSLIP packet drivers: http://home.cc.umanitoba.ca/~molzahn/cslip.html Nigel's DOS PPP applications unfinished list: http://www.palms.nq.net/ppp.html DOSLYNX home page: http://www.fdisk.com/ KERMIT: http://www.columbia.edu/kermit/ Althought not an Internet application in its own, kermit can be a invaluable terminal emulator and modem dialer. Recent versions incorporates the WATTCP TCP/IP kernel, so they can act as good TELNET clients when used with a packet driver. WWW Browsers for DOS: http://www.concentric.net/~cruzing/dosinet/dosinet.shtml RealmSpace for the DOS: http://www.best.com/~darknerd/realmspace/rsdos.htm DOS INTERNET FILES, INFORMATION, AND LINKS: http://www.westsound.com/ptmudge/dos_inet.htm DOS Internet home page: http://www.wustl.edu/~hugh/dos-www.html --- End (original filename: README.TXT) --- --- Begin (original filename: PPPD.MAN) --- PPPD for DOS 0.6 beta NAME pppd - Point to Point Protocol packet driver SYNOPSIS pppd [ COMn ] [ speed ] [ options ] DESCRIPTION The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: a method for encapsulating datagrams over serial links, an extensible Link Control Protocol (LCP), and a family of Network Control Protocols (NCP) for establishing and configuring different network- layer protocols. DOS pppd provides the encapsulation scheme, basic LCP, authentication support, and an NCP for establishing and configuring the Internet Protocol (IP) (called the IP Control Protocol, IPCP). FREQUENTLY USED OPTIONS <COMn> Specifies the COM port to use for communicating with the peer. Port COM1 through COM4 can be used; the standard base address and IRQ are assumed unless you change the default with other options. Basic testing (through BIOS) is done to ensure COM availability. If pppd fails with message: Invalid COM device COM? Then probably you have a non standard COM port setup. Omit the COM? keyword from configuration and specify COM port values with the following two options, base and irq. base <port address> Specifies the base address for the COM port, in the event that it is a non-standard one. The number can be entered in hex, octal or decimal, following the C language rules for parsing numbers (0xnnn is hex for example). No attempt is made to verify that a valid COM port exists at the address, so use this option with care. irq <IRQ number> Specifies the IRQ number used by the COM port. The same considerations as above apply. pktvec <interrupt number> Specifies the interrupt vector number to be hooked by the packet driver interface. The valid range is from 0x60-0x66, 0x68-0x6F and 0x78-0x7E. If this option is not used, the driver searches for the first free vector in this range (usually 0x60). namsrv <n> Set IP addresses to return in the DNS field of BOOTP replies. Supported only by the ethernet emulation versions EPPPD.EXE and EPPPDD.EXE. Up to two nameservers can be specified. This option is useful for configuring DOS Internet applications through BOOTP. <speed> Specifies the speed for serial comunications. Up to 115200 baud can be programmed, but beware that serial ports that have the old 8250 UART cannot handle speeds higher than 9600 reliably. The number can be entered in hex, octal or decimal, as in the above options. asyncmap <map> Set the async character map to <map>. This map describes which control characters cannot be successfully received over the serial line. pppd will ask the peer to send these characters as a 2- byte escape sequence. The argument is a 32 bit hex number with each bit representing a character to escape. Bit 0 (00000001) represents the character 0x00; bit 31 (80000000) represents the character 0x1f or ^ . If multiple asyncmap options are given, the values are ORed together. If no asyncmap option is given, no async character map will be negotiated for the receive direction; the peer should then escape all control characters. connect Use the command specified by to set up the serial line. The CHAT.EXE program must be used with this option, as the COM port is controled by pppd and a private interface is used between the two programs for granting COM access to CHAT. pppd will look in the current directory first, then in the same directory where pppd resides. crtscts Use hardware flow control (i.e. RTS/CTS) to control the flow of data on the serial port. If neither the crtscts nor the -crtscts option is given, the hardware flow control setting for the serial port is left unchanged. escape xx,yy,... Specifies that certain characters should be escaped on transmission (regardless of whether the peer requests them to be escaped with its async control character map). The characters to be escaped are specified as a list of hex numbers separated by commas. Note that almost any character can be specified for the escape option, unlike the asyncmap option which only allows control characters to be specified. The characters which may not be escaped are those with hex values 0x20 - 0x3f or 0x5e. file <f> Read options from file <f> (the format is described below). mru <n> Set the MRU [Maximum Receive Unit] value to <n> for negotiation. pppd will ask the peer to send packets of no more than <n> bytes. The minimum MRU value is 128. The default MRU value is 1500. A value of 296 is recommended for slow links (40 bytes for TCP/IP header + 256 bytes of data). mtu <n> Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer requests a smaller value via MRU negotiation, pppd will request that the kernel networking code send data packets of no more than n bytes through the PPP network interface. netmask <n> Set the interface netmask to <n>, a 32 bit netmask in "decimal dot" notation (e.g. 255.255.255.0). If this option is given, the value specified is ORed with the default netmask. The default netmask is chosen based on the negotiated remote IP address; it is the appropriate network mask for the class of the local IP address and that satisfies the following condition: (<netmask> & <remoteIP>) = (<netmask> & <localIP>) The default netmask is right shifted if necessary until the above condition is reached. OPTIONS <local IP address>:<remote IP address> Set the local and/or remote interface IP addresses. Either one may be omitted. The IP addresses must be given in decimal dot notation (e.g. 150.234.56.78). IP addresses will be obtained from the peer if not specified in any option. Thus, in simple cases, this option is not required. If a local and/or remote IP address is specified with this option, pppd will not accept a different value from the peer in the IPCP negotiation, unless the ipcp- accept-local and/or ipcp-accept-remote options are given, respectively. -ac Disable Address/Control compression negotiation (use default, i.e. address/control field compression disabled). -all Don't request or allow negotiation of any options for LCP and IPCP (use default values). -am Disable asyncmap negotiation (use the default asyncmap, i.e. escape all control characters). -as <n> Same as asyncmap <n> -chap Don't agree to authenticate using CHAP. chap-restart <n> Set the CHAP restart interval (retransmission time- out for challenges) to <n> seconds (default 3). -crtscts Disable hardware flow control (i.e. RTS/CTS) on the serial port. If neither the crtscts nor the -crtscts option is given, the hardware flow control setting for the serial port is left unchanged. -d Increase debugging level (same as the debug option). debug Increase debugging level (same as -d). If this option is given, pppd will log the contents of all control packets sent or received in a readable form. The packets are logged through DOS standard output, which can be redirected to a file. Some debug output is sent to DOS standard error. This options is supported by PPPDD.EXE & EPPPDD.EXE. -ip Disable IP address negotiation. If this option is used, the remote IP address must be specified with an option on the command line or in an options file. ipcp-accept-local With this option, pppd will accept the peer's idea of our local IP address, even if the local IP address was specified in an option. ipcp-accept-remote With this option, pppd will accept the peer's idea of its (remote) IP address, even if the remote IP address was specified in an option. ipcp-max-configure <n> Set the maximum number of IPCP configure-request transmissions to <n> (default 10). ipcp-max-failure <n> Set the maximum number of IPCP configure-NAKs returned before starting to send configure-Rejects instead to <n> (default 10). ipcp-max-terminate <n> Set the maximum number of IPCP terminate-request transmissions to <n> (default 3). ipcp-restart <n> Set the IPCP restart interval (retransmission timeout) to <n> seconds (default 3). kdebug n Enable debugging code in the low-level PPP driver. The argument n is a number which is the sum of the following values: 1 to enable general debug messages, 2 to request that the contents of received packets be printed, and 4 to request that the contents of transmitted packets be printed. This option is supported by PPPDD.EXE & EPPPDD.EXE. lcp-echo-failure <n> If this option is given, pppd will presume the peer to be dead if n LCP echo-requests are sent without receiving a valid LCP echo-reply. If this happens, pppd will terminate the connection. Use of this option requires a non-zero value for the lcp-echo- interval parameter. This option can be used to enable pppd to terminate after the physical connection has been broken (e.g., the modem has hung up) in situations where no hardware modem control lines are available. lcp-echo-interval <n> If this option is given, pppd will send an LCP echo-request frame to the peer every n seconds. Under Linux, the echo-request is sent when no packets have been received from the peer for n seconds. Normally the peer should respond to the echo-request by sending an echo-reply. This option can be used with the lcp-echo-failure option to detect that the peer is no longer connected. lcp-max-configure <n> Set the maximum number of LCP configure-request transmissions to <n> (default 10). lcp-max-failure <n> Set the maximum number of LCP configure-NAKs returned before starting to send configure-Rejects instead to <n> (default 10). lcp-max-terminate <n> Set the maximum number of LCP terminate-request transmissions to <n> (default 3). lcp-restart <n> Set the LCP restart interval (retransmission timeout) to <n> seconds (default 3). local Don't use the modem control lines. With this option, pppd will ignore the state of the CD (Carrier Detect) signal from the modem and will not change the state of the DTR (Data Terminal Ready) signal. modem Use the modem control lines. This option is the default. With this option, pppd will wait for the CD (Carrier Detect) signal from the modem to be asserted when opening the serial device (unless a connect script is specified), and it will drop the DTR (Data Terminal Ready) signal briefly when the connection is terminated and before executing the connect script. -mn Disable magic number negotiation. With this option, pppd cannot detect a looped-back line. -mru Disable MRU [Maximum Receive Unit] negotiation. With this option, pppd will use the default MRU value of 1500 bytes. -pap Don't agree to authenticate using PAP. pap-max-authreq <n> Set the maximum number of PAP authenticate-request transmissions to <n> (default 10). pap-restart <n> Set the PAP restart interval (retransmission timeout) to <n> seconds (default 3). passwd Set the user password to use for authenticating this machine with the peer using PAP/CHAP to . -pc Disable protocol field compression negotiation (use default, i.e. protocol field compression disabled). +ua Agree to authenticate using PAP/CHAP if requested by the peer, and use the data in file for the user and password to send to the peer. The file contains the remote user name, followed by a newline, followed by the remote password, followed by a newline. user Set the user name to use for authenticating this machine with the peer using PAP/CHAP to . -vj Disable negotiation of Van Jacobson style TCP/IP header compression (use default, i.e. no compres- sion). -vjccomp Disable the connection-ID compression option in Van Jacobson style TCP/IP header compression. With this option, pppd will not omit the connection-ID byte from Van Jacobson compressed TCP/IP headers, nor ask the peer to do so. vj-max-slots n Sets the number of connection slots to be used by the Van Jacobson TCP/IP header compression and decompression code to n, which must be between 2 and 16 (inclusive). xonxoff Use software flow control (i.e. XON/XOFF) to control the flow of data on the serial port. OPTIONS FILES Options can be taken from files as well as the command line. pppd reads options from the files .\pppd.cfg (also in the directory where the pppd program is located) and .\pppdrc.cfg before looking at the command line. After parsing command line options, a file named .\pppdcom?.cfg is tried, the ? will be replaced with the current COM number. An options file is parsed into a series of words delimited by whitespace. Whitespace can be included in a word by enclosing the word in quotes ("). A backslash (\) quotes the following character. A hash (#) starts a comment, which continues until the end of the line. If you need to put DOS path separators in options files, you must use the escape sequence \\, for example: +ua c:\\secrets\\paplogin This is needed because the \ character is interpreted as the beginning of an escape control code. AUTHENTICATION PAP/CHAP authentication with the peer is supported by this release. It doesn't support authenticating the peer to ourselves, so it is not well suited for acting as a PPP server. You are required to supply two items for authentication, a user name and a password. Options are available for setting these two items. An authentication file can also be used with the +ua filename option. EXAMPLES In the simplest case, you can connect the serial ports of two machines and issue a command like pppd com1 9600 passive If the other machine is running UNIX and has a getty process attached to the serial port we want to use, the process of logging in to the other machine and starting pppd can be automated by using the connect option to run chat, for example: pppd com1 38400 connect "chat '' '' 'login:' 'username' 'Password:' 'password' '% ' 'exec pppd passive'" (Note however that running chat like this will leave the password visible in the parameter list of pppd and chat.) If your serial connection is any more complicated than a piece of wire, you may need to arrange for some control characters to be escaped. In particular, it is often useful to escape XON (^Q) and XOFF (^S), using asyncmap a0000. If the path includes a telnet, you probably should escape ^] as well (asyncmap 200a0000). If the path includes an rlogin, you will need to use the escape ff option on the end which is running the rlogin client, since many rlogin implementations are not transparent; they will remove the sequence [0xff, 0xff, 0x73, 0x73, followed by any 8 bytes] from the stream. DIAGNOSTICS The debug versions PPPDD.EXE and EPPPDD.EXE incorporate additional code for diagnostic purposes. The log will be sent to DOS standard output and error/informative messages will go to DOS standard error. Logging will cease after the driver goes resident, so its usefulness is limited to debugging the link establishment phase. The debug option causes the contents of all control packets sent or received to be logged, that is, all LCP, PAP, CHAP or IPCP packets. This can be useful if the PPP negotiation does not succeed. If debugging is enabled at compile time, the debug option also causes other debugging messages to be logged. FILES .\ip-up.bat A DOS batch file generated by pppd that will set environment variables with the current PPP link parameters, such local IP, remote IP, etc. The file contains the following statements: SET MYIP=xxx.xxx.xxx.xxx SET REMIP=yyy.yyy.yyy.yyy SET NETMASK=zzz.zzz.zzz.zzz SET PEERMRU=nnnn This file can be called from inside another batch file and then use the environment variables for DOS Internet applications configuration. full_path_to_pppd\pppd.cfg .\pppd.cfg System default options for pppd, read before user default options or command-line options. .\pppdrc.cfg User default options, read before command-line options. .\pppdcom?.cfg System default options for the serial port being used, read after command-line options. SEE ALSO RFC1144 Jacobson, V. Compressing TCP/IP headers for low- speed serial links. 1990 February. RFC1321 Rivest, R. The MD5 Message-Digest Algorithm. 1992 April. RFC1332 McGregor, G. PPP Internet Protocol Control Protocol (IPCP). 1992 May. RFC1334 Lloyd, B.; Simpson, W.A. PPP authentication protocols. 1992 October. RFC1548 Simpson, W.A. The Point-to-Point Protocol (PPP). 1993 December. RFC1549 Simpson, W.A. PPP in HDLC Framing. 1993 December. NOTES You can use CTRL+BREAK to abort the driver before it goes resident. You must use CTRL+BREAK, CTRL+C doesn't work To close the PPP link and deinstall the driver you must use a standard packet driver terminator, such as TERMIN.COM from Russell Nelson (CRYNWR). Call it with: TERMIN 0xnn Where nn is the hex number of the interrupt vector used by the installed driver, i.e. TERMIN 0x60. AUTHORS DOS port by Antonio Lopez Molero, <tonilop@redestb.es>. Drew Perkins, Brad Clements, Karl Fox, Greg Christy, Brad Parker, Paul Mackerras (paulus@cs.anu.edu.au). --- End (original filename: PPPD.MAN) ---