NOVELL TECHNICAL INFORMATION DOCUMENT

TITLE:              PTF374.EXE, WAN Links 2.0 Maintenance
DOCUMENT ID:        TID000341
DOCUMENT REVISION:  A
DATE:               01JUL93
ALERT STATUS:       Yellow
INFORMATION TYPE:   Symptom Solution
README FOR:         PTF374.EXE

NOVELL PRODUCT and VERSION:
NetWare MultiProtocol Router PLUS 2.1

ABSTRACT:
PTF 374 is the latest maintenance PTF for WAN Links 2.0.   It is
recommended for all WAN Links 2.0 installations which use PPP as it
includes the latest PPP.LAN.
_________________________________________________________________

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.
_________________________________________________________________

Self-Extracting File Name:  PTF374.EXE

Files Included     Size     Date        Time

  PTF374.TXT          (This File)
     PPP.LAN      71817    4-07-93     10:11a


README for PTF374.EXE
April 21, 1993

SUMMARY
Maintenance PTF for WAN Links; Version 2.0 (ONLY).

It solves the following problems:
- Unable to connect with a WellFleet or Hewlett Packard router.
- Problems relative to a NAT IP Router
- "Attempt to manually create a call using destination record"
- Link PPP failing to load.
- Use of "LCP Discard Request" results in the connection being broken.
- Lack of clocking in back to back testing.
- Protocol rejection.


INSTALLATION INSTRUCTIONS
Copy into the SYS:SYSTEM subdirectory of the Wan Links Router.
Down the server and re-initialize the router.


PROBLEM/SOLUTION DETAIL
The following problems have all been corrected by changes to PPP.LAN:
1.  IP could not establish a PPP connection between a WellFleet or Hewlett
Packard router and MPR.  While attempting the IP connection, LCP
negotiation proceeds as expected.

During IPCP negotiation:
- MPR sends a null config-request which WellFleet acks.
- WellFleet (or HP) then sends a config-request including an IP Address
option.
- MPR 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.
- MPR acks the config-request, but never sends another IPCP config-request
of its own.
- This resulted in a half open IPCP connection.

2.  During LCP negotiation Link/PPP proposes 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 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.  Until the PTF is applied the RS422 support logic in Link/PPP does 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.

However, 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 <record name>
because the database entry references a board/port not currently loaded"

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.

4.  PPP would not load unless the CSL version number and revision letter
exactly matched the version/revision expected by PPP.  PPP 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.
The change will allow the use of updates of CSL including the new CSL which
ship with NetWare for SAA 1.3.  You MUST use PTF 374 if you will be using
WAN Links with NetWare for SAA 1.3 or higher.

5. Diagnostic testing from the remote using "LCP Discard Requests" resulted
in ALL subsequent frames being discarded.

6. Clocking was not provided for users who wanted to test the link with
V.35 null modem cables.

7. PPP has a feature which determines when a protocol not supported by the
remote is being used.  Upon receiving notification of protocol rejection,
PPP no longer attempts to interpret the unsupported protocol.  However, PPP
instead reacted to the notification by no longer attempting to configure
supported protocols as well.

HISTORY
This PTF supersedes the only prior WAN Links PTF, PTF 356.
ÿ