NOVELL TECHNICAL INFORMATION DOCUMENT TITLE: MPR 2.0 / WAN Links 2.0 Maintenance PTF DOCUMENT ID: TID200005 DOCUMENT REVISION: A DATE: 04OCT93 ALERT STATUS: Yellow INFORMATION TYPE: Symptom Solution README FOR: MPR161.EXE NOVELL PRODUCT and VERSION: NetWare MultiProtocol Router 2.0 WAN Links 2.0 ABSTRACT: This is the README file for MPR161 which is a consolidation of all patches and fixes for both MPR 2.0 and WAN Links 2.0. It is separated into 4 parts, each part dealing with one or more of the files included in the MPR161.EXE file. _________________________________________________________________ DISCLAIMER THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION. _________________________________________________________________ SYMPTOM Previous versions of PINSTALL.NLM caused the server to abend when installing MPR 2.0 or WAN Links 2.0 from the B drive. The version of PINSTALL.NLM that is included with this maintenance PTF does not abend the server. PINSTALL.NLM resides on both the diskette labeled MPR-1 (for the MPR 2.0 product) and the diskette labeled WAN-1 (for the WAN Links 2.0 product.) SOLUTION PINSTALL.NLM is loaded and run from the diskette. Therefore, the fix for this symptom is to make a copy of the diskette, copy the new version of PINSTALL.NLM on to the copy diskette and then install from the copy diskette. SYMPTOM On both MPR 2.0 and WAN Links 2.0, previous versions of RIPENH.NLM would crash if LSLENH.NLM was loaded. The version of RIPENH.NLM that is included with this maintenance PTF can test to see if LSLENH.NLM and avoid the interaction with LSLENH.NLM that caused the crash. On both MPR 2.0 and WAN Links 2.0, previous versions of INETCFG.NLM did not allow the configuration of NetFrame drivers. The version of INETCFG.NLM that is included with this maintenance PTF will configure NetFrame drivers. SOLUTION The fix for these symptoms is to copy RIPENH.NLM and INETCFG.NLM to the \SYSTEM directory of the server. SYMPTOM On WAN Links 2.0, using previous versions of PPP.LAN (for PPP connections) the following seven symptoms exist: 1. On WAN Links 2.0, using previous versions of PPP.LAN, IP could not establish a PPP connection between a WellFleet or Hewlett Packard router and WAN Links. While attempting the IP connection, LCP negotiation proceeds as expected. During IPCP negotiation: - WAN Links sends a null config-request which WellFleet acks. - WellFleet (or HP) then sends a config-request including an IP Address option. - WAN Links responds with a config-reject as expected. - Upon receipt of MPR's config-reject, WellFleet issues an IPCP term-ack, then resends a null IPCP config-request. - WAN Links acks the config-request, but never sends another IPCP config-request of its own. - This resulted in a half open IPCP connection. 2. On WAN Links 2.0, using previous versions of PPP.LAN, during LCP negotiation Link/PPP proposes a magic number configuration which is rejected by NAT Routers. Once Link/PPP removes magic number from the configuration request the connection is successfully established. The removal of the magic number from the configuration request causes Link/PPP to ignore the Echo Request Generation parameter (if configured by the end user.) Instead it disables Echo Request Generation which will prevent the detection of a failing remote peer. 3. On WAN Links 2.0, using previous versions of PPP.LAN, PPP would not load unless the CSL version number and revision letter exactly matched the version/revision expected by PPP. PPP.LAN has been changed so that: - The first number must still match that expected. - Numbers to the right of the first number will be noted and if different than expected result (signifying a minor change) in a warning to the system console without loading being impeded. - The letter signifying revision will be ignored. This change will allow the use of updates of CSL including the new CSL which ship with NetWare for SAA 1.3. You MUST use the version of PPP.LAN that is included with this maintenance PTF if you will be using WAN Links 2.0 with NetWare for SAA 1.3 or higher. 4. On WAN Links 2.0, using previous versions of PPP.LAN, diagnostic testing from the remote using "LCP Discard Requests" resulted in ALL subsequent frames being discarded. 5. On WAN Links 2.0, using previous versions of PPP.LAN, clocking was not provided for users who wanted to test the link with V.35 null modem cables. 6. On WAN Links 2.0, using previous versions of PPP.LAN, PPP had a feature which attempted to determine when a protocol not supported by the remote router was being used. Upon receiving notification of protocol rejection, PPP no longer attempts to negotiate the use of the unsupported protocol. 7. On WAN Links 2.0, using previous versions of PPP.LAN, the RS422 support logic in Link/PPP did not properly assert DTR. Link/PPP was developed using a mis-wired version of the Newport Systems RS-422 cable which returned an asserted DSR even though DTR was unasserted. When a correctly wired cable is used all connection attempts fail with a console message similar to the following: "Attempt to manually create a call using destination record because the database entry references a board/port not currently loaded" TROUBLESHOOTING The follow applies only to the symptom #7 above. Both the mis-wired and correctly wired cables have part #826-170-0001). To identify properly wired cables: - Connect a X.21 conversion cable to port one of the RS-422 cable. - Use a ohmmeter at the adapter end (62 pin) of the RS-422 cable to check for continuity between pins 5 and 23 and between pins 2 and 46. If each of the pin pairs are connected, the cable is the new properly wired version. The new cable will work with after application of this PTF. If there is continuity between pin 2 and pin 5 of the 62 pin connector the cable is the old mis-wired version. To correct the cable, pin 12 and pin 30 should be swapped at *each* 37 pin RS-422 connector. Once this is done repeat the tests described above. SOLUTION The fix for these symptoms is to copy PPP.LAN to the \SYSTEM directory of the server. SYMPTOM On WAN Links 2.0, using previous versions of NXAM.NLM and NXDRV.NLM (for X.25 connections): - there was no support for adapter memory above 1M - there was no support system memory above 16M ; there is now support up to 32M - problems occurred when unloading SNMP.NLM SOLUTION The fix for these symptoms is to copy NXAM.NLM and NXDRV.NLM to the \SYSTEM directory of the server. Self-Extracting File Name: MPR161.EXE Revison: A Files Included: Size Date \ MPR161.TXT (This File) PINSTALL.NLM 23431 04-01-93 RIPENH.NLM 3533 12-09-92 INETCFG.NLM 100764 05-06-93 PPP.LAN 71817 04-07-93 NXAM.NLM 44176 03-01-93 NXDRV.NLM 20322 03-01-93 Installation Instructions: PINSTALL.NLM: 1. Make copies of your MPR 2.0 or WAN Links 2.0 diskettes. 2. In the copy diskette labelled MPR-1 (or WAN-1), replace PINSTALL.NLM with the file from MPR161.EXE. 3. Follow the normal installation instructions given in the manual to install MPR or WAN Links. RIPENH.NLM, INETCFG.NLM: Copy RIPENH.NLM and INETCFG.NLM to the \SYSTEM directory of the server. Down and bring the server back up. PPP.LAN: Copy PPP.LAN to the \SYSTEM directory of the server. Down and bring the server back up to re-initialize the router. NXAM.NLM, NXDRV.NLM: Copy NXAM.NLM and NXDRV.NLM to the \SYSTEM directory of the server. Down and bring the server back up to re-initialize the router. Patch History: The INETCFG.NLM in this PTF supersedes the one found in PTF141. The PPP.LAN in this PTF supersedes PTF374. ÿ