Esto no es un problema, aunque su nombre lo parezca. Sólo significa que un temporizador (timer) ha concluido su cuenta. Los temporizadores son una parte necesaria durante la fase de establecimiento del protocolo.
El proceso pppd ha recibido una señal HUP. La señal HUP se genera por
el software que controla el dispositivo tty cuando el dispositivo remoto
al que se estaba conectado ha terminado el enlace a través del módem. Esto
significa que el módem ha colgado ("hang up" en inglés) la conexión. El
programa kill también puede ser usado para enviar esta señal al
proceso pppd. Cuando pppd recibe esta señal, empieza la
secuencia de finalización del enlace de una manera ordenada.
El proceso pppd ha recibido una señal INT. Esta señal la genera el
software que controla la consola cuando se pulsa un CTRL+C y pppd se
está ejecutando como un proceso de segundo plano (background). Igualmente
kill también puede generar esta señal para el proceso pppd. De
hecho, esta es la forma educada de finalizar la ejecución de
pppd y terminar con el enlace. Vea la pregunta referida a dip -k
(pregunta
¿ Existe algún comando similar a dip -k para PPP ?.) para ver un script que realiza esta función. De la
misma manera que con SIGHUP, pppd termina con el enlace de una manera
ordenada.
Unknow protocol (c025) received.El sistema remoto desea utilizar el protocolo Lynk Quality Reporting con su sistema Linux. Este protocolo no está soportado por la versión actual de PPP para Linux. Esto no es un error, sólo indica que el sistema remoto está enviando una invitación a usar este protocolo y Linux le responde con un delicado: "No puedo hacer lo que me pides ahora, asi que no me marees más con esto".
El paquete PPP de Morning Star Software siempre intentará utilizar este protocolo LQP. Esto es normal y no significa que el enlace no pueda realizarse o sea erróneo.
Unknow protocol (80fd) received.El sistema remoto quiere utilizar el protocolo de control de compresión (Compresion Control Protocol) con su sistema Linux. Este protocolo se situa "por encima" del protocolo básico y, si se negocia correctamente, se obtiene una reducción del número de bytes transmitidos en cada trama. O sea, que la transmisión es más rápida.
Sin embargo, existen un buen número de compresores que pueden agruparse
bajo el tármino de Compression Control Protocol. La versión 2.2 del
paquete PPP sólo entiende uno: el compresor BSD. Este compresor funciona
de forma muy parecida a como lo hace el programa compress de UNIX y
utiliza una compresión del tipo LZW. Dependiendo del tamaño del código,
puede ser necesario una gran cantidad de espacio del kernel para
incorporar los diccionarios de compresión y descompresión necesarios. Esto
no debería ser utilizado si su máquina tiene un espacio limitado de
memoria (ni siquiera lo intente si tiene 8 megabytes o menos de RAM
física). Para estos casos, debería adquirir un módem decente que soporte
este tipo de compresión.
A menos que los dos extremos del enlace acepten este tipo de compresión, ésta no se utilizará en la conexión.
Otro tipo común de compresor es Predictor-1. Necesita menos memoria y se ejecuta más rápido. Sin embargo, su compresión no es tan buena como el de BSD, ya que envía unos pocos más de bytes por cada trama.
Muchos servidores de terminal comerciales utilizan un compresor denominado
Stacker(TM) LZW o Protocolo LZS. Este tipo de compresor es comercial y
requiere una licencia de uso. Aparentemente, Stacker le puede dar a usted
esa licencia gratis, pero existe otra licencia más específica que le
impide utilizar este tipo de compresión junto con pppd.
ioctl(TIOCGETD): I/Oerror o ioctl(PPPIOCSINPSIG): I/O error. Examine los mensajes que aparecen cuando arranca el sistema. Si aparece el
mensaje PPP version 0.1.2 es que tiene una versión antigua del driver
PPP.c.
Si aparece PPP version 0.2.7, entonces tiene una versión actualizada
de PPP.c para el paquete 2.1.2. Sin embargo, este fichero no fué
compilado con el mismo conjunto de números de ioctl. Asegurése que sólo
tiene un fichero llamado if_ppp.h. Debería estar situado en el
directorio donde están los ficheros include del kernel de linux. Una vez
hecho esto, vuelva a compilar el kernel y el proceso pppd.
Si aparece PPP version 2.2.0 entonces está usando el driver
correspondiente a la versión 2.2 del paquete. Esta versión del driver solo
funciona con las versiones 2.2 del paquete pppd. El programa
pppd versión 2.2 sólo funcionará con esta versión del driver.
ioctl(PPPIOCGDEBUG): I/O error,ioctl(TIOCSETD): I/O error o ioctl(TIOCNXCL): I/O error.¿ Porqué ocurre esto ?. El sistema remoto ha desconectado el teléfono. Los drivers tty intentan
reestablecer la disciplina de conexión que tenían antes de perder la
línea. A la vez, pppd intenta hacer lo mismo que estos drivers tty
para poder recuperar la conexión. Cuando se produce esta situación es
normal que estos errores aparezcan.
ifconfig me proporciona una información extraña con PPP.Normalmente, ifconfig proporciona una información parecida a esta:
ppp0 Link encap UNSPEC HWaddr 00-00-00-00-00-00-00 ...
inet addr 192.76.32.2 P-t-P 129.67.1.65 Mask 255.255.255.0
UP POINTOPOINT RUNNING MTU 1500 Metric 1
Este mensaje aparece sólo con propósitos informativos. Si usa una versión
reciente del kernel, actualice el paquete nettools por el de
http://sunacm.swan.ac.uk/pub/Linux/networking/nettools.
proc/net/dev parece que esta vacío.¿ Tecleó el comando ls -l /proc/net y se está preguntando cómo
puede ser que tenga un tamaño de 0 bytes ?. Si es así, no se preocupe
porque es normal. En vez de eso teclee:
cat /proc/net/dev
Ahora no debería de estar vacío. El hecho de que la longitud del fichero
sea cero se debe a que se encuentra en un sistema de ficheros del tipo
"proc". De la misma manera, usar more, less o most tampoco
deben usarse para visualizar este fichero. Si quiere un resultado similar
haga
cat /proc/net/dev | less
Esto no es un problema. Este mensaje es el resultado de la llamada que
hace el driver de PPP al procedimiento unregister_netdev. Esta
llamada permite al driver de PPP solicitar dinámicamente el número de
dispositivos que sean necesarios. No hay un límite real sobre el número de
ellos a crear. Por poner un límite, se ha elegido el valor de 256
dispositivos. Si encuentra que este número es pequeño, entonces debe
cambiar el #define que se encuentra en el fichero ppp.c y
poner el valor que desee. Este será el número de dispositivos que serán
cargados dinámicamente.
/proc/net/dev no tiene ningúndispositivo PPP. ¿ Donde están ?. No están en ningún sitio. Fueron desconectados durante el arranque del sistema. Vea la pregunta anterior para más información.