Hay un buen número de razones por la que su conexión puede no funcionar - chat no ha conseguido completarse correctamente, usted tiene una línea con mucho ruido, etc. Compruebe su registro de sistema para más indicaciones.
Un problema muy común es que la gente compila el soporte PPP en el núcleo y después, cuando intentan ejecutar pppd, el núcleo se queja diciendo que no soporta ppp. Hay unas cuantas razones por la que esto puede ocurrir.
/etc/lilo.conf y vuelve a ejecutar lilo.Una buena manera de comprobar el núcleo es ejecutando la orden uname
-a, que debería producir una línea como
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
Esto da la versión del núcleo y la fecha en la que el núcleo se compiló - lo cual debería dar una idea clara de qué es lo que sucede.
Si compiló el soporte ppp como módulo, pero no rehizo e instaló los módulos,
puede conseguir este error. Compruebe el Núcleo-COMO y el fichero README en
/usr/src/linux.
Otra posibilidad en este caso es que usted puede esperar que los módulos
requeridos se carguen automáticamente, pero puede no estar ejecutando el
demonio kerneld (que carga y descarga automáticamente módulos en tiempo
real). Lea el kerneld mini-HOWTO para más información acerca de la
configuración de kerneld.
Usted debe utilizar ppp-2.2 o superior con las versiones de núcleo 2.x.x. Puede utilizar ppp-2.2 con la versión de núcleo 1.2.x (si parchea el núcleo). Si no, utilice ppp-2.1.2.
Si no ejecuta pppd como usuario root (y ppd no es su id root) puede recibir este mensaje.
Hay infinitas variaciones sobre esto (eche un vistazo a comp.os.linux...).
Un fallo MUY común es que haya errado al transcribir algo en sus scripts. Lo único que debe hacer aquí es asegurarse de que registra la conversación chat entre su PC Linux y el servidor en el registro de sistema (/var/log/messages) y entonces ir línea por línea examinándolo. Puede que necesite conectarse al servidor ppp manualmente para comprobarlo todo de nuevo.
Debe comprobar el registro de las líneas de órdenes muy cuidadosamente - y tenga en cuenta de que los humanos tenemos la tendencia de leer lo que CREEMOS que hemos escrito - ¡no lo que hemos escrito de veras!
serial line is not 8 bit clean...''
También hay variaciones sobre esto - como serial line looped back,
etc., y la causa puede ser varias cosas.
Para entender qué es lo que pasa es necesario profundizar un poco en qué es lo que sucede tras el proceso de pppd.
Cuando pppd arranca, envía paquetes LCP (protocolo de control de conexión) a la máquina remota. Si recibe una respuesta válida entonces pasa a la siguiente fase (utilizar IPCP - paquetes de protocolo de control de IP) y sólo cuando esa negociación finaliza se inicializa la capa IP de manera que pueda utilizar su conexión PPP.
Si no hay un servidor ppp funcionando al otro lado de la línea cuando su PC envía paquetes lcp, éstos son reflejados por el proceso de entrada en el sistema de la máquina remota. Como estos paquetes utilizan 8 bits, el reflejo corta el octavo bit (recuerde que ASCII es un código de 7 bits). PPP ve esto y se queja de acuerdo con ello.
Hay bastantes razones por las que este reflejo puede ocurrir.
Cuando su script chat finaliza, pppd arranca en su PC. Sin embargo, si no ha completado el proceso de entrada en el sistema (incluyendo el envío de cualquier orden necesaria para arrancar PPP en el servidor), PPP no se iniciará.
Por lo tanto, los paquetes lcp se reflejarán y recibirá este error.
Necesita comprobar cuidadosamente y corregir (si es necesario) su script chat (ver más arriba).
Algunos servidores requieren que introduzca una orden o un retorno de carro tras completar el proceso de entrada en el sistema antes de arrancar ppp.
Compruebe su script chat (ver más arriba).
Si entra en el sistema manualmente y se encuentra con que necesita enviar un retorno de carro para que arranque PPP, simplemente añada un par esperado/enviado en blanco al final de su script chat (una cadena de envío vacía envía realmente un retorno de carro).
Este es algo más raro.
Por defecto, pppd está compilado para enviar un máximo de 10 peticiones de configuración lcp. Si el servidor es un poco lento al arrancar, las 10 peticiones puede ser enviadas antes de que el PPP remoto este listo para recibirlas.
En su máquina, pppd ve las 10 peticiones reflejadas (con el octavo bit eliminado) y finaliza.
Hay dos maneras de evitar esto:-
Añada lcp-max-configure 30 a su fichero de opciones ppp. Esto
incrementa el máximo número de paquetes de configuración lcp que pppd envía
antes de dejarlo. Para un servidor realmente lento, puede que necesite
incluso más que esto.
De manera alternativa, puede trabajar la solución algo más. Se habrá dado cuenta de que cuando se conectó a mano al servidor PPP y PPP arrancó, el ppp era siempre el carácter del gurruño (~).
Utilizando este conocimiento podemos añadir un nuevo par
esperado/enviado al final de nuestro script chat que espere una
tilde y no envíe nada. Esto sería algo como:-
\~ ''
Nota: como el carácter tilde tiene un significado especial en el shell, debe ser mostrado con un carácter de escape (por eso la barra inversa inicial).
Si pppd rehusa a establecer un camino por defecto, esto es porque (bastante correctamente) deniega la eliminación/reemplazo del camino por defecto existente.
La razón más normal de este error es que algunas distribuciones configurar una camino por defecto vía tarjeta Ethernet que es contraria a establecer una ruta específica de red.
Vea el Manual GARL y los COMOs Net2/3 para más información acerca de cómo configurar su tarjeta Ethernet y las rutas asociadas.
Una alternativa a esto es que su red local utilice una pasarela/encaminador y que la tabla de encaminamientos de su PC haya sido configurada para apuntar como camino por defecto a la pasarela.
Solucionar esta última situación requiere algo más de conocimientos IP y queda fuera de los objetivos de este COMO. Le sugiero que obtenga un consejo de alguien más experto (vía foros de noticias o de alguien a quien pueda preguntar).
Hay otras muchas razones aparte de estas por las que ppp no puede conectar y/o funcionar bien.
Lea el PUF PPP (que son realmente una serie de preguntas y respuestas). Es un documento mucho más intuitivo y las respuestas ESTAN allí. Desde mi triste experiencia, si la respuesta a sus problemas no está allí, el problema no es fallo de ppp. En mi caso yo estaba utilizando un núcleo ELF para el que no había actualizado los módulos de núcleo apropiados. Desperdicié sólo 2 días y una casi toda una noche modificando lo que había sido un perfecto servidor PPP antes del ligero error.