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/O error
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
nettools
por el deproc/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ún dispositivo 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.