We just had a Toshiba laptop exhibit this LCP loop problem in 2.0.60 code. The customer resolved it by upgrading the V.90 code for the PCMCIA modem. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- From: Ian Quinn <IanQ@Interconnect.co.nz> To: <usr-tc@lists.xmission.com> Sent: Monday, January 31, 2000 9:50 PM Subject: RE: (usr-tc) Quirky CHAP on 2.0.51

It doesn't look like a CHAP problem - more a LCP negotiation problem.

After

the HARC sends it's CHAP Challenge, it receives another LCP Request from the remote end, effectively restarting the LCP phase.

It's not obvious what's wrong from this end since during the initial set of LCP negotion, there seems to be an LCP Request-Acknowledge eventually negotiated in each direction so both ends should think the LCP state is open and be happy to move on to authenticate.

1. LCP Negotiated Remote Client -> HARC Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2

2. LCP Negotiated HARC -> Remote Client Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df

I'd get a trace from the remote device and see if it receives the outgoing LCP Acknowledge from the HARC. Maybe it's corrupt, lost or just late for some reason forcing the remote client to resend it's LCP config request.

The remote end definately seems to be pushing the HARC back into negotiating LCP after the HARC thinks it's open and has moved on to authenticate.

Also not sure what AUTH_TYPE c2 23 81 is? c2 23 05 is CHAP, c2 23 80 is MS-CHAP (I think)...

Hope this helps (and that I didn't misread this!).

Regards

Ian

...

-----Original Message----- From: Scot Desort [SMTP:scot@njaccess.net] Sent: Tuesday, February 01, 2000 4:12 PM To: usr list Subject: (usr-tc) Quirky CHAP on 2.0.51

Have a few DSP's upgraded to 2.0.51. Just noticed a quirk in CHAP authentication. After LCP is done, and PPP authentication begins, the auth packets do not make it to the Radius server. I have made several test calls, logging both radius info on my Vircom radius server, and PPP packets on the TC. The radius server does not receive any incoming packet. The TC shows the following:

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM bc 93 87 df PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 CALLBACK 06

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REJ CALLBACK 06

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REJ PROTO_COMP AC_COMP MPP_MRRU 05 ea

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM bc 93 87 df

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_NAK AUTH_TYPE c2 23 81

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df

Outgoing PPP Data on interface: slot:4/mod:17 CHAP CHALLENGE 10 a9 8a 81 83 ad dc b9 06 13 f2 bc ad 63 d4 76 28 48 69 50 65 72

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 8b cf 11 8b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REJ PROTO_COMP AC_COMP MPP_MRRU 05 ea

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 8b cf 11 8b

Outgoing PPP Data on interface: slot:4/mod:17 CHAP CHALLENGE 10 50 b8 b1 f5 4d a4 9a d0 e1 c9 af ef 3e 1d 1c 82 48 69 50 65 72

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2

Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_NAK AUTH_TYPE c2 23 05

Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM 8b cf 11 8b

And the process continues until I cancel the connection attempt.

It *will* however sometimes authenticate just fine using CHAP. It always authenticates using PAP. This test call is ISDN. I am about to try the same series of tests using analog dialup.

Anyone else seen this???

-- Scot

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.