Westermo ID-90 - Manual (Page 61)

Using Multilink PPP
To enable Multilink PPP handling within the ID-90 please enable the B channel protocol ML-
PPP: atb31 or prot = 31.
ML-PPP may be used with different authentification procedures during the call up of the line.
One of these is CHAP. You may enable ML-PPP CHAP by the following steps:
• Type “at**chappwd=<password>” to input your password in the ID-90.
• Type “AT&W” to store the setting in the ID-90.
Afterwards a ML-PPP connection is initially made using CHAP authentification. If the server
does not handle CHAP an automatic fallback to PAP is performed.
Warning: Since the password is shown in plain text it may be disclosed
by unauthorized persons.
Details on Multilink PPP
The following authentication protocols (AP) are supported by ID-90 when running
Multilink PPP (ML-PPP)
• Password Authentication Protocol (PAP)
• Challenge Handshake Authentication Protocol (CHAP) with the variants
• MD5 according to RFC 1321
• Microsoft Chap according to RFC 2433
PAP exchanges the password in clear text format in the B-channel, whereas CHAP encrypts
the password according to the algorithms described in the RFCs mentioned above. Due to
the fact that the password cannot (at least not with reasonable effort) be derived from the
data exchanged on the first link during connection establishment the much safer CHAP
protocol can be used only if the password chappwd is locally stored on the TA.
The following basic rules apply when the TA is configured to run ML-PPP:
1. If the remote side requests (in the Link Control Protocol LCP ConfigRequest) an AP
that the TA can handle, the request is forwarded to local side.
2. If the remote side requests an AP that the TA cannot handle, the TA proposes the safest
protocol depending on its capabilities:
• PAP if no password chappwd is locally stored,
• CHAP MD5 if a password chappwd is locally stored.
This step may be repeated a limited number of times only, if this number exceeds, the
TA falls back to single link operation until the next connection is tried.
3. Once the local side rejects (with a LCP ConfigNak) an AP that was alternatively pro-
posed by the TA (see previous rule), the TA falls back to single link operation until the
next connection is tried. Local and remote side may negotiate any AP they like .
4. At the end of the link setup procedure the negotiated AP is checked and, if supported, is
used for the second link too. If the final AP is not supported the second link is not
established, the TA falls back to single link operation until the next connection is tried.
Note that some hosts are very strict, e.g. if PAP is proposed by the TA due to the lack of a locally stored password chap-
pwd they simply hang up the connection without any chance to negotiate anything else. In these cases the TA should be
configured for single link PPP operation, or, alternatively, the chappwd should be supplied and stored on the TA.
61 6607-2204