home *** CD-ROM | disk | FTP | other *** search
/ Network Support Encyclopedia 96-1 / novell-nsepro-1996-1-cd2.iso / download / netware / mpr161.exe / MPR161.TXT < prev    next >
Text File  |  1993-10-04  |  8KB  |  229 lines
  1.  
  2.               NOVELL TECHNICAL INFORMATION DOCUMENT
  3.  
  4. TITLE:              MPR 2.0 / WAN Links 2.0 Maintenance PTF
  5. DOCUMENT ID:        TID200005
  6. DOCUMENT REVISION:  A
  7. DATE:               04OCT93
  8. ALERT STATUS:       Yellow
  9. INFORMATION TYPE:   Symptom Solution
  10. README FOR:         MPR161.EXE
  11.  
  12. NOVELL PRODUCT and VERSION:
  13. NetWare MultiProtocol Router 2.0
  14. WAN Links 2.0
  15.  
  16. ABSTRACT:
  17. This is the README file for MPR161 which is a consolidation of all patches
  18. and fixes for both MPR 2.0 and WAN Links 2.0.  It is separated into 4
  19. parts, each part dealing with one or more of the files included in the
  20. MPR161.EXE file.
  21. _________________________________________________________________
  22.  
  23. DISCLAIMER
  24. THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL.
  25. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION.
  26. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION
  27. ONLY.  NOVELL MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS
  28. INFORMATION.
  29. _________________________________________________________________
  30.  
  31. SYMPTOM
  32.  
  33. Previous versions of PINSTALL.NLM caused the server to abend when
  34. installing MPR 2.0 or WAN Links 2.0 from the B drive.
  35.  
  36. The version of PINSTALL.NLM that is included with this maintenance PTF does
  37. not abend the server.
  38.  
  39. PINSTALL.NLM resides on both the diskette labeled MPR-1 (for the MPR 2.0
  40. product) and the diskette labeled WAN-1 (for the WAN Links 2.0 product.)
  41.  
  42.  
  43. SOLUTION
  44.  
  45. PINSTALL.NLM is loaded and run from the diskette.  Therefore, the fix for
  46. this symptom is to make a copy of the diskette, copy the new version of
  47. PINSTALL.NLM on to the copy diskette and then install from the copy
  48. diskette.
  49.  
  50.  
  51. SYMPTOM
  52.  
  53. On both MPR 2.0 and WAN Links 2.0, previous versions of RIPENH.NLM would
  54. crash if LSLENH.NLM was loaded.
  55.  
  56. The version of RIPENH.NLM that is included with this maintenance PTF can
  57. test to see if LSLENH.NLM and avoid the interaction with LSLENH.NLM that
  58. caused the crash.
  59.  
  60. On both MPR 2.0 and WAN Links 2.0, previous versions of INETCFG.NLM did not
  61. allow the configuration of NetFrame drivers.
  62.  
  63. The version of INETCFG.NLM that is included with this maintenance PTF will
  64. configure NetFrame drivers.
  65.  
  66.  
  67. SOLUTION
  68.  
  69. The fix for these symptoms is to copy RIPENH.NLM and INETCFG.NLM to the
  70. \SYSTEM directory of the server.
  71.  
  72.  
  73. SYMPTOM
  74.  
  75. On WAN Links 2.0, using previous versions of PPP.LAN (for PPP connections)
  76. the following seven symptoms exist:
  77.  
  78. 1. On WAN Links 2.0, using previous versions of PPP.LAN, IP could not
  79. establish a PPP connection between a WellFleet or Hewlett Packard router
  80. and WAN Links.
  81.  
  82. While attempting the IP connection, LCP negotiation proceeds as expected.
  83.  
  84.  During IPCP negotiation:
  85. - WAN Links sends a null config-request which WellFleet acks.
  86. - WellFleet (or HP) then sends a config-request including an IP Address
  87. option.
  88. - WAN Links responds with a config-reject as expected.
  89. - Upon receipt of MPR's config-reject, WellFleet issues an IPCP term-ack,
  90. then resends a null IPCP config-request.
  91. - WAN Links acks the config-request, but never sends another IPCP
  92. config-request of its own.
  93. - This resulted in a half open IPCP connection.
  94.  
  95. 2. On WAN Links 2.0, using previous versions of PPP.LAN, during LCP
  96. negotiation Link/PPP proposes a magic number configuration which is
  97. rejected by NAT Routers.  Once Link/PPP removes magic number from the
  98. configuration request the connection is successfully established.
  99.  
  100. The removal of the magic number from the configuration request causes
  101. Link/PPP to ignore the Echo Request Generation parameter (if configured by
  102. the end user.)  Instead it disables Echo Request Generation which will
  103. prevent the detection of a failing remote peer.
  104.  
  105. 3. On WAN Links 2.0, using previous versions of PPP.LAN, PPP would not load
  106. unless the CSL version number and revision letter exactly matched the
  107. version/revision expected by PPP.
  108.  
  109. PPP.LAN has been changed so that:
  110. - The first number must still match that expected.
  111. - Numbers to the right of the first number will be noted and if different
  112. than expected result (signifying a minor change) in a warning to the system
  113. console without loading being impeded.
  114. - The letter signifying revision will be ignored.
  115.  
  116. This change will allow the use of updates of CSL including the new CSL
  117. which ship with NetWare for SAA 1.3.  You MUST use the version of PPP.LAN
  118. that is included with this maintenance PTF if you will be using WAN Links
  119. 2.0 with NetWare for SAA 1.3 or higher.
  120.  
  121. 4. On WAN Links 2.0, using previous versions of PPP.LAN, diagnostic testing
  122. from the remote using "LCP Discard Requests" resulted in ALL subsequent
  123. frames being discarded.
  124.  
  125. 5. On WAN Links 2.0, using previous versions of PPP.LAN, clocking was not
  126. provided for users who wanted to test the link with V.35 null modem
  127. cables.
  128.  
  129. 6. On WAN Links 2.0, using previous versions of PPP.LAN, PPP had a feature
  130. which attempted to determine when a protocol not supported by the remote
  131. router was being used.  Upon receiving notification of protocol rejection,
  132. PPP no longer attempts to negotiate the use of the unsupported protocol.
  133.  
  134. 7. On WAN Links 2.0, using previous versions of PPP.LAN,  the RS422 support
  135. logic in Link/PPP did not properly assert DTR.  Link/PPP was developed
  136. using a mis-wired version of the Newport Systems RS-422 cable which
  137. returned an asserted DSR even though DTR was unasserted.
  138.  
  139. When a correctly wired cable is used all connection attempts fail with a
  140. console message similar to the following:
  141.  
  142. "Attempt to manually create a call using destination record <record name>
  143. because the database entry references a board/port not currently loaded"
  144.  
  145.  
  146. TROUBLESHOOTING
  147.  
  148. The follow applies only to the symptom #7 above.
  149.  
  150. Both the mis-wired and correctly wired cables have part #826-170-0001). To
  151. identify properly wired cables:
  152. - Connect a X.21 conversion cable to port one of the RS-422 cable.
  153. - Use a ohmmeter at the adapter end (62 pin) of the RS-422 cable to check
  154. for continuity between pins 5 and 23 and between pins 2 and 46.
  155.  
  156. If each of the pin pairs are connected, the cable is the new properly wired
  157. version.  The new cable will work with after application of this PTF.
  158.  
  159. If there is continuity between pin 2 and pin 5 of the 62 pin connector the
  160. cable is the old mis-wired version.  To correct the cable, pin 12 and pin
  161. 30 should be swapped at *each* 37 pin RS-422 connector.  Once this is done
  162. repeat the tests described above.
  163.  
  164.  
  165. SOLUTION
  166.  
  167. The fix for these symptoms is to copy PPP.LAN to the \SYSTEM directory of
  168. the server.
  169.  
  170.  
  171. SYMPTOM
  172.  
  173. On WAN Links 2.0, using previous versions of NXAM.NLM and NXDRV.NLM (for
  174. X.25 connections):
  175. - there was no support for adapter memory above 1M
  176. - there was no support system memory above 16M ; there is now support up to
  177. 32M
  178. - problems occurred when unloading SNMP.NLM
  179.  
  180.  
  181. SOLUTION
  182.  
  183. The fix for these symptoms is to copy NXAM.NLM and NXDRV.NLM to the \SYSTEM
  184. directory of the server.
  185.  
  186.  
  187. Self-Extracting File Name: MPR161.EXE    Revison: A
  188.  
  189. Files Included:   Size      Date
  190.  
  191. \
  192.   MPR161.TXT            (This File)
  193. PINSTALL.NLM     23431    04-01-93
  194.   RIPENH.NLM      3533    12-09-92
  195.  INETCFG.NLM    100764    05-06-93
  196.      PPP.LAN     71817    04-07-93
  197.     NXAM.NLM     44176    03-01-93
  198.    NXDRV.NLM     20322    03-01-93
  199.  
  200.  
  201. Installation Instructions:
  202.  
  203. PINSTALL.NLM:
  204. 1. Make copies of your MPR 2.0 or WAN Links 2.0 diskettes.
  205. 2. In the copy diskette labelled MPR-1 (or WAN-1), replace PINSTALL.NLM
  206. with the file from MPR161.EXE.
  207. 3. Follow the normal installation instructions given in the manual to
  208. install MPR or WAN Links.
  209.  
  210. RIPENH.NLM, INETCFG.NLM:
  211. Copy RIPENH.NLM and INETCFG.NLM to the \SYSTEM directory of the server. 
  212. Down and bring the server back up.
  213.  
  214. PPP.LAN:
  215. Copy PPP.LAN to the \SYSTEM directory of the server.  Down and bring the
  216. server back up to re-initialize the router.
  217.  
  218. NXAM.NLM, NXDRV.NLM:
  219. Copy NXAM.NLM and NXDRV.NLM to the \SYSTEM directory of the server. Down
  220. and bring the server back up to re-initialize the router.
  221.  
  222.  
  223. Patch History:
  224.  
  225. The INETCFG.NLM in this PTF supersedes the one found in PTF141.
  226.  
  227. The PPP.LAN in this PTF supersedes PTF374.
  228.  
  229.