martes, 15 de julio de 2008

Problemas Frecuentes

Al lanzar la conexión miro el /var/log/messages y sólo veo(una vez tras otra):

Apr 15 10:34:08 wanda kernel: ippp0: dialing 0 055...
Apr 15 10:34:08 wanda kernel: ippp0: dialing 1 055...
Apr 15 10:34:08 wanda kernel: ippp0: dialing 2 055...

pero no veo nada más, ¿a qué puede ser debido?

Es un problema físico. Revise la conexión del cable tanto en la tarjeta como en el TR1. Revise la continuidad del cable así mismo. Cámbielo en último término. Asegúrese de que su TR1 tiene servicio... ;-) y Asegúrese de no estar pasando por ninguna centralita.

La conexión se corta tras un mensaje como:

Apr 15 15:58:28 wanda pppd[208]: Could not determine remote IP address

y seguidamente:

Apr 15 15:58:28 wanda pppd[208]: LCP terminated at peer's request
Apr 15 15:58:28 wanda kernel: isdn_net: local hangup ippp0
Apr 15 15:58:28 wanda kernel: ippp0: Chargesum is 0
Apr 15 15:58:28 wanda pppd[208]: Modem hangup
Apr 15 15:58:28 wanda pppd[208]: Connection terminated.

Es un problema bastante común debido a que Infovía (en el supuesto de que la use para conectar) no nos asigna, ---o no lo hace con suficiente rapidez--- una dirección remota del enlace PPP. Hay un solución que funciona tanto en conexiones RDSI como RTC que consiste en pasarle nosotros una dirección en el establecimiento de la conexión. En el caso de conexiones vía RTC (módem corriente y moliente) incluya una línea en el /etc/ppp/options tal que:

:172.16.1.96

y deje el parámetro que le indica que, a pesar de todo, aceptaremos la IP que el extremo nos asigne como remota (ipcp-accept-remote). La IP que pongamos puede ser cualquiera, pero como siempre, y por seguir una regla, ponga una de las que normalmente nos asigna Infovía de su rango (172.16.x.x por ejemplo).

Gracias a Horacio J. Peña por este detalle (el primero al que se lo leimos en la lista del SLUG).

El caso de conexiones vía RDSI (sobre todo en el caso de que usemos el primer método) se puede proceder de la misma forma, pues aunque se le pasen parámetros al (i)pppd, el demonio leerá el fichero /etc/ppp/options.

Al inicializar el demonio ipppd obtengo el mensaje ``Can't find usable ippp device''. ¿A qué es debido?

Según Frank Meyer, del grupo de desarrollo isdn4linux, se debe a que al lanzar el ipppd, este calcula un número aleatorio basándose en la función gethostid() que provoca una resolución DNS, usando para ello el servidor de nombres que aparezca en /etc/resolv.conf.

Si no tenemos la conexión activa, esto lógicamente no es posible y el DNS no puede ser alcanzado (y hablamos en el caso general de que no se disponga de un DNS local, como suele suceder comúnmente).

Para solucionarlo, incluya el nombre de su máquina (incluido localhost) en el /etc/hosts con el dominio completo que haya especificado en /etc/resolv.conf. Hay otra solución basada en un parche no oficial para evitar este comportamiento por parte del ipppd; el fichero syncPPP FAQ incluído en el directorio de documentación de las utilidades ISDN amplía este tema.

No hay comentarios: