ppp/NeXT

#
#  $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).