NeXT/README.NeXT

   1 #
   2 #  $Id: README.NeXT,v 1.1 1995/12/18 03:29:54 paulus Exp $
   3 #
   4
   5 This file has been "reset" for ppp-2.2.
   6
   7 ----------------------------------------------------------------------
   8
   9 The NeXT OS does not provide a way of determining the ethernet address
  10 of a particular interface and thus the -proxyarp option to pppd and
  11 this code does not work in quite the way that it would on other
  12 versions. Given an ethernet interface, to find the address for the
  13 code will firstly find the hostname associated with that interface's
  14 IP address. From here it tries 2 methods of obtaining the hardware
  15 address. The first is to look for an entry in the ethernets
  16 database. This can be done by simplay placing a single line in
  17 /etc/ethers with your address and hostname.  The second method used is
  18 to look for the ethernet address in the / netinfo domain. This will
  19 most likely have the ethernet address on systems where a configuration
  20 server is used to boot the client machines. Thus on a large numbver of
  21 systems the code will find the ethernet address without any
  22 modification of /etc/ethers. If for any reason the address as given by
  23 netinfo needs to be overridden then this can be done by placing an
  24 ethry in /etc/ethers which is then used in preference. This code has
  25 been tested on both black and white hardware where it does seem to
  26 work correctly.
  27
  28 Thanks to Pete French <pete@ohm.york.ac.uk> for the code fix.
  29
  30 Status: installed fix.  Proxy-arp works as stated above.
  31
  32 ----------------------------------------------------------------------
  33
  34 The ioctl problems for NS Intel have been reduced. :) A real workaround for
  35 the errors in PPPIOCG* routines is in place.  The ioctl macro is only
  36 used to handle the bad return values.  See ppptioctl() for a
  37 description of the fix.
  38
  39 This fix also fixed the problems encountered when trying to use
  40 multiple interfaces.  Previously, the second interface would steal
  41 from the first.
  42
  43 I have been in contact with NeXT about this bug.  I hope that it
  44 will be fixed in 3.3.  It turns out, after further study, that the
  45 problem only occurred when using the NeXT supplied serial drivers.
  46 The MuX driver worked flawlessly (thanks Mark!).  However, please note
  47 that PPP works with either driver installed.
  48
  49 ----------------------------------------------------------------------
  50
  51 ==============
  52 From ppp-2.1.2
  53 ==============
  54
  55 #
  56 # LKS for NeXT OS
  57 #
  58 # $ORIG: README.NeXT,v 1.2 1994/10/02 19:34:44 perkins Exp $
  59 #
  60
  61 Known Problems:  The following are excerpts from mail messages
  62                   (sometimes concatenations from several people or
  63                    edited).
  64
  65 ----------------------------------------------------------------------
  66
  67 for NS intel:
  68
  69 I wasn't able to get LKSs working with ppp_reloc placed in
  70 /etc/kern_loader.conf at all.  rc.net insisted on setting the
  71 interface flags to UP, and I wasn't able to get it not to by changing
  72 iftab the way I could on black hardware.
  73
  74 Rather than wasting time trying to debug rc.net, I just took ppp_reloc
  75 out of kern_loader.conf and used kl_util from rc.local to load ppp
  76 (which happens after netinfo is up and running, and after rc.net).
  77
  78 If you insist on installing your LKS in /usr/lib/kern_loader/* and
  79 modifying your /etc/kern_loader.conf appropriately, you will want to
  80 add a line like:
  81
  82 ppp*    !false
  83
  84 in /etc/iftab.  Again, note that this approach does not work correctly
  85 on Intel based systems.  The suggested approach is to modify
  86 /etc/rc.local as suggested in the file INSTALL.
  87
  88 Status: Work around by calling rc.ppp from rc.local
  89
  90 -----------------------------------------------------------------------
  91
  92 It seems that some modems, specifically my telebit T3000 take a little
  93 bit of time to initialize after a DTR drop, so if "modem" is set on
  94 the command line, they can [accidentally] drop the first part of the
  95 chat command.  An easy fix is to put delay into the script, or just
  96 change the code in main.c (pppd) to:
  97
  98         if (!default_device && modem) {
  99             setdtr(fd, FALSE);
 100             sleep(1);
 101             setdtr(fd, TRUE);
 102             sleep(2);  /* <-- Give modems time to reinit after DTR drop*/
 103
 104 Also, I am among the many having difficulty getting a SIGHUP when the
 105 peer drops the connection (on the dial out case).
 106
 107 status:  Decided for the time being that this should be added to
 108          the chat script by using the \\d construct.
 109
 110          The SIGHUP problem is addressed in the next release.
 111          A temporary fix is to use the '/bin/csh' instead of the
 112          normal '/bin/sh' in the script that starts pppd.
 113
 114 ----------------------------------------------------------------------
 115 For Proxy-arp, there is a problem in not finding the ether address
 116 correctly. The address is marked as AF_UNSPEC and full of zeroes
 117 rather than being AF_DLI. I don't know quite why as yet.
 118
 119 The bug also occurs under 3.0 systems too. Has anyone at NeXT
 120 commented on this bug?
 121
 122 NeXT does not provide a way of determining the ethernet address of a
 123 particular interface and thus this code does not work in quite the way
 124 that it would on other versions. Given an ethernet interface, to find
 125 the address for the code will firstly find the hostname associated
 126 with that interface's IP address. From here it tries 2 methods of
 127 obtaining the hardware address. The first is to look for an entry in
 128 the ethernets database. This can be done by simplay placing a single
 129 line in /etc/ethers with your address and hostname.  The second method
 130 used is to look for the ethernet address in the / netinfo domain. This
 131 will most likely have the ethernet address on systems where a
 132 configuration server is used to boot the client machines. Thus on a
 133 large numbver of systems the code will find the ethernet address
 134 without any modification of /etc/ethers. If for any reason the address
 135 as given by netinfo needs to be overridden then this can be done by
 136 placing an ethry in /etc/ethers which is then used in preference. This
 137 code has been tested on both black and white hardware where it does
 138 seem to work correctly.
 139
 140 Thanks to Pete French <pete@ohm.york.ac.uk> for the code fix.
 141
 142 Status: installed fix.  Proxy-arp works as stated above.
 143
 144 ----------------------------------------------------------------------
 145
 146 This kernel is known to work on black and white hardware runnign OS
 147 GG3.2. On White hareware if you should run the NeXT supplied serial drivers.
 148 It currently does not work with the MuX driver.  However, we are in
 149 contact with the MuX developers and are working on a solution.
 150
 151   Rumors abound that MuX v1.4 works as long as you undefine
 152   `DOUBLE_BUFFER'.
 153
 154 This has not been thoroughly verified.
 155
 156 ----------------------------------------------------------------------
 157
 158 If you change the LKS_DIR installation directory to something other
 159 than /usr/lib/kern_loader/ppp, you will probably want to change the
 160 default location that pppstats searches.  Do a search for *system and
 161 change the pathname appropriately.
 162
 163 ----------------------------------------------------------------------
 164
 165 For problems, send mail to Steve Perkins (perkins@cps.msu.edu).
 166 Please include your hardware type the LKS version number in all
 167 reports.  This number may be found in the file /usr/adm/messages (once
 168 the LKS has been installed).