# # $Id: README.NeXT,v 1.1 1995/12/18 03:29:54 paulus Exp $ # This file has been "reset" for ppp-2.2. ---------------------------------------------------------------------- The NeXT OS does not provide a way of determining the ethernet address of a particular interface and thus the -proxyarp option to pppd and this code does not work in quite the way that it would on other versions. Given an ethernet interface, to find the address for the code will firstly find the hostname associated with that interface's IP address. From here it tries 2 methods of obtaining the hardware address. The first is to look for an entry in the ethernets database. This can be done by simplay placing a single line in /etc/ethers with your address and hostname. The second method used is to look for the ethernet address in the / netinfo domain. This will most likely have the ethernet address on systems where a configuration server is used to boot the client machines. Thus on a large numbver of systems the code will find the ethernet address without any modification of /etc/ethers. If for any reason the address as given by netinfo needs to be overridden then this can be done by placing an ethry in /etc/ethers which is then used in preference. This code has been tested on both black and white hardware where it does seem to work correctly. Thanks to Pete French for the code fix. Status: installed fix. Proxy-arp works as stated above. ---------------------------------------------------------------------- The ioctl problems for NS Intel have been reduced. :) A real workaround for the errors in PPPIOCG* routines is in place. The ioctl macro is only used to handle the bad return values. See ppptioctl() for a description of the fix. This fix also fixed the problems encountered when trying to use multiple interfaces. Previously, the second interface would steal from the first. I have been in contact with NeXT about this bug. I hope that it will be fixed in 3.3. It turns out, after further study, that the problem only occurred when using the NeXT supplied serial drivers. The MuX driver worked flawlessly (thanks Mark!). However, please note that PPP works with either driver installed. ---------------------------------------------------------------------- ============== From ppp-2.1.2 ============== # # LKS for NeXT OS # # $ORIG: README.NeXT,v 1.2 1994/10/02 19:34:44 perkins Exp $ # Known Problems: The following are excerpts from mail messages (sometimes concatenations from several people or edited). ---------------------------------------------------------------------- for NS intel: I wasn't able to get LKSs working with ppp_reloc placed in /etc/kern_loader.conf at all. rc.net insisted on setting the interface flags to UP, and I wasn't able to get it not to by changing iftab the way I could on black hardware. Rather than wasting time trying to debug rc.net, I just took ppp_reloc out of kern_loader.conf and used kl_util from rc.local to load ppp (which happens after netinfo is up and running, and after rc.net). If you insist on installing your LKS in /usr/lib/kern_loader/* and modifying your /etc/kern_loader.conf appropriately, you will want to add a line like: ppp* !false in /etc/iftab. Again, note that this approach does not work correctly on Intel based systems. The suggested approach is to modify /etc/rc.local as suggested in the file INSTALL. Status: Work around by calling rc.ppp from rc.local ----------------------------------------------------------------------- It seems that some modems, specifically my telebit T3000 take a little bit of time to initialize after a DTR drop, so if "modem" is set on the command line, they can [accidentally] drop the first part of the chat command. An easy fix is to put delay into the script, or just change the code in main.c (pppd) to: if (!default_device && modem) { setdtr(fd, FALSE); sleep(1); setdtr(fd, TRUE); sleep(2); /* <-- Give modems time to reinit after DTR drop*/ Also, I am among the many having difficulty getting a SIGHUP when the peer drops the connection (on the dial out case). status: Decided for the time being that this should be added to the chat script by using the \\d construct. The SIGHUP problem is addressed in the next release. A temporary fix is to use the '/bin/csh' instead of the normal '/bin/sh' in the script that starts pppd. ---------------------------------------------------------------------- For Proxy-arp, there is a problem in not finding the ether address correctly. The address is marked as AF_UNSPEC and full of zeroes rather than being AF_DLI. I don't know quite why as yet. The bug also occurs under 3.0 systems too. Has anyone at NeXT commented on this bug? NeXT does not provide a way of determining the ethernet address of a particular interface and thus this code does not work in quite the way that it would on other versions. Given an ethernet interface, to find the address for the code will firstly find the hostname associated with that interface's IP address. From here it tries 2 methods of obtaining the hardware address. The first is to look for an entry in the ethernets database. This can be done by simplay placing a single line in /etc/ethers with your address and hostname. The second method used is to look for the ethernet address in the / netinfo domain. This will most likely have the ethernet address on systems where a configuration server is used to boot the client machines. Thus on a large numbver of systems the code will find the ethernet address without any modification of /etc/ethers. If for any reason the address as given by netinfo needs to be overridden then this can be done by placing an ethry in /etc/ethers which is then used in preference. This code has been tested on both black and white hardware where it does seem to work correctly. Thanks to Pete French for the code fix. Status: installed fix. Proxy-arp works as stated above. ---------------------------------------------------------------------- This kernel is known to work on black and white hardware runnign OS GG3.2. On White hareware if you should run the NeXT supplied serial drivers. It currently does not work with the MuX driver. However, we are in contact with the MuX developers and are working on a solution. Rumors abound that MuX v1.4 works as long as you undefine `DOUBLE_BUFFER'. This has not been thoroughly verified. ---------------------------------------------------------------------- If you change the LKS_DIR installation directory to something other than /usr/lib/kern_loader/ppp, you will probably want to change the default location that pppstats searches. Do a search for *system and change the pathname appropriately. ---------------------------------------------------------------------- For problems, send mail to Steve Perkins (perkins@cps.msu.edu). Please include your hardware type the LKS version number in all reports. This number may be found in the file /usr/adm/messages (once the LKS has been installed).