--- /dev/null
+#
+# $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 <pete@ohm.york.ac.uk> 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 <pete@ohm.york.ac.uk> 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).
projects / ppp.git / blobdiff