Scenario 1: Authentication Time OutsPart I

A user calls in to report that his modem won't authenticate successfully. It seems to be stuck at the verifying username and password stage. First, you use the command #debug ppp negotiation to debug the problem.

After debugging the problem, the output in Example 8-1 is produced.

Example 8-1. Output from debug ppp negotiation for Authentication Time OutsPart I

 Mar  2 13:38:46.291: As1 LCP: I CONFREQ [ACKrcvd] id 66 len 14 Mar  2 13:38:46.291: As1 LCP: As1 LCP:    AuthProto PAP (0x0304C023) Mar  2 13:38:46.291: As1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) Mar  2 13:38:46.862: As1 LCP: O CONFNAK [ACKrcvd] id 66 len 9 Mar  2 13:38:46.862: As1 LCP:    AuthProto CHAP (0x0305C22305) Mar  2 13:38:47.394: As1 LCP: I CONFREQ [ACKrcvd] id 67 len 14 Mar  2 13:38:47.394: As1 LCP:    AuthProto PAP (0x0304C023) Mar  2 13:38:47.394: As1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) Mar  2 13:38:47.919: As1 LCP: O CONFNAK [ACKrcvd] id 67 len 9 Mar  2 13:38:47.919: As1 LCP:    AuthProto CHAP (0x0305C22305) Mar  2 13:38:48.488: As1 LCP: I CONFREQ [ACKrcvd] id 68 len 14 Mar  2 13:38:48.488: As1 LCP:    AuthProto PAP (0x0304C023) Mar  2 13:38:48.488: As1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) Mar  2 13:38:48.812: As1 LCP: O CONFNAK [ACKrcvd] id 68 len 9 Mar  2 13:38:48.812: As1 LCP:    AuthProto CHAP (0x0305C22305) 

The output in Example 8-1 continues until the modems disconnect. In this example, the link control protocol (LCP) never completes and does not change to an open state. The client and server must agree on the authentication type (Password Authentication Protocol [PAP], Challenge Handshake Authentication Protocol [CHAP], or Microsoft CHAP [MS CHAP]) before LCP can change to an open state and allow authentication. In this case, the client requests PAP authentication and the server requires CHAP authentication, as shaded in Example 8-2.

Example 8-2. Excerpt of Example 8-1 with CHAP and PAP Commentary

  ! Non-acknowledgment is sent back saying no to PAP and requesting CHAP:  Mar  2 13:38:46.862: As1 LCP: O CONFNAK [ACKrcvd] id 66 len 9 Mar  2 13:38:46.862: As1 LCP:    AuthProto CHAP (0x0305C22305)  ! Request comes in asking to authenticate via PAP:  Mar  2 13:38:47.394: As1 LCP: I CONFREQ [ACKrcvd] id 67 len 14 Mar  2 13:38:47.394: As1 LCP:    AuthProto PAP (0x0304C023) Mar  2 13:38:47.394: As1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) 

The client sends a configuration request to the network access server (NAS) requesting PAP authentication. The NAS sends a non-acknowledgment back to the client that denies PAP authentication and asks for CHAP authentication. The client only knows how to authenticate through PAP and resends its request for PAP authentication. This continues in a loop until a disconnect timer ends the call.

The fix is implemented by making sure that the authentication protocols on both ends are the same. If the service is supposed to authenticate through CHAP, the end user must reconfigure the dial client to use CHAP authentication. If the service is supposed to allow PAP authentication, the router must be reconfigured to accept PAP authentication.

In this case, the service was supposed to accept only CHAP, so the end user reconfigured the dial client and then reconnected.