10.7.18. El proceso que fuerza una llamada en modo auto nunca funciona

Este es un problema conocido cuando ppp está configurado para negociar una IP dinámica local con el remoto. Cuando ese programa inicial llama a connect(2), el IP del interface tun es asignado al punto final del socket. El kernel crea el primer paquete saliente y establece la conexión. Si, como resultado de la asignación dinámica de IP, la dirección del interface es cambiada, el punto final del socket original será invalido. Los siguientes paquetes enviados al remoto normalmente serán descartados. Aun si no lo son, cualquier respuesta no será enrutada hacia la máquina de origen por que la dirección IP de la máquina de origen ha cambiado.

Hay varias maneras teóricas de solucionar este problema. Lo mejor sería que el remoto reasignase la misma IP si fuese posible :-)

El método más sencillo desde nuestra parte, sería no cambiar nunca la IP del interface tun, pero por el contrario, cambiar todos los paquetes salientes de manera que la ip de origen es cambiada del IP del interface a la IP negociada, instantaneamente. Esto es, esencialmente, lo que hacen libalias(3) y el parámetro -alias de ppp.

Otra alternativa (y probablemente la mas eficaz) es implementar una llamada al sistema que cambie todos los sockets de una IP a otra. Ppp debería usar esta llamada para modificar los sockets de todos los programas existentes cuando una nueva dirección IP es negociada.

Una tercera opción es permitir que un interface se active sin IP. Los paquetes salientes tendrían un IP de 255.255.255.255 hasta que el primer SIOCAIFADDR ioctl este hecho. Esto permitiría que ppp cambiase el IP de origen, pero solo si el socket es 255.255.255.255 y solo el IP y el checksum necesitan cambiar. Esto, de todas maneras, requiere tocar el kernel para que puede enviar paquetes incorrectos a un interface mal configurado.

Ninguna de estas soluciones ha sido implementada (todavía).