I have already reported this to comp.protocols.ppp, but I thought I should also mention it here since others may encounter the same problem. My original posting had the title "No response to IPCP ConfReq". The problem was (and is) that the implementation that my ISP uses for PAP does not quite construct the PAP Authorization Acknowledge in accordance with RFC 1334. If you read section 2.2.2 carefully (which my ISP's vendor evidently did not do) you see that although the Message field at the end is optional, the preceding Msg-Length byte is not. So if there's to be no message, you have to have a zero byte at the end (after the 2 byte Length field). It turns out that pppd 2.3.5 insists that this be present and fails the entire authentication if it is not. The fix is in upap.c, in the routine upap_rauthack(). Since at this point, we know we have been authenticated it seemed to me that verifying the Message part was superfluous. So I commented out the return statement that effectively aborts authentication and sends things into a loop of: send PAP Auth Req receive PAP Auth Ack (silently ignored) receive IPCP Conf Req (silently ignored because pppd thinks we're still in the auth phase). This is where my original subject line came from. The change allowed pppd to work with my ISP after weeks of frustration. I finally discovered the problem by recompiling pppd with DEBUGALL which caused a "short packet" message to be printed. I then saw that the routine above was being called with len=0, and the cause of *that* was explained to me by James Carlson, whose book "PPP Design and Debugging" also helped me greatly in my adventure. The irony is that if pppd had not had this "incompatability" and had just worked out of the box, I would know a whole lot less about PPP now. -- David - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [EMAIL PROTECTED]
