You are correct, LCP. However the Cisco CPE is *not* offering to do CHAP. 100% sure that CONFACK CHAP is not being sent. It only started happening about three months ago. Only on Telecom Xtra connections. And only in some regions (I would hazard a guess to say it is only happening in the South Island, but would need to look at those who have requested help). I do not believe there is a bug in the Cisco implementation with regard to this. It is doing exactly what it is meant to be doing. What I might do, for your own interest, is send a debug output off-list next time I run into one. -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Nathan Ward Sent: Friday, 30 April 2010 10:10 a.m. To: NZNOG List Subject: Re: [nznog] Xtra BBA Issue with Cisco 877 Hi Philip, Twice in this thread you have talked about the CPE offering CHAP as an authentication in the IPCP 'exchange'. This is strange, because IPCP is an NCP, so does not run until after the Authentication phase. Typically, the authentication protocol to use is negotiated during LCP, which is before the Authentication phase. Perhaps you mean LCP? You've also said that the telecom box attempts to start CHAP. That would certainly be strange behaviour if you had not CONFACKed CHAP as the authentication protocol. Are you sure you are not sending a CONFACK for CHAP? Can you send through some logs showing this? That would be a pretty big bug in the PPP implementation on the far end, and I'd be very surprised if that hadn't been discovered and fixed a very long time ago. I suspect what you are really seeing is the Telecom box CONFREQing for CHAP, and you CONFACK it because CHAP is enabled by default. It may seem strange that Cisco routers CONFACK for CHAP when no CHAP password appears to be configured, however Cisco peers can have different passwords per authenticator - in the challenge message there is a Name field, and Cisco routers look in their internal password database (username <blah> password 0 <blah>) for the appropriate password to use for that CHAP session, matching the presented Name to the username. The CHAP username that is presented by Cisco peers is by default the local hostname. Because the username is known, and the password is not known if it exists until CHAP starts, it isn't entirely unreasonable that CHAP is CONFACKed unless explicitly denied. Generally, most Cisco peers are configured with "ppp chap password <blah>" which avoids needing to know the Name that the authenticator is going to present ahead of time. I guess you might want to file a bug/feature request with Cisco suggesting that CHAP is not CONFACKed unless "ppp authentication chap callin" is used, however that would change default behaviour of the PPP stack, so it might be hard to get done. Anyway, in my view this problem is on the local end of the link, not the Telecom end. I hope that clears up the problem you guys are seeing. Anton, LCP negotiates one authentication protocol to use, prior to the Authentication phase. If Authentication with the negotiated authentication protocol fails, PPP will not go back to LCP to ask for something else, the link will be torn down. Perhaps it would be a good idea to alternately try CHAP and PAP each time the link comes up, but that would be an implementation feature. Also CHAP passwords must be at least 1 character, so it's not possible to configured a blank password. On 30/04/2010, at 8:11 AM, Philip D'Ath wrote: <snip>