11.1. | El ppp no funciona. ?Qué estoy haciendo mal? |
Primero deberías leer el man de ppp y la sección de PPP del handbook. Activa los logs con el comando
Este comando debería ser tecleado en el prompt del
ppp o incluirse en el archivo de
configuración
!ppp
y que el archivo Si tu versión de ppp no entiende el comando "set log" deberías bajarte la última versión. Esta compilará sin problemas en FreeBSD 2.1.5 y superiores. | |
11.2. | Ppp se bloquea al ejecutarlo |
Esto ocurre normalmente por que no se puede resolver el nombre
de la máquina. La mejor manera de solucionar este problema
es asegurarse que el sistema use en primer lugar el archivo
127.0.0.1 foo.bar.com foo localhost
Añadir otra línea para la máquina local. Consultar las páginas man relevantes para más detalles. Ahora se debería poder ejecutar el siguiente mandato de
forma satisfactoria | |
11.3. | PPP no quiere marcar en modo -auto |
Primero, asegúrate de tener una ruta por defecto. Ejecutando el comando url="http://www.FreeBSD.org/cgi/man.cgi?netstat"> name="netstat -rn"> deberías ver dos entradas como estas:
Esto es asumiendo que hayas usado las direcciones del manual, la página man o del archivo de ejemplo ppp.conf.sample. Si no tienes una ruta por defecto, puede ser por que estés usando una versión antigua de ppp que no entiende la palabra HISADDR en el archivo ppp.conf. Si tu versión de ppp es de antes de FreeBSD 2.2.5, cambia la línea
add 0 0 HISADDR
por otra diciendo
add 0 0 10.0.0.2
Otra razón para la inexistencia de la ruta por defecto es que
sin darte cuenta hayas creado un default router en el archivo
/etc/rc.conf (anteriormente llamado
delete ALL
en el archivo | |
11.4. | ?Qué significa "No route to host"? |
Este error se debe normalmente a la falta de la sección
en el archivo
Pásate por la sección PPP y direcciones IP dinámicas del handbook para más información. | |
11.5. | Mi conexión se corta pasados 3 minutos |
El timeout de ppp por defecto es de 3 minutos. Se puede ajustar con la línea:
set timeout NNN
Donde NNN es el número de segundos de inactividad antes
de cerrar la conexión. Si NNN es 0, la conexión no
se cerrará nunca por timeout. Es posible poner este comando en
el archivo | |
11.6. | Mi conexión se corta en situaciones de carga |
Si tienes la opción Link Quality Reporting (LQR) configurada es posible que demasiados paquetes LQR se pierdan entre tu máquina y el remoto. PPP deduce que la línea es mala y corta la conexión. En versiones anteriores a la 2.2.5 de FreeBSD, LQR estaba activado por defecto. Ahora está desactivado por defecto. LQR puede ser activado con la línea
disable lqr
| |
11.7. | Mi conexión se corta en periodos aleatorios |
Algunas veces, en líneas telefónicas de baja calidad o con mucho ruido, o líneas con la opción de llamada en espera activada, el módem corta la conexión por que piensa (erróneamente) que ha perdido la portadora. Hay una opción en muchos modems para determiar la tolerancia a pérdidas temporales de portadora. En un USR Sportster por ejemplo, esta es medida por el registro S10 en décimas de segundo. Para hacer que tu módem sea más resistente, puedes añadir la siguiente secuencia "send-expect" a la cadena de llamada:
set dial "...... ATS10=10 OK ......"
Mira en el manual de tu módem para más detalles. | |
11.8. | No ocurre nada después del mensaje Login OK |
En versiones anteriores a FreeBSD 2.2.5, una vez estaba la conexión establecida, ppp espera a que el remoto inicie la negociación LCP (Line Control Protocol). Muchos proveedores de Internet no iniciarán la negociación esperando que sea el cliente el que lo haga. Para forzar al ppp a iniciar el LCP, usa la siguiente línea:
set openmode active
Nota: Normalmente no hay problemas si las dos partes inician la negocioacion LCP, ya que el modo abierto (open mode) está activo por defecto. De todas maneras, la siguiente sección explica cuando pueden haber problemas. | |
11.9. | Sigo teniendo errores sobre el parámetro magic |
Ocasionalmente, justo después de la conexión, puedes ver mensajes en el log referentes a "magic number is the same". Algunas veces, estos mensajes son inofensivos, y otras veces uno de los dos extremos finaliza la conexión. Algunas implementaciones de ppp no pueden solucionar este problema, y, aunque parezca que la conexión está establecida, verás repetidas peticiones y aceptaciones de configuración en el archivo de log hasta que una de las dos partes cierra la conexión. Esto ocurre normalmente en servidores con disco lentos que tienen problemas para gestionar eficientemente los puertos serie. También existen informes de problemas en conexiones mediante slip. La razón es que en el tiempo que tarda el servidor en salir del getty y ejecutar el ppp, el cliente manda los paquetes de inicio LCP. Al estar el ECHO todavía activo en el puerto del servidor, el cliente ppp lo único que ve son sus propios paquetes "reflejados" por el servidor. Una parte de la negociación LCP es establecer un número mágico para cada una de los dos extremos de las conexiones para que los "reflejos" puedan ser detectados. El protocolo dice que cuando el remoto intenta negociar el mismo "magic number", se debe enviar un NAK para seleccionar un nuevo "magic number". Durante el periodo de tiempo que el servidor tiene el ECHO activado en el puerto, el cliente ppp envía paquetes LCP, ve que el mismo "magic" vuelve en el paquete reflejado y lo da como no válido (envia NAK). Este todavía ve el paquete reflajado con NAK (lo que significa que el ppp debe cambiar su "magic"). Esto produce un enorme número de cambios de "magic number" que son introducidos en el buffer tty del servidor. Tan pronto como el ppp arranca en el servidor, es bombardeado con cambios de "magic numbers" e inmediatamente decide que ya ha realizado el número suficiente de negociaciones LCP y corta la conexión. Mientras tanto, el cliente, que ya no ve los paquetes reflejados, recibe sin problemas la desconexión del servidor y también cierra la conexión. Esto puede ser resuelto permitiendo que el remoto inicie la negociación, poniendo la siguiente línea en el archivo ppp.conf:
set openmode passive
Esto indica al ppp que espere a que el servidor comience la negociación LCP. Es posible que algunos servidores nunca inicien la negociación. Si este es el caso, puedes hacer algo como:
set openmode active 3
Esto le indica al ppp que sea pasivo durante 3 segundos, y despues comience a enviar peticiones LCP. Si el remoto envía peticiones durante este periodo, ppp responderá inmediatamente sin esperar los 3 segundos establecidos. | |
11.10. | Las negociaciones LCP continuan hasta que se cierra la conexión |
Existe actualmente un problema de implementación en ppp en la que no asocia las respuestas LCP, CCP & IPCP con sus peticiones originales. Como resultado, si una implementación ppp es más lenta durante 6 segundos que la remota, la remota enviará dos peticiones de configuración LCP adicionales. Esto es fatal. Considera dos implementaciones, A y B. A empieza a enviar peticiones LCP inmediatamente después de conectar y B tarda 7 segundos en arrancar. Cuando B arranca, A ha enviado 3 peticiones LCP. Estamos asumiendo que la línea tiene el ECHO desactivado, si no, veriamos los problemas de "magic number" descritos en el apartado anterior. B envía un REQ, y a continuación envía un ACK al primer REQ de A. Esto resulta en que A entra en modo OPENED y envía un ACK (el primero) a B. Mientras, B devuelve dos ACKs más en respuesta a los dos REQs adicionales enviados por A antes de que B arrancase .B recibe el primer ACK de A y entra en modo OPENED. A recibe el segundo ACK de B y vuelve al estado REQ-SENT, enviando otro (el cuarto) REQ. Entonces recibe el tercer ACK y entra en modo OPENED. Mientras, B recibe el cuarto REQ de A, produciendo que vuelva de nuevo al estado ACK-SENT y enviando otro (el segundo) REQ y (cuarto) ACK. A recibe el REQ, entra en modo REQ-SENT y envía otro REQ. Inmediatamente recibe el siguiente ACK y entra en OPENED. Esto pasa hasta que una de las partes piensa que ya ha realizado suficientes reintentos y corta la conexión. La mejor manera de evitar esto es configurar una de las partes de manera pasiva - que es, hacer que una de las partes espere a que la otra comience la negociación. Esto puede realizarse con el comando:
Se debe tener cuidado con esta opción. También se puede usar:
para limitar el número de veces que ppp espera a que el remoto comience la negociación. Alternativamente, puedes user el comando:
donde N es el número de segundos que espera antes de empezar la negociación. Mira en el manual para más detalles. | |
11.11. | Ppp se bloquea al conectar |
Antes de la versión 2.2.5 era posible que la conexión se corte nada más iniciarse debido a un problema en la negociación de compresión Predictor1. Esto solo pasa si las dos partes intentan negociar con diferentes protocolos de control de compresión (CCP). Este problema ya está corregido, pero si estás usando una versión antigua de ppp, el problema puede solucionarse con la línea
| |
11.12. | Ppp se bloqua al abrir un shell de test |
Cuando ejecutas el comando shell o !, ppp ejecuta un shell (o si has pasado argumentos, ppp ejecutará esos argumentos). Ppp esperará a que se complete el comando antes de continuar. Si intentas usar la conexión ppp mientras se ejecuta el comando, parecerá que la conexión se ha colgado. Esto es por que ppp está esperando a que se complete la ejecución del comando. Si quieres ejecutar comandos como este, usa el comando !bg en su lugar. Esto ejecutará el comando en background, y ppp continúa sin problemas con la conexión. | |
11.13. | Ppp sobre un cable null-modem no funciona |
No hay manera que ppp detecte automáticamente que una conexión directa se ha cortado. Es debido a las líneas que se usan en un cable serie null-modem. Cuando usamos este tipo de conexión, LQR debería estar siempre activada con el comando
enable lqr
LQR es aceptado por defecto si es negociado por el remoto. | |
11.14. | ?Por que llama sin motivo el ppp en modo -auto? |
Si ppp llama inesperadamente, debes determinar la causa, y poner filtros (dfilters) para prevenir esas llamadas. Para determinar la causa, usa la siguiente línea:
set log +tcp/ip
Esto guardara todo el tráfico que pase a través de la conexión. La próxima vez que se realice una llamada no deseada, podrás ver la causa convenientemente guardada. Ahora puedes desactivar las llamadas producidas por esa causa. Usualmente, este tipo de problemas se debe a consultas de DNS. Para prevenir que las consultas de DNS puedan establecer conexiones usa la siguiente línea (esto no hará que los paquetes de DNS queden parados cuando la conexión está establecida):
set dfilter 1 deny udp src eq 53
Esto no siempre es aconsejable, ya que puede afectar a la capacidad de realizar conexiones bajo demanda - muchos programas necesitan hacer una consulta al DNS antes de poder realizar cualquier operación. En el caso del DNS, deberías determinar que es lo que
está intentando realizar esas consultas de DNS. Muchas veces,
sendmail
es el culpable. Debes asegurarte configurar el
sendmail de manera que no realice ninguna consulta al DNS. Mira la
sección Configuracion de correo para
tener más detalles acerca de como crear una archivo propio de
configuración de sendmail. También deberías
añadir la siguiente línea en tu archivo
define(`confDELIVERY_MODE', `d')dnl
Esto hara que sendmail encole todo el correo hasta que no se procese la cola (usualmente, sendmail es invocado con "-bd -q30m", indicandole que procese la cola cada 30 minutos) o hasta que se ejecuta el comando "sendmail -q" (por ejemplo, desde el archivo ppp.linup). | |
11.15. | ?Qué significan estos errores CCP? |
Sigo viendo los siguientes errores en el archivo de log:
CCP: CcpSendConfigReq
Esto es porque ppp está intentando negociar compresión Predictor1, y el remoto no quiere negociar ningún tipo de compresión. Estos mensajes son sin importancia, pero si quieres eliminarlos, puedes desactivar la compresión Predictor1 localmente:
disable pred1
| |
11.16. | PPP se cuelga durante transferencia de archivos con errores I/OP |
En la versión FreeBSD 2.2.2 y anteriores, había un problema en el driver tun que no permitía paquetes entrantes con un tamaño mayor que el MTU del interface. La recepción de un paquete mayor que el MTU resulta en un error IO que es logueado vía syslogd. La especificación PPP dice que un MRU de 1500 siempre debería ser aceptada como mínimo, a pesar de lo que se negocie mediante LCP, de todas maneras, es posible que hayas disminuido el MTU por debajo de 1500 y tu proveedor te esté enviando paquetes de 1500, haciendo que tu conexión se bloquee. El problema puede solucionarse haciendo que el tamaño del MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores. | |
11.17. | ?Por que ppp no loguea la velocidad de la conexión? |
Para loguear todas las líneas de "conversación" de tu módem, debes activar la siguiente opción:
set log +connect
Esto hará que ppp loguee todo hasta la última cadena "expect" pedida. Si quieres ver la velocidad de tu conexión y usas PAP o CHAP (y por lo tanto no tienes nada que "chatear" después del CONNECT en el script de marcado), debes estar seguro de indicarle al ppp que espera la línea "CONNECT con algo como esto:
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
Aquí, tenemos nuestro CONNECT, enviamos nada, y esperamos un salto de línea, forzando al ppp que lea la respuesta del CONNECT. | |
11.18. | Ppp ignora el carácter `\' en mi chat script |
PPP lee cada línea de los archivos de configuración para poder interpretar cadenas como set phone "123 456 789" correctamente. Para especificar un carácter ``"'', debes usar la contrabarra (``\''). Cuando el intérprete lee cada argumento, reinterpreta el argumento para buscar alguna secuencia especial de escape como ``\P'' o ``\T''. Como resultado de esta doble lectura, recuerda que has de usar el número correcto de escapes (contrabarras). Si quieres enviar un caracter ``\'' a tu módem, necesitas hacer algo como:
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
resultando en la siguiente secuencia:
ATZ
o
set phone 1234567
resultando en la siguiente secuencia:
ATZ
| |
11.19. | Ppp produce un seg-fault, pero no veo el archivo
|
Ppp (o cualquier otro programa de este tipo), nunca deberían hacer un core dump. Por que ppp funciona con un id de usuario 0, el sistema operativo no escribirá la imagen del core en disco. Si ppp termina con errores de "segmentation violation" o cualquier otra señal que normalmente causa un core dumped, y quieres poder hacer un debug de ese core, asegúrate de usar la última versión de ppp, y haz lo siguiente:
$ tar xfz ppp-*.src.tar.gz
Ahora tendrás instalada una versión "debuggable" de ppp. Tendrás que ser root para poder ejecutar ppp ya que todos sus privilegios han sido revocados. Cuando arranques ppp, acuerdate del directorio en el que te encuentras. Ahora, cuando ppp recibe una violación de segmentación , creará un archivo core llamado ppp.core. A continuación , deberías hacer lo siguiente:
$ su
Toda esta información puede hacer posible diagnosticar el problema. Si estás familiarizado con gdb, puedes encontrar otras pistas como que causó el dump y las direcciones y valores de las variables más relevantes. | |
11.20. | El proceso que fuerza una llamada en modo auto nunca funciona |
Este es un problema conocido cuando ppp está configurado para negociar una IP dinámica local con el remoto. Este problema ha sido solucionado en la última versión - busca en el man la palabra iface. El problema era que cuando el programa inicial llama a connect(2), el IP del interface tun es asignado al punto final del socket. El kernel crea el primer paquete saliente y establece la conexión. Si, como resultado de la asignación dinámica de IP, la dirección del interface es cambiada, el punto final del socket original será invalido. Los siguientes paquetes enviados al remoto normalmente serán descartados. Aun si no lo son, cualquier respuesta no será enrutada hacia la máquina de origen por que la dirección IP de la máquina de origen ha cambiado. Hay varias maneras teóricas de solucionar este problema. Lo mejor sería que el remoto reasignase la misma IP si fuese posible :-) La versión actual de ppp hace esto, pero otras muchas implementaciones no. El método más sencillo desde nuestra parte,
sería no cambiar nunca la IP del interface tun, pero por el
contrario, cambiar todos los paquetes salientes de manera que la ip de
origen es cambiada del IP del interface a la IP negociada,
instantaneamente.
Esto es, esencialmente, lo que hacen
libalias(3)
y el parámetro Otra alternativa (y probablemente la más eficaz) es implementar una llamada al sistema que cambie todos los sockets de una IP a otra. Ppp debería usar esta llamada para modificar los sockets de todos los programas existentes cuando una nueva dirección IP es negociada. La misma llamada de sistema podría ser usada para clientes dhcp cuando son forzados a rehacer sus sockets. Una tercera opción es permitir que un interface se active sin IP. Los paquetes salientes tendrían un IP de 255.255.255.255 hasta que el primer SIOCAIFADDR ioctl este hecho. Esto permitiría que ppp cambiase el IP de origen, pero solo si el socket es 255.255.255.255 y solo el IP y el checksum necesitan cambiar. Esto, de todas maneras, requiere tocar el kernel para que puede enviar paquetes incorrectos a un interface mal configurado. | |
11.21. | ?Porqué muchos juegos no funcionan con el parámetro -alias? |
La razón por la que muchos de los juegos no funcionan es por que la máquina externa intentará abrir una conexión o enviar paquetes UDP (no solicitados) a la máquina interna. El software "alias" no sabe que esos paquetes debrín enviarse a la máquina interna. Para que las cosas funcionen, asegúrate que la única cosa que está funcionando es el software con el que tienes problemas, entonces ejecuta tcpdump en el interface tun del gateway o ejecuta el log tcp/ip del ppp ("set log +tcp/ip" en el gateway. Cuando arrancas el software que no funciona, deberís ver paquetes que pasan a través del gateway. Cuando algo vuelve del exterior, será rechazado (ese es el problema). Apunta el número de puerto de esos paquetes y cierra el software que no funciona. Haz esto varias veces para comprobar si el número de puerto se repite. Si es así, la siguiente línea en el archivo de configuración del ppp /etc/ppp/ppp.conf hará que las cosas funcionen:
alias port proto internalmachine:port port
donde "proto" puede ser "tcp" o "udp", "internalmachine" es la máquina a la que quieres que los paquetes sean enviados y "port" es el número de puerto de destino de los paquetes. No podrás usar ese software en otras máquinas sin modificar el comando anterior, y ejecutar el software simultaneamente en dos máquinas internas no será posible - después de todo, el mundo exterior está viendo a toda tu red como una sola máquina. Si los números de puertos no se repiten, hay tres opciones más: 1) Desarrollar el soporte en libalias. Ejemplos de estos "casos especiales" los puedes encontrar en /usr/src/lib/libalias/alias_*.c (alias_ftp.c es un buén prototipo). Esto usualmente supone leer ciertos paquetes salientes conocidos, identificando la instrucción que le indica a la máquina exterior que inicie una conexión con la máquina interna en un puerto específico (aleatorio) y configurar un "ruta" en la tabla de alias para que los paquetes siguientes sepan donde ir. Esta es la solución más difícil, pero es la mejor y hará que el software funcione con múltiples máquinas. 2) Usar un proxy. La aplicación debe soportar socks5 por ejemplo, o (como en el caso del "cvsup") debería tener una opción "pasiva" que evita que el remoto intente abrir conexiones con la maquina local. 3) Redireccionar todo el tráfico a la máquina interna usando "alias addr". Esta es la solución más sencilla. | |
11.22. | ?Ha hecho alguien una lista de puertos útiles? |
Todavía no, pero se podría hacer, si hay interés. En cada ejemplo, internal debe ser reemplazado por la dirección IP de la máquina que va a estar jugando.
| |
11.23. | ?Qué son los errores FCS? |
FCS significa Frame Check Sequence. Cada paquete ppp tiene un checksum añadido para asegurar que los datos que se reciben son los datos que han sido enviados. Si el FCS de un paquete entrante es incorrecto, el paquete es rechazado y se incremente el contador HDLC FCS. Los valores de error HDLC se pueden visualizar usando el comando show hdlc. Si tu conexión es mala (o si tu driver serie está rechazando paquetes), verás errores FCS ocasionales. En general no tienes porque preocuparte de ellos. Si tienes un módem externo, asegúrate que el cable está correctamente aislado de interferencias - esto debería erradicar el problema. Si tu conexión se corta tan pronto como has conectado y ves
gran cantidad de errores FCS, puede ser por que ti conexión no
es de 8 bits. Asegúrate de que tu módem no está
usando control de flujo (XON/XOFF) por software. Si tu conexión
de datos debe usar control de flujo por software, usa el
comando Otra razón para ver muchos errores FCS puede ser que el remoto haya dejado de "hablar" PPP. Deberís activar el log asíncrono para determinar si los datos entrantes son de un login o un prompt de shell. Si tienes un prompt de shell en el extremo de la conexión, es posible terminar el ppp sin cortar la conexión usando el comando close clp (usando el comando term podrás conectar de nuevo con el shell de la máquina remota. Si no hay nada en el log que indique por que se ha terminado la conexión, deberís preguntar al administrador del sistema remoto porqué ha terminado la sesión. | |
11.24. | Nada de esto me ayuda - Estoy desesperado ! |
Si todo falla, envía toda la información que puedas, incluyendo los archivos de configuración, como arrancas el ppp, las partes relevantes del archivo de log y la salida del comando netstat -rn (antes y despues de la conexión) a la lista de distribución FreeBSD-questions@FreeBSD.org, a la lista de FreeBSD en castellano o al grupo de news comp.unix.bsd.FreeBSD.misc y alguien te ayudará a solucionar los problemas. |
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>.