There is currently an implementation mis-feature in ppp where it doesn't associate LCP, CCP & IPCP responses with their original requests. As a result, if one ppp implementation is more than 6 seconds slower than the other side, the other side will send two additional LCP configuration requests. This is fatal.
Consider two implementations, A and B. A starts sending LCP requests immediately after connecting and B takes 7 seconds to start. When B starts, A has sent 3 LCP REQs. We're assuming the line has ECHO switched off, otherwise we'd see magic number problems as described in the previous section. B sends a REQ, then an ACK to the first of A's REQs. This results in A entering the OPENED state and sending and ACK (the first) back to B. In the meantime, B sends back two more ACKs in response to the two additional REQs sent by A before B started up. B then receives the first ACK from A and enters the OPENED state. A receives the second ACK from B and goes back to the REQ-SENT state, sending another (forth) REQ as per the RFC. It then receives the third ACK and enters the OPENED state. In the meantime, B receives the forth REQ from A, resulting in it reverting to the ACK-SENT state and sending another (second) REQ and (forth) ACK as per the RFC. A gets the REQ, goes into REQ-SENT and sends another REQ. It immediately receives the following ACK and enters OPENED.
This goes on 'till one side figures out that they're getting nowhere and gives up.
The best way to avoid this is to configure one side to be passive - that is, make one side wait for the other to start negotiating. This can be done with the
set openmode passive
command. Care should be taken with this option. You should also use the
set stopped N
command to limit the amount of time that ppp waits for the peer to begin negotiations. Alternatively, the
set openmode active N
command (where N is the number of seconds to wait before starting negotiations) can be used. Check the manual page for details.