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 !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 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: | |
14.3. | ¿Por qué ppp(8) no marca en modo |
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 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 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 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 donde | |
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 Habiendo establecido si el problema es local o remoto, existen dos posibilidades: | |
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 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:
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:
En la consola de gdb, use los comandos | |
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 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, 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 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 Alternativamente, el siguiente comando (donde set openmode active Verifique la página de manual para detalles. | |
14.13. | ¿Por qué ppp(8) se bloquea cuando intento probarlo en el shell? |
Al usar Para ejecutar comandos como este, use | |
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 |
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 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 | |
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 |
La utilidad ppp parsea cada línea en sus archivos de configuración de manera que pueda interpretar cadenas como Cuando el interprete de chat parsea cada argumento, reinterpreta el argumento para buscar cualquier secuencia de escape especial tales como Para realmente envíar un carácter 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 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 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 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 |
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>.