Existe actualmente un problema de implementación en ppp en la que no asocia las respuestas LCP, CCP & IPCP con sus peticiones originales. Como resultado, si una implementación ppp es mas lenta durante 6 segundos que la remota, la remota enviará dos peticiones de configuración LCP adicionales. Esto es fatal.
Considera dos implementaciones, A y B. A empieza a enviar peticiones LCP inmediatamente después de conectar y B tarda 7 segundos en arrancar. Cuando B arranca, A ha enviado 3 peticiones LCP. Estamos asumiendo que la línea tiene el ECHO desactivado, si no, veriamos los problemas de "magic number" descritos en el apartado anterior. B envía un REQ, y a continuación envía un ACK al primer REQ de A. Esto resulta en que A entra en modo OPENED y envía un ACK (el primero) a B. Mientras, B devuelve dos ACKs mas en respuesta a los dos REQs adicionales enviados por A antes de que B arrancase .B recibe el primer ACK de A y entra en modo OPENED. A recibe el segundo ACK de B y vuelve al estado REQ-SENT, enviando otro (el cuarto) REQ. Entonces recibe el tercer ACK y entra en modo OPENED. Mientras, B recibe el cuarto REQ de A, produciendo que vuelva de nuevo al estado ACK-SENT y enviando otro (el segundo) REQ y (cuarto) ACK. A recibe el REQ, entra en modo REQ-SENT y envía otro REQ. Inmediatamente recibe el siguiente ACK y entra en OPENED.
Esto pasa hasta que una de las partes piensa que ya ha realizado suficientes reintentos y corta la conexión.
La mejor manera de evitar esto es configurar una de las partes de manera pasiva - que es, hacer que una de las partes espere a que la otra comience la negociación. Esto puede realizarse con el comando:
set openmode passive
Se debe tener cuidado con esta opción. También se puede usar:
set stopped N
para limitar el número de veces que ppp espera a que el remoto comience la negociación. Alternativamente, puedes user el comando:
set openmode active N
donde N es el número de segundos que espera antes de empezar la negociación. Mira en el manual para más detalles.