Capítulo 14. PPP

14.1. No puedo hacer que ppp(8) funcione. ¿Qué estoy haciendo mal?
14.2. ¿Por qué ppp(8) se cuelga cuando lo corro?
14.3. ¿Por qué ppp(8) no marca en modo -auto?
14.4. ¿Qué significa No route to host?
14.5. ¿Por qué mi conexión se corta luego de 3 minutos?
14.6. ¿Por qué mi conexión se corta bajo carga intensiva?
14.7. ¿Por qué mi conexión se corta luego de un intervalo al azar de tiempo?
14.8. ¿Por qué mi conexión se cuelga luego de un intervalo al azar de tiempo?
14.9. El extremo remoto no responde. ¿Qué hago?
14.10. ppp(8) se colgó. ¿Qué puedo hacer?
14.11. Sigo viendo errores acerca de que la magia es la misma. ¿Qué significan?
14.12. Las negociaciones LCP continúan hasta que la conexión se cierre. ¿Cuál es el problema?
14.13. ¿Por qué ppp(8) se bloquea cuando intento probarlo en el shell?
14.14. ¿Por qué ppp(8) sobre un cable de modem nulo nunca termina?
14.15. ¿Por qué ppp(8) marca en modo -auto sin razón?
14.16. ¿Qué significan estos errores de CCP?
14.17. ¿Por qué ppp(8) no escribe en el log mi velocidad de conexión?
14.18. ¿Por qué ppp(8) ignora el carácter \ en mi script de chat?
14.19. ¿Qué son los errores FCS?
14.20. Nada de esto ayuda — ¡Estoy desesperado! ¿Qué puedo hacer?

14.1.

No puedo hacer que ppp(8) funcione. ¿Qué estoy haciendo mal?

Primero, lea ppp(8) y la sección del manual sobre PPP . Para asistir en la solución de problemas, habilite los logs con el siguiente comando:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Este comando debe ser escrito en el indicador de comandos de ppp(8)o puede ser ingresado al inicio de la sección default en /etc/ppp/ppp.conf. Asegurese de que /etc/syslog.conf contenga las líneas mostradas a continuación y que el archivo /var/log/ppp.log exista:

!ppp
*.*        /var/log/ppp.log

Mucho de lo que esta pasando puede verse en el archivo de log. No se preocupe si no tiene sentido dado que puede tener sentido para alguien más.

14.2.

¿Por qué ppp(8) se cuelga cuando lo corro?

Esto suele ser porque le nombre de host no puede resolverse. La mejor manera de arreglar esto es asegurarse de que /etc/hosts sea leído primero asegurando que la línea hosts este listada primero en /etc/host.conf. Luego, agregue una entrada en /etc/hosts para la máquina local. Si no hay una red local, cambie la línea localhost:

127.0.0.1        foo.example.com foo localhost

De otra manera, agregue otra entrada para el host. Consulte las paginas de manual relevantes para más detalles.

Cuando termine, verifique que este comando corra exitosamente: ping -c1 `hostname`.

14.3.

¿Por qué ppp(8) no marca en modo -auto?

En primer lugar, verifique que exista una ruta por defecto. Este comando debería mostrar dos entradas:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

Si una ruta por defecto no se muestra, asegurese de que la línea HISADDR haya sido agregada a /etc/ppp/ppp.conf.

Otra razón para que la línea de la ruta por defecto falte es que se haya añadido una ruta por defecto a /etc/rc.conf y esta línea no este en /etc/ppp/ppp.conf:

delete ALL

Si este es el caso, vuelva a la sección Configuración final del sistema del manual.

14.4.

¿Qué significa No route to host?

Este error suele ocurrir porque la siguiente sección falta en /etc/ppp/ppp.linkup:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Esto solo es necesario para una dirección de IP dinámica o cuando la dirección del gateway por defecto es desconocida. Cuando se usa modo interactivo, puede escribirse lo siguiente luego de entrar en modo de paquetes. El modo de paquetes esta indicado por las letras PPP en mayúscula en la consola:

delete ALL
add 0 0 HISADDR

Vea la sección sobre PPP y direcciones de IP dinámicas del manual para más detalles.

14.5.

¿Por qué mi conexión se corta luego de 3 minutos?

El timeout por defecto de PPP es de 3 minutos. Esto puede ajustarse con la siguiente línea:

set timeout NNN

donde NNN es el número de segundos de inactividad antes que la conexión se cierre. Si NNN es cero, la conexión nunca se cerrara debido a un timeout. Es posible poner este comando en ppp.conf, o escribirlo en la consola en modo interactivo. También es posible ajustarlo en tiempo real mientras las línea esta activa conectandose a el servidor de socket de ppp usando telnet(1) o pppctl(8). Vea la pagina de manual de ppp(8) para más detalles.

14.6.

¿Por qué mi conexión se corta bajo carga intensiva?

Si Link Quality Reporting (LQR) esta configurado, es posible que muchos paquetes LQR se hayan perdido entre el sistema FreeBSD y el peer. ppp(8) deduce que por consiguiente la línea debe estar mal, y se desconecta. LQR esta deshabilitado por defecto y puede habilitarse con la siguiente línea:

enable lqr

14.7.

¿Por qué mi conexión se corta luego de un intervalo al azar de tiempo?

A veces, en una línea de teléfono con mucho ruido, o incluso una línea con llamada en espera habilitada, el modem puede colgar porque incorrectamente piensa que perdió el portador.

Hay un parámetro en la mayoría de los modems para determinar que tan tolerante debe ser a perdidas temporales del portador. Vea el manual del modem para más detalles.

14.8.

¿Por qué mi conexión se cuelga luego de un intervalo al azar de tiempo?

Mucha gente experiencia conexiones que se cuelgan sin explicación aparente. Lo primero es estable que lado de la conexión esta colgado.

Al usar un modem externo, intente usar ping(8) para ver si la luz TD se enciendie cuando se transmiten datos. Si se enciende pero la luz RD no, el problema esta en el otro extremo. Si TD no se enciende, el problema es local. Con un modem interno, use el comando set server en ppp.conf. Cuando el cuelgue ocurra, conéctese a ppp(8) usando pppctl(8). Si la conexión a la red súbitamente revive debido a la actividad en el socket de diagnóstico, o si no se conecta pero debido al comando set socket tiene éxito en tiempo de inicio, el problema es local. Si puede conectarse pero continúan los cuelgues, habilite los logs locales conset log local async y use ping(8) desde otra ventana o terminal para hacer uso del link. El log asincrónico another mostrara los datos siendo transmitidos y recibidos en el link. Si los datos salen pero nunca vuelven, el problema es remoto.

Habiendo establecido si el problema es local o remoto, existen dos posibilidades:

  • Si el problema es remoto, lea la entrada P: 14.9.

  • Si el problema es local, lea la entrada P: 14.10.

14.9.

El extremo remoto no responde. ¿Qué hago?

Puede hacerse muy poco acerca de esto. Muchos ISPs se rehúsan a ayudar a los usuarios que no corran Microsoft® OS. Agregue enable lqr a /etc/ppp/ppp.conf, permitiendo ppp(8) para detectar el fallo o cuelgue remoto. Esta detección es relativamente lenta y por consiguiente no muy útil.

Primero, intente deshabilitar toda la compresión local agregando lo siguiente a la configuración:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Luego reconectese para asegurarse de que esto no hace la diferencia. Si las cosas mejoran o si el problema se soluciona por completo, determine que ajuste hace la diferencia mediante prueba y error. Esta es información útil para el ISP, aunque puede evidenciar que este no es un sistema Microsoft®.

Antes de contactar el ISP, habilite el logueo asincrónico localmente y espere a que la conexión se cuelgue nuevamente. Esto puede usar bastante espacio de disco. La última lectura de datos del puerto puede ser interesante. Usualmente se trata de datos ASCII, y puede incluso describir el problema (Memory fault, Core dumped).

Si el ISP es servicial, deberían poder habilitar logueo en su extremo, luego cuando la siguiente desconexión ocurra, podrían ser capaces de decir porque su extremo tiene un problema.

14.10.

ppp(8) se colgó. ¿Qué puedo hacer?

En este caso, recompile ppp(8) con información de debug, y luego use gdb(1) para obtener un stack trace desde el proceso de ppp que esta parado. Para recompilar la utilidad ppp con información de debug, escriba:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Luego, reinicie ppp y espere a que se cuelgue nuevamente. Cuando la compilación de depuración de ppp se cuelgue, inicie gdb en el proceso que se colgó escribiendo:

# gdb ppp `pgrep ppp`

En la consola de gdb, use los comandos bt o where para obtener un stack trace. Guarde la salida de la sesión de gdb, y separese del proceso que esta corriendo escribiendo quit.

14.11.

Sigo viendo errores acerca de que la magia es la misma. ¿Qué significan?

Ocasionalmente, justo después de conectare, puede haber mensajes en el log que digan Magic is same. A veces, estos mensajes son inofensivos, y a veces un lado u el otro sale. La mayoría de las implementaciones de PPP no pueden sobrevivir a este problema, incluso si el link parace activarse, habrá pedidos de configuración repetidos y reconocimientos de configuración en el archivo de log hasta que ppp(8) eventualmente se rinda y cierre la conexión.

Esto normalemente sucede en maquinas del servidor con discos lentos que lancen una ppp(8) en el puerto y ejectuen ppp(8) desde un script de inicio u otro programa luego de la autenticación. Existen reportes de que esto sucede consistentemente al usar slirp. La razón es que en el tiempo entre que getty(8)salga y ppp(8) inicie, el ppp(8) del lado del cliente comienza a enviar paquetes Line Control Protocol (LCP). Porque ECHO sigue siendo cambiado para el puerto en el servidor, el cliente ppp(8) ve estos paquetes reflejarse de vuelta.

Una parte de la negociación LCP consiste en establecer un numero mágico para cada lado del link de manera que se puedan detectar reflexiones. El protocolo dice que cuando el peer intenta negociar el mismo número mágico, debe enviarse un NAK y se debe elegir un nuevo numero mágico. Durante el período en que el puerto del servidor tiene ECHO prendido, el cliente ppp(8) envía paquetes LCP, ve el mismo numero mágico en el paquete reflejado y le envía un NAK. También ve el reflejado el NAK (lo que también significa que ppp(8) debe cambiar su numero mágico). Esto produce un enorme número de potenciales cambios de números mágicos, todos los cuales se apilan en el buffer del tty del servidor. Tan pronto como ppp(8) inicia en el servidor, se satura de cambios de numero mágico y casi inmediatamente decide que intento lo suficiente negociar LCP y termina. Mientras tanto, el cliente, que ha dejado de ver las reflexiones, se vuelve satisfecho justo a tiempo para ver un cuelgue del servidor.

Esto puede evitarse permitiéndole al peer comenzar la negocación con la siguiente línea en ppp.conf:

set openmode passive

Esto le dice a ppp(8) que espere al que el servidor inicie las negociaciones LCP. Algunos servidor pueden no obstante nunca iniciar las negociaciones. En este caso, intente algo como:

set openmode active 3

Esto le dice a ppp(8) que sea pasivo por 3 segundos, y luego comience a enviar pedidos LCP. Si el peer comienza a enviar pedidos durante este período, ppp(8) responderá inmediatamente en lugar de esperar el período completo de 3 segundos.

14.12.

Las negociaciones LCP continúan hasta que la conexión se cierre. ¿Cuál es el problema?

Eixte actualmente un error de implementación en ppp(8) donde no se asocian las respuesta LCP, CCP & IPCP con sus pedidos originales. Como resultado, si una implementación de PPP es más lenta que la del otro lado por 6 segundos o más, el otro lado enviara dos pedidos de configuración LCP adicionales. Esto es fatal.

Considere dos implementaciones, A y B. A comienza a enviar pedidos LCP inmediatamente luego de conectarse y a B le lleva 7 segundos iniciar. Cuando B inicia, A ha enviado 3 REQs LCP. Asumimos que la línea tiene ECHO desactivado, de otra forma veríamos problemas con los números mágicos como vimos en la sección previa. B envía una REQ, y luego un ACK al primero de los REQs de A. Esto resulta en A entrando al estado OPENED y enviando un ACK (del primero) de vuelta a B. Mientras tanto, B envía de vuelta dos ACKs más en respuesta a las dos REQs adicionales enviadas por A antes de que B haya iniciado. B luego pasa a recibir el primero ACK de A y entra al estado OPENED. A revice el segundo ACK de B y vuelve al estado REQ-SENT, enviando otro REQ (adelantado) de acuerdo con la RFC. Luego recibe el tercer ACK y entra en el estado OPENED. En el entremedio, B recibe el REQ adelantado desde A, resultando en el mismo revirtiendo al estado ACK-SENT y enviando otro (segundo) REQ y ACK (adelantado) de acuerdo con la RFC. A obtiene el REQ, se pone en modoREQ-SENT y envía otra REQ. Inmediatamente recive el siguiente ACK y entra a modo OPENED.

Esto continua hasta que uno de los lados se de cuenta de que no están llegando a ningún lado y termine.

La mejor manera de evitar esto es configurar un lado para ser passive — esto es, hacer que un lado espere al otro para comenzar a negociar. Esto puede hacerse con el siguiente comando:

set openmode passive

Se debe tener cuidado con esta opción. Este comando también puede usarse para limitar la cantidad de tiempo que ppp(8) espera a que el peer comienze las negociaciones.

set stopped N

Alternativamente, el siguiente comando (donde N es el número de segundos a esperar antes de iniciar las negociaciones) puede ser usado:

set openmode active N

Verifique la página de manual para detalles.

14.13.

¿Por qué ppp(8) se bloquea cuando intento probarlo en el shell?

Al usar shell o !, ppp(8) ejecuta un shell o los argumentos pasados. El programa ppp esperara a que el comando se complete antes de continuar. Cualquier intento de usar el link de PPP mientras se correr el comando aparecerá como un link paralizado. Esto es porque ppp(8) espera a que el comando se complete.

Para ejecutar comandos como este, use !bg en su lugar. Esto ejecutara el comando dado en el trasfondo, y ppp(8) puede continuar sirviendo el link.

14.14.

¿Por qué ppp(8) sobre un cable de modem nulo nunca termina?

No hay forma de que ppp(8) automáticamente determine que una conexión directa fue terminada. Esto es debido a que las líneas usadas en el cable de serie de un modem nulo. Al usar este tipo de conexión, LQR siempre debería ser habilitado con la siguiente línea:

enable lqr

LQR es aceptado por defecto si es negociado por el peer.

14.15.

¿Por qué ppp(8) marca en modo -auto sin razón?

Si ppp(8) marca de manera inesperada, determine la causa y ajuste los filtros de marcación para prevenir dicha llamada.

Para determinar la causa, use la próxima línea:

set log +tcp/ip

Esto escribirá un log con todo el trafico de la conexión. La próxima vez que esta línea surja inesperadamente, la razón será logueada con una conveniente estampa temporal a su lado.

Luego, deshabilite el marcado bajo estas circunstancias. Usualmente, este tipo de problema se da debido a las búsquedas de DNS. Para prevenir que las búsquedas de DNS establezcan una conexión (esto no prevendrá que ppp(8) pase los paquetes a través de una conexión establecida), use lo siguiente:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Esto no siempre es aceptable, dado que romperá las capacidades de demanda de marcado. La mayoría de los programas necesitaran una búsqueda de DNS antes de hacer otras cosas relacionadas con la red.

En el caso del DNS, intente determinar que es lo que esta realmente intentando resolver un nombre de host. La mayoría del tiempo, Sendmail es el culpable. Asegúrese de configurar Sendmail para que no realize ninguna búsqueda de DNS en su archivo de configuración. Vea la sección acerca de usar email con una conexión de dialup en el manual de FreeBSD para los detalles. Probablemente también quiera además agregar la siguiente línea a .mc:

define(`confDELIVERY_MODE', `d')dnl

Esto hara que Sendmail encole todo hasta que se corra la cola, usualmente cada 30 minutos, o hasta que se haga sendmail -q, tal vez desde /etc/ppp/ppp.linkup.

14.16.

¿Qué significan estos errores de CCP?

Continuo viendo los siguientes errores en mi archivo de log:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Esto ocurre porque ppp(8) esta intentando negociar compresión Predictor1, pero el peer no quiere negociar compresión en absoluto. Los mensajes son inofensivos, pero pueden ser silenciados deshabilitando la compresión:

disable pred1

14.17.

¿Por qué ppp(8) no escribe en el log mi velocidad de conexión?

Para escribir en el log todas las líneas de la conversación de modem, agregue lo siguiente:

set log +connect

Esto hara que ppp(8) escriba en el log todo hasta la última cadena expect pedida.

Para ver la velocidad de conexión al usar PAP o CHAP, asegúrese de configurar ppp(8) para que espere la línea CONNECT entera, usando algo como esto:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Esto obtiene la línea CONNECT, no envía nada, y luego espera una nueva línea, forzando a ppp(8) a leer toda la respuesta CONNECT.

14.18.

¿Por qué ppp(8) ignora el carácter \ en mi script de chat?

La utilidad ppp parsea cada línea en sus archivos de configuración de manera que pueda interpretar cadenas como set phone "123 456 789" correctamente y darse cuenta de que el número es solo un argumento. Para especificar un carácter ", escapeelo utilizando una barra invertida (\).

Cuando el interprete de chat parsea cada argumento, reinterpreta el argumento para buscar cualquier secuencia de escape especial tales como \P o \T. Como resultado de este doble parsea, recuerde usar el número correcto de escapes.

Para realmente envíar un carácter \, haga algo como:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Esto resultara en la siguiente secuencia:

ATZ
OK
AT\X
OK

Ó:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Esto resultara en la siguiente secuencia:

ATZ
OK
ATDT1234567

14.19.

¿Qué son los errores FCS?

FCS significa Frame Check Secuence (secuencia de verificación de marcos). Cada paquete PPP tiene un checksum asignado para asegurarse que los datos que están siendo recibidos son los datos que se envían. Si el FCS de un paquete entrante es incorrecto, el paquete es tirado y la cuenta de HDLC de FCS se incrementa. Los valores de error de HDLC pueden mostrarse usando el comando show hdlc.

Si el link esta mal o el controlador de serie comienza a desechar paquetes, producirá el error de FCS ocasional. Esto no suele ser algo por lo que valga la pena preocuparse, aunque ralentiza los protocolos de compresión substancialmente.

Si el link se paraliza tan pronto como se conecta y produce ung ran numero de errores de FCS, asegurese de que el modem no este usando control de flujo por software (XON/XOFF). Si el link debe usar control de flujo por software, use set accmap 0x000a0000 para decirle a ppp(8) que escapee los caracteres ^Q y ^S.

Otra razón para tener demasiados errores de FCS puede ser que el extremo remoto haya dejado de comunicarse con PPP. En este caso, habilite el logueo async para determinar si los datos entrantes son de un inicio de sesión o un indicador del shell. Si se trata de un indicador del shell en el textrmo remoto, es posible terminar ppp(8) sin desechar la línea usando close lcp seguido de term) para reconectarse al shell en la máquina remota.

Si nada en el archivo de log indica porque el ink fue terminado, pregúntele al administrador remoto o su ISP porque la sesión termino.

14.20.

Nada de esto ayuda — ¡Estoy desesperado! ¿Qué puedo hacer?

Si todo lo demás falla, envíe los detalles del error, los archivos de configuración, como se esta iniciando ppp(8), las partes reelevantes del archivo de log, y la salida de netstat -rn, antes y después de conectarse, a la lista de correo de preguntas generales de FreeBSD.

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.

Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.