CHAP response retransmission (PPPoE)

[n***@gmail.com]

Our box is running ppp 2.4.4-2 being used for PPPoE mode configuration.

Excuse me if this is not right forum for this.

One customer is testing it against other ppp server for PPPoE.

In testing, he is withholding CHAP Success/Failure message,
to test whether CHAP Response is resend or not.

Ques:
1. Does ppp 2.4.4 resends CHAP response ?
2. Which configuration I need to correct, to achieve above ?

thanks.

regards
ng

[James Carlson]

Post by n***@gmail.com
Our box is running ppp 2.4.4-2 being used for PPPoE mode configuration.
Excuse me if this is not right forum for this.
One customer is testing it against other ppp server for PPPoE.
In testing, he is withholding CHAP Success/Failure message,
to test whether CHAP Response is resend or not.
1. Does ppp 2.4.4 resends CHAP response ?
2. Which configuration I need to correct, to achieve above ?

PPP 2.4.4 doesn't retransmit Response messages. Most (all?)
implementations don't do that, because it's common for the authenticator
to move from Authentication phase to Network phase after sending the
CHAP Success message, and thus end up ignoring any subsequent CHAP
Response messages.

Just as RFC 1994 specifies that you can take an LCP Terminate-Request to
mean the same thing as CHAP Failure, you can take any NCP
Configure-Request message from the peer to mean CHAP Success.

(I'm pretty sure there's a book that covers these sorts of detailed
design issues ...)

In general, PPP is intentionally asymmetric, and the burden for
retransmit is on the sender of a request-type message. The design of
CHAP is, in my opinion, a little odd in that context. If I were doing
it, I would have had a CHAP Success-Ack message, if guaranteeing
delivery was important. (Or perhaps have CHAP Result and Result-Ack
messages, to combine Success/Failure.) Doing that would put the burden
of retransmission back where it belongs -- the peer sending
Success/Failure would have to resend if the message was lost.