home *** CD-ROM | disk | FTP | other *** search
/ OpenStep 4.0 (User) / OS_user_4.0.iso / private / etc / ppp / Examples / README.NeXT < prev    next >
Encoding:
Text File  |  1995-07-03  |  7.0 KB  |  169 lines
  1. #
  2. #  $Id: README.NeXT,v 4.2 1995/07/03 18:26:23 perkins 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).
  169.