Introduction ------------ This is a package that implement PPP for Minix 2.0.2/3/4 in 16 and 32 bits. It also can be used under Minix-VMD 1.7.0. This version includes LCP/IPCP negotiation, PAP and CHAP authentication, VJ header compression, protocol compression, address/header compression, BSD compression, address translation, automatic DNS configuration, and route configuration. There is a server option that allows you to handle incoming PPP connections. Check server.txt for configuration details. The negotiation should be automatic. The driver try to use compression and no escape characters by default, but if the peer does not support it, it reduce the options until reach the default (RFC suggested) parameters. You can make a smaller driver modifying compilation options. See the config.h file to customize your driver. The driver is implemented by a user mode program. After negotiation, the original program forks itself, so the new program manages transmition of PPP frames, and the original manages the reception. This kind of operation allows to be full duplex and is very quickly. The tests I did with this driver were with telnet, ftp, rlogin, popclient, smr and lynx. All the testing was done with my ISP, and with a Linux machine using pppd as client and server (pppd version 2.3.11) . Also, I linked the 2 machines using Minix and the ppp driver, and I used it for simple comunication like telnet and ftp. Check the Minix-link file for details. NOTICE ------ The driver is not danger for the Minix kernel. There are no need to modify the kernel, but you always should be carefull with your information when you run foreign programs. Also, I believe that is a good practice to compile the all kernel image before modifying it, so this allow you to know the real state of the changes, and possible errors that can ocurr. Remember that you need to enable networking code. Check the /usr/include/minix/config.h for details. Instalation ----------- Before any change, you should compile your kernel at all with network code enabled, and you should boot your new kernel. You can download some kernels with networking enabled from my home page, or download some DOSMINIX zips files with all the code ready. Check the ftp/http sites. All the following information is ONLY for standard Minix, for Minix-VMD check the man pages (networking and serial port enabling). If you need to compile your kernel, you need to make some configurations in /usr/include/minix/config.h to enable the network code defining ENABLE_NETWORKING to 1. You can open the tar file for example on /ppp. I will use that path to explain the operation. For low memory systems, you can get configuration files from the XT directory. The files can get you a good idea on big memory systems. The kernel driver is unpackaged by executing the following: # cd /ppp/ppp # make <== make the ppp.drv driver # make install <== installs the driver and man page. The "make" command compile the driver. You can install it with the second command "make install", it installs it into /usr/local/bin with proper privileges and the man page in /usr/local/man/man1. The "make install" may do all the process if you like. The make command prepares 2 drivers. ppp.drv is the client driver, ppp.srv is to be used as a server. You can check the config.h file, to disable some defines, so you can get a smaller driver (i.e. if you have low memory). I recomend you to use header compression, but it uses memory. Debugging should be disable because it is not usefull on normal operation, and because it adds more code and make the driver slowly. Enable it only if you want to trace at the packet level. The slcp utility is a simple script that lets you control the operation of the driver. It allows you to enable or disable debugging while working, and also end the conection and hang-up the modem via the chat program. It is a script so you can adapt it to your necessity. The script is copied to /usr/local/bin if you have an old version, in the install process. /**************************************************************************/ There is a patch to rs232.c needed to be applied if you like that the system stops driver when a hangup is detected. Check patch.txt for details. /**************************************************************************/ The chat program also can be compiled with make: cd /ppp/chat make <== makes the chat program make install <== installs chat command in /usr/local/bin and man page. This left the chat program in /usr/local/bin, you need to have the directory in your path to execute. Also it install the chat man page. Configuration ------------- There are some tips for configuration. The most easy is to use the default network for PPP. If you have no ethernet cards, you can use this configuration. If you like to have a local network and use PPP as ocassionality connection, you need to configure routing. Check the add_route command and the routing papers in the documentation. # netdefault psip2 This will configure your network to use psip devices. You need to start the minimun net daemons, modifying the /etc/rc file as: echo -n "Starting network daemons: " # for daemon in rarpd nonamed irdpd talkd <<== starts only nonamed for daemon in nonamed do if [ -f /usr/bin/$daemon ] then echo -n " $daemon" $daemon & fi done echo . # Get the nodename from the DNS and set it. # hostaddr -a >/etc/hostname.file || echo noname >/etc/hostname.file ^ ########^ comment this line!!!!!!!!!!! You can only start the nonamed daemon, only for name resolution, and avoid it getting with hostaddr the name, to avoid hanging the system at startup. Or you can not start daemons, and use resolv.conf managed by the ppp driver or by hand. If you prefer that ppp.drv controls the file, remember that the actions are: - if the file exists, ppp.drv add the naameserver option, you need to check the status. You can have problems with different ISPs, so you will have a lot of entries and will be slow to resolve names. The resolver routines uses dns entries and each query may be slow. - rename the /etc/resolv.conf file, so pppp.drv always creates a new one. In this situation, the driver deletes the file when the conection end. To handle DNS by the driver, supply the flag (-N) to the driver. I recomend you to have no resolv.conf file, if you have several ISPs, if you have only one ISP, you can get the DNS info from it, or from ppp.drv, and hand edit the resolv.conf file, and do not use the -N flag. After this modifications, you can have an empty /etc/rc.net file. # cp /dev/null /etc/rc.net # chmod 755 /etc/rc.net The IP address is passed to the driver, and it negotiates it. At the end of negotiation, it sets the resulting IP into inet code. Address translation : You can use this feature if you like to connect to your ISP, have dynamic address and reconect without reboot Minix. The inet code does not allow you to change the IP on the fly, so you can have a static ip assigned into rc.net, like 10.1.1.1, and use the -t switch, so the driver will translate the local IP to the ISP ip. Here you need to know that some programs like ftp need to use PASSIVE mode, and lynx must be compiled with the option NO_PORT to pass throught the ppp.drv without problems. For automatic logging and configuration, you can use the chat command, please check the chat and modem directory for explanations, examples of scripts and shell commands. For manual conection, you can use kermit or minicom, and you can have the following configuration on the .kermrc file set line /dev/tty01 set speed 38400 Other very usefull command is term: # term 8 38400 /dev/tty01 term is a dumb terminal emulator, but very usefull, check the man page. It is important to have the modem on before booting Minix, because some modems with autobaud send strange caracters and could hangs the tty driver. After dialing with kermit and logged into the ISP, with CTRL \ C returns to kermit and after use the "quit" command to avoid hang the telephone. Now, you should execute the ppp driver to link the system with the ISP: # ppp.drv -b 38400 /dev/tty01 & The driver will print information, if you use authentication, it will present you the message send by the remote peer (generally "Login Ok" or similar), and when it finish negotiation, it will print the "ready" message. You can use the -v (verbose) flag to get more information. If you have problems, you can add the -v and -d switchs to have a lot of information about packet headers, etc, and compile the code with DEBUG. The debugging information is written to standard error, so you can redirect it with 2> to a file. The -v and -d switch combination will give you different levels of debugging, and both switchs are the full information possible. There is other compilation option DEBUGPKT, that dumps the packet contents, but I suggested to use only for learning or if you like to help me into development. -d and -v stops when the driver arrives to the data transfer phase, after negotiation. This allows to debug only the connection. There are a next level of debug. -D and -V flags works equal than -d and -v but continues debugging and dumping packets during all the driver connection. This uses a lot of disk space and system resources. Be carefull. If you need supply an IP address, use the -i switch. The default is to get it from the peer node. The driver will use this IP for negotiation, and if the peer refuses it, it will use the IP that the peer suggest. If you must login to the ISP using PAP or CHAP, you must supply the user and password in the command line. You can use chat to handle the basic modem operations, and after connection, use PAP or CHAP to authenticate. The command is as follows # ppp.drv -b 38400 -u username -p password /dev/tty01 & This command sets the port /dev/tty01 to 38400 baud, and will use PAP or CHAP authentication with peer, using "username" and "password" to login. If the peer needs PAP/CHAP authentication, but you does not supply -u or -p the driver rejects the authentication protocols. The -u and -p switchs enable authentication into the driver. When you connect, the driver shows you the authentication messages that the peer send if you log into the system. Also, you can use the -f [file] and -l [entry] flags using a file specification for PAP or CHAP. The default file is /etc/ppp.auth , and it must have the following #/etc/ppp.auth file isp:user:password the isp is the parameter you pass to the driver, it will lookup for it into the file, and get the user and password necesary to login. This allows you to hidden the ISP account if you issue the ps command. The command now is the following ppp.drv -b 38400 -l isp /dev/tty01 & As the default operation of the driver is passive, it waits until the peer begins sending packets for negotiation. If you supply the -a switch, it fires a timer, and if it did not receive any packets, start the negotiation. You may need to add the -a switch in some ISPs. A brief explanation of switchs is the following (client version): -i IP : allow to set an IP to use as ppart of negotiation. -b baud : set the port to the baud rate.. -a : set active mode, starts negotiiation with peer. -d : enable debugging messages intoo routines. -D : debugging also data packets. -v : enable verbose messages. -V : verbose messages during data packetts also. -u user : allows to supply the username to be used by PAP/CHAP. -p pass : allows to supply the password to be used by PAP/CHAP. -l entry: entry into specification file for PAP/CHAP. -f file : alternate file specification ffor PAP/CHAP -I psip : allows to specify a second psiip device, not the default. -t : translate IP mode. -m : allow to supply a netmask, used onlly without translation mode. -N : allows to modified /etc/resolvv.conf pointing to ISP's DNS. -R : adds a default route from Minix to the PPP peer node. -T N : retransmit timer value in secondds, defaults to 3. -r N : retries for protocols, defaults to 10. -Z : enable negotiation for BSD compresss. When the negotiation process ends, you will see 2 process running ppp.drv with the F1 key, or with command ps. The first one (low pid value) is who reads from peer and send to Minix the IP packets, the other handles the write to peer. During negotiation only the first process is running, and forks the second when ready. This kind of work is very quick to handle full duplex communication. If your ISP supply the DNS, ppp.drv will add the nameserver record automatically. You need to supply the -N flag. Or you can start the DNS daemon by hand with: nonamed -n & or use the /etc/resolv.conf with a line as nameserver Check boot(8) about this configuration. Remember the suggestions before. Some ISP have problems with delay (I have problems with some free ISPs) and you need to change the retransmitions time, you can use the -T flag to use a bigger value than 2 seconds. Also, retry is limited to 10, but you can use other values with -r. If you use more than an interface (ethernet and PPP) the -R flag allows to set a default route to peer, for using it as the default route. Also some ISPs needs this option, or refuse the packets. This option is similar to use the default ISP route in Windows, so you generally need it. After all this steps, you can telnet, ftp, ping or browse the Internet using address or names. The slcp script allows you to enable or disable debug or kill the ppp process. All the information is send to stderr. The kill section also use the chat command to hang the modem. This is the same script used in slip. The script can be called as: slcp d enable debugging messages and verbose output slcp k kill the ppp.drv process and hang-up modem with chat slcp h hang-up the modem using the chat program The chat section of slcp use standard Hayes commands to hang-up the modem, please check your modem manual to verify the commands. You should adapt slcp for your modem and configuration. Remember that each time you make the ppp.drv, it installs also the slcp script. For the correct use of the slcp, you need a file /etc/modem.line that have your specific definitions of your machine. My file have the following commands: TTY=tty01 SPEED=38400 export TTY export SPEED So the scripts execute it, and it is very easy to reconfigure all the scripts with a main configuration file. In the example, tty01 is COM2 in my PC. I recomended you to test previosly the COM port from DOS or Windows to have the rigth idea about how it is working. The tested the driver at different baud rates, but you should be carefull by any negotiation problem related to speed. If you have problems for connecting to your ISP, try with lower rates (like 19200 and 9600 bauds), to know if your ISP have no timing problems. The maximum speed I tested is 115200 bauds, with a 33600 Modem Fax in a serial COM port.