/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.
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.
Can't findusable 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.