Previous

Next

PPP Commands

In order for PPP to transition through the PPP states, the following commands are sent:

Configuration-Request

Contains desired options.

Configuration-Ack

Sent in response to a Configuration-Request when all the options listed in the request are acceptable.

Configuration-Nak

Sent in response to a Configuration-Request when one or more of the options are recognized but their values are not acceptable or when additional options are required. If additional options are required, they will be appended to the end of the Configuration-Nak message. If a value was not accepted, an acceptable value will be sent.

Configuration-Reject

Sent in response to a Configuration-Request containing an option or option value which is either unrecognized, not supported or cannot be negotiated.

Terminate-Request

Sent in order to close the PPP connection.

Terminate-Ack

Sent in response to a Terminate-Request.

Code-Reject

Sent in response to an unknown LCP command.

Protocol-Reject

Sent in response to an unknown protocol.

PPP transitions to the next phase after all four of the following events have occurred (not necessarily in this sequence):

• Configuration request has been sent.
• Acknowledgement of the request sent has been received.
• Configuration request has been received.
• Acknowledgement of the received request has been sent.

For each phase, no option will be requested unless the programmer requests it by calling the appropriate API routine (see xn_lcp_want_pap, xn_ipcp_want_address, xn_lcp_want_option, xn_lcp_want_mru, etc.), with remote set to LOCAL_HOST.

Upon receipt of a Configuration-Request, all known options and any value associated with the option will be acceptable unless the programmer explicitly requested otherwise by calling the appropriate PPP API routine. (See xn_lcp_want_pap, xn_ipcp_want_address, etc., with host set to REMOTE_HOST). If requested values (i.e. from remote host in a Configuration-Request and from the application via an API routine) do not match and the option is negotiable, the alternative value requested in the API routine will be negotiated by sending a Configuration-NAK message. A Configuration-NAK response will only be sent a limited number of times, then the option will be rejected. This limitation is configurable (see section PPP Configuration in the RTIP-32 Reference Manual). A Configuration-Reject will be sent if the option is not negotiable or not understood. An option is not negotiable if the appropriate API routine has been called (see xn_lcp_set_option and xn_ipcp_set_option with host set to REMOTE_HOST). In summary, either a Configuration-ACK, Configuration-NAK or Configuration-Reject is sent in response to the receipt of a Configuration-Request.

Likewise, when a Configuration-NAK has been received, the default is to accept the option and any value associated with the option unless the appropriate PPP API routines listed above have been called with host set to LOCAL_HOST. A Configuration-Request is always sent in response to a Configuration-NAK. If the options specified in the Configuration-NAK are acceptable, they and any associated values in the NAK are included in the request. Any non-acceptable options are unchanged from the original request sent.

All options except PAP and CHAP will be dropped and no longer negotiated if a Configuration-Reject is received containing the option. If PAP or CHAP is required as specified by xn_lcp_want_pap or xn_lcp_want_chap, the link will not become established unless one of the options is accepted. If PAP is negotiated, likewise, the connection will not become established unless a valid user name and password is received during the authentication phase. If CHAP is negotiated, the link will not become established unless a valid response to a CHAP challenge is received during the PPP Authentication phase.

PPP

PPP Phases and States

PPP Authentication