diff options
Diffstat (limited to 'es_ES.ISO8859-1/FAQ/network.sgml')
| -rw-r--r-- | es_ES.ISO8859-1/FAQ/network.sgml | 1167 |
1 files changed, 0 insertions, 1167 deletions
diff --git a/es_ES.ISO8859-1/FAQ/network.sgml b/es_ES.ISO8859-1/FAQ/network.sgml deleted file mode 100644 index c64630abaf..0000000000 --- a/es_ES.ISO8859-1/FAQ/network.sgml +++ /dev/null @@ -1,1167 +0,0 @@ -<!-- $FreeBSD$ --> -<!-- The FreeBSD Documentation Spanish Project --> - <sect> - <heading>Networking<label id="networking"></heading> - - <sect1> - <heading>¿Dónde puedo encontrar información sobre "diskless booting"?</heading> - - <p>"Diskless booting" significa que una máquina FreeBSD sea - arrancada sobre una red, y lea los ficheros necesarios de un servidor y no - desde su disco duro. Para más detalles, por favor, lee la - sección <url url="../../handbook/diskless.html" - name="diskless booting del manual"> - - <sect1> - <heading> - ¿Puede una máquina FreeBSD ser usada como router dedicado? - </heading> - - <p>Los estandards de Internet y las buenas prácticas de - ingeniería nos prohiben proveer el forward de paquetes en la - distribución estandard. Aun así, puedes activar esta - opción cambiando la siguiente variable a <tt/YES/ en el fichero - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf" - name="rc.conf">: - - <verb> - gateway_enable=YES # Set to YES if this host will be a gateway - </verb> - - <p>Esta opción pondrá la variable <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?sysctl" name="sysctl"> - <tt/net.inet.ip.forwarding/ a <tt/1/. - - <p>En muchos casos también necesitarás ejecutar un proceso - de rutado para indicar la existencia en la red de tu router; FreeBSD - incluye el daemon estandard de rutado BSD - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?routed" name="routed"> - , aunque en situaciones más complejas quizás quieras usar - <em/GaTeD/ disponible por ftp en <tt/ftp.gated.Merit.EDU/. - - <p>Es nuestro deber advertirte que estando FreeBSD configurado de esta - manera, no cumple completamente con todos los estandares de routers - de Internet, pero es suficiente para uso ordinario. - - <sect1> - <heading>¿Puedo conectar mi Win95 con Internet a través de FreeBSD?</heading> - - <p>Típicamente, la gente que pregunta esto tiene dos pc's en casa, - uno con FreeBSD y otro con Win95; la idea es usar FreeBSD para conectar - a Internet y luego ser capaz de acceder a Internet desde el - ordenador con Windows 95. Este es realmente un caso especial de la - pregunta anterior. - - <p>Hay un útil documento disponible que explica como configurar - FreeBSD como un - <url url="http://www.ssimicro.com/~jeremyc/ppp.html" - name="Router PPP"> - - <p><bf/NOTA:/ Esto requiere, al menos, tener dos direcciones IP - fijas disponibles, y posiblemente tres o más, dependiendo del - número de máquinas que quieras conectar. Como alternativa, - si no tienes una dirección IP fija, puedes usar una de las subredes - privadas e instalar un proxy como - <url url="http://squid.nlanr.net/Squid/" name="SQUID"> - y <url url="http://www.tis.com/" name="The TIS firewall toolkit"> - en tu FreeBSD. - - <p>Mira también la sección <ref id="direct-at" name="natd">. - - <sect1> - <heading> - ¿Por que falla la compilación del último BIND del ISC? - </heading> - - <p>Hay un conflicto entre el fichero <tt/cdefs.h/ incluido en la - distribución de BIND y el distribuido con FreeBSD. Solo tienes que - borrar <tt>compat/include/sys/cdefs.h</tt>. - - <sect1> - <heading>¿Soporta FreeBSD SLIP y PPP?</heading> - - <p>Sí. Mira las paginas man de - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?slattach" - name="slattach">, <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?sliplogin" name="sliplogin">, - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?pppd" name="pppd"> y - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp">. - <tt/pppd/ y <tt/ppp/ soportan conexiones entrantes y salientes. - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?sliplogin" - name="Sliplogin"> trabaja exclusivamente con conexiones entrantes y - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?slattach" - name="slattach"> con conexiones salientes. - - <p>Estos programas son descritos en las siguientes secciones del - <url url="../../handbook/index.html" name="manual">: - - <itemize> - <item><url url="../../handbook/slips.html" - name="Handbook entry on SLIP (server side)"> - - <item><url url="../../handbook/slipc.html" - name="Handbook entry on SLIP (client side)"> - - <item><url url="../../handbook/ppp.html" - name="Handbook entry on PPP (kernel version)"> - - <item><url url="../../handbook/ppp-and-slip.html#USERPPP" - name="Handbook entry on PPP (user-mode version)"> - </itemize> - - <p>Si solo tienes acceso a Internet a traves de un "shell - account", quizás quieras mirar el package <htmlurl - url="http://www.FreeBSD.org/cgi/ports.cgi?^slirp" name="slirp">. - Puede darte un (limitado) acceso a servicios como ftp y http. - - <sect1> - <heading> - ¿Soporta FreeBSD NAT o Masquerading?<label id="natd"> - </heading> - - <p>Si tienes una red local (una o más máquinas), pero solo - se te ha asignado una única dirección IP desde tu proveedor - de Internet (o si recibes las direcciones de manera dinámica), te - interesa mirar el programa - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?natd" name="natd">. - <tt/Natd/ te permite conectar una red entera a Internet usando - solamente una dirección IP. - - <p>El programa - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp"> - tiene una funcionalidad similar incluida, a través del - parámetro -alias. La <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?libalias" name="librería - alias"> es usada en ambos casos. - - - <sect1> - <heading> - El ppp no funciona. ¿Qué estoy haciendo mal?<label id="userppp"> - </heading> - - <p>Primero deberías leer el <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="man de ppp"> y - la <url url="../../handbook/ppp-and-slip.html#USERPPP" - name="sección de PPP del handbook">. Activa los logs con el - comando - - <verb> - set log Phase Chat Connect Carrier lcp ipcp ccp command - </verb> - - <p>Este comando debería ser tecleado en el prompt del <bf/ppp/ o - incluirse en el fichero de configuración <tt>/etc/ppp/ppp.conf</tt> - (al inicio de la sección <bf>default</bf> es el mejor lugar). - Asegurate que el fichero - url="http://www.FreeBSD.org/cgi/man.cgi?syslog.conf" - name="/etc/syslog.conf"> contiene las siguientes líneas: - - <verb> - !ppp - *.* /var/log/ppp.log - </verb> - - <p>y que el fichero <tt>/var/log/ppp.log</tt> existe. Puedes - encontrar mucha información sobre lo que está pasando en las - conexiones con el fichero de log. - - <p>Si tu versión de ppp no entiende el comando "set log" - deberías bajarte la - <url url="http://www.FreeBSD.org/~brian" name="última - versión">. Esta compilará sin problemas en FreeBSD 2.1.5 y - superiores. - - <sect2> - <heading>PPP no quiere marcar en modo -auto</heading> - - <p>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: - - <verb> -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 - </verb> - - <p>Esto es asumiendo que hayas usado las direcciones del manual, - la página man o del fichero de ejemplo ppp.conf.sample. Si no - tienes una ruta por defecto, puede ser por que estés usando una - versión antigua de <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp"> que no - entiende la palabra <tt/HISADDR/ en el fichero ppp.conf. Si - tu versión de <bf/ppp/ es de antes de FreeBSD 2.2.5, cambia la - línea - - <verb> - add 0 0 HISADDR - </verb> - - <p>por otra diciendo - - <verb> - add 0 0 10.0.0.2 - </verb> - - <p>Otra razón para la inexistencia de la ruta por defecto es que - sin darte cuenta hayas creado un default router en el fichero - /etc/rc.conf (anteriormente llamado <tt>/etc/sysconfig</tt>) y - hayas omitido la línea - - <verb> - delete ALL - </verb> - - <p>en el fichero <tt>ppp.conf</tt>. Si es este el caso vuelve a la - sección - <url url="../../handbook/ppp-and-slip.html#USERPPP-FINAL.html" - name="configuración final del sistema"> en el handbook. - - <sect2> - <heading>¿Qué significa "No route to host"?</heading> - - <p>Este error se debe normalmente a la falta de la sección - - <verb> - MYADDR: - delete ALL - add 0 0 HISADDR - </verb> - - <p>en el fichero <tt>/etc/ppp/ppp.linkup</tt>. Esto es solo - necesario si tienes una direccion IP dinámica o no sabes la - dirección de tu gateway. Si estás usando el modo - interactivo, puedes teclear lo siguiente despues de entrar en - <tt/packet mode/: - - <verb> - delete ALL - add 0 0 HISADDR - </verb> - - <p>Pásate por la sección - <url url="../../handbook/ppp-and-slip.html#USERPPP-DYNAMICIP" - name="PPP y direcciones IP dinámicas"> del handbook para - más información. - - <sect2> - <heading>Mi conexión se corta pasados 3 minutos</heading> - - <p>El timeout de ppp por defecto es de 3 minutos. Se puede ajustar - con la línea: - - <verb> - set timeout NNN - </verb> - - <p>Donde <bf/NNN/ es el número de segundos de inactividad antes - de cerrar la conexión. Si <bf/NNN/ es 0, la conexión no - se cerrará nunca por timeout. Es posible poner este comando en - el fichero <tt>ppp.conf</tt>, o teclearla en el prompt del modo - interactivo. - También es posible ajustarla en cualquier momento mientras la - conexión esté activa conectando al socket del servidor - <bf/ppp/ usando - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?telnet" name="telnet"> - o <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?pppctl" - name="pppctl">. Leete el man de - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp"> - para más detalles. - - <sect2> - <heading>Mi conexión se corta en situaciones de carga</heading> - - <p>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 - - <verb> - disable lqr - </verb> - - <sect2> - <heading>Mi conexión se corta en periodos aleatorios</heading> - - <p>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. - - <p>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: - - <verb> - set dial "...... ATS10=10 OK ......" - </verb> - - <p>Mira en el manual de tu módem para más detalles. - - <sect2> - <heading>No ocurre nada después del mensaje Login OK</heading> - - <p>En versiones anteriores a FreeBSD 2.2.5, una vez estaba la - conexión establecida, - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" - name="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 <bf/ppp/ a iniciar el LCP, usa la - siguiente línea: - - <verb> - set openmode active - </verb> - - <p><bf/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. - - <sect2> - <heading>Sigo teniendo errores sobre el parámetro magic</heading> - - <p>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 fichero de log hasta que una de las dos - partes cierra la conexión. - - <p>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. - - <p>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. - - <p>Esto puede ser resuelto permitiendo que el remoto inicie la - negociación, poniendo la siguiente línea en el fichero - ppp.conf: - - <verb> - set openmode passive - </verb> - - <p>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: - - <verb> - set openmode active 3 - </verb> - - <p>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. - - <sect2> - <heading> - Las negociaciones LCP continuan hasta que se cierra la conexión</heading> - - <p>Existe actualmente un problema de implementación en <bf/ppp/ - en la que no asocia las respuestas LCP, CCP & IPCP con sus - peticiones originales. Como resultado, si una implementación - <bf/ppp/ es mas lenta durante 6 segundos que la remota, la remota - enviará dos peticiones de configuración LCP adicionales. - Esto es fatal. - - <p>Considera dos implementaciones, <bf/A/ y <bf/B/. <bf/A/ empieza - a enviar peticiones LCP inmediatamente después de conectar y - <bf/B/ tarda 7 segundos en arrancar. Cuando <bf/B/ arranca, <bf/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. <bf/B/ envía un REQ, y a - continuación envía un ACK al primer REQ de <bf/A/. Esto - resulta en que <bf/A/ entra en modo <bf/OPENED/ y envía un ACK - (el primero) a <bf/B/. Mientras, <bf/B/ devuelve dos ACKs mas en - respuesta a los dos REQs adicionales enviados por <bf/A/ antes de que - <bf/B/ arrancase .<bf/B/ recibe el primer ACK de <bf/A/ y entra en modo - <bf/OPENED/. - <bf/A/ recibe el segundo ACK de <bf/B/ y vuelve al estado - <bf/REQ-SENT/, enviando otro (el cuarto) REQ. Entonces recibe el - tercer ACK y entra en modo <bf/OPENED/. Mientras, <bf/B/ recibe el - cuarto REQ de <bf/A/, produciendo que vuelva de nuevo al estado - <bf/ACK-SENT/ y enviando otro (el segundo) REQ y (cuarto) ACK. <bf/A/ - recibe el REQ, entra en modo <bf/REQ-SENT/ y envía otro REQ. - Inmediatamente recibe el siguiente ACK y entra en <bf/OPENED/. - - <p>Esto pasa hasta que una de las partes piensa que ya ha realizado - suficientes reintentos y corta la conexión. - - <p>La mejor manera de evitar esto es configurar una de las partes - de manera <bf/pasiva/ - que es, hacer que una de las partes espere - a que la otra comience la negociación. Esto puede realizarse - con el comando: - - <verb> - set openmode passive - </verb> - - Se debe tener cuidado con esta opción. También se puede - usar: - - <verb> - set stopped N - </verb> - - para limitar el número de veces que <bf/ppp/ espera a que el - remoto comience la negociación. Alternativamente, puedes user - el comando: - - <verb> - set openmode active N - </verb> - - donde <bf/N/ es el número de segundos que espera antes de empezar - la negociación. Mira en el manual para más detalles. - - <sect2> - <heading>Ppp se bloquea al conectar</heading> - - <p>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 <bf/ppp/, el problema puede solucionarse - con la línea - - <verb> - disable pred1 - </verb> - - <sect2> - <heading>Ppp se bloqua al abrir un shell de test</heading> - - <p>Cuando ejecutas el comando <tt/shell/ o <tt/!/, <bf/ppp/ ejecuta - un shell (o si has pasado argumentos, <bf/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 <bf/ppp/ está esperando a que se complete la - ejecución del comando. - - <p>Si quieres ejecutar comandos como este, usa el comando <tt/!bg/ en - su lugar. Esto ejecutará el comando en background, y ppp - continúa sin problemas con la conexión. - - <sect2> - <heading>Ppp sobre un cable null-modem no funciona</heading> - - <p>No hay manera que <bf/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 - - <verb> - enable lqr - </verb> - - <p>LQR es aceptado por defecto si es negociado por el remoto. - - <sect2> - <heading>¿Por que llama sin motivo el ppp en modo -auto?</heading> - - <p>Si <bf/ppp/ llama inesperadamente, debes determinar la causa, y - poner filtros (dfilters) para prevenir esas llamadas. - - <p>Para determinar la causa, usa la siguiente línea: - - <verb> - set log +tcp/ip - </verb> - - <p>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. - - <p>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): - - <verb> - set dfilter 1 deny udp src eq 53 - set dfilter 2 deny udp dst eq 53 - set dfilter 3 permit 0/0 0/0 - </verb> - - <p>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. - - <p>En el caso del DNS, deberías determinar que es lo que - está intentando realizar esas consultas de DNS. Muchas veces, - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?sendmail" - name="sendmail"> es el culpable. Debes asegurarte configurar el - sendmail de manera que no realice ninguna consulta al DNS. Mira la - sección <ref id="ispmail" name="Configuracion de correo"> para - tener más detalles acerca de como crear una fichero propio de - configuración de sendmail. También deberías - añadir la siguiente línea en tu fichero <bf/.mc/: - - <verb> - define(`confDELIVERY_MODE', `d')dnl - </verb> - - <p>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 fichero ppp.linup). - - <sect2> - <heading>¿Qué significan estos errores CCP?</heading> - - <p>Sigo viendo los siguientes errores en el fichero de log: - - <verb> - CCP: CcpSendConfigReq - CCP: Received Terminate Ack (1) state = Req-Sent (6) - </verb> - - <p>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: - - <verb> - disable pred1 - </verb> - - <sect2> - <heading>PPP se cuelga durante transferencia de ficheros con errores I/OP</heading> - - <p>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. - - <p>La especificación PPP dice que un MRU de 1500 <bf>siempre</bf> - 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. - - <p>El problema puede solucionarse haciendo que el tamaño del - MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores. - - <sect2> - <heading>¿Por que ppp no loguea la velocidad de la conexión?</heading> - - <p>Para loguear todas las líneas de "conversación" de tu - módem, debes activar la siguiente opción: - - <verb> - set log +connect - </verb> - - <p>Esto hará que - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp"> - loguee todo hasta la última cadena "expect" pedida. - - <p>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: - - <verb> - set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" - </verb> - - <p>Aquí, tenemos nuestro CONNECT, enviamos nada, y esperamos un - salto de línea, forzando al <bf/ppp/ que lea la respuesta del - CONNECT. - - <sect2> - <heading>Ppp ignora el carácter `\' en mi chat script</heading> - - <p>PPP lee cada línea de los ficheros de configuración - para poder interpretar cadenas como <tt/set phone "123 456 789"/ - correctamente. - Para especificar un carácter ``"'', debes usar la contrabarra - (``\''). - - <p>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). - - <p>Si quieres enviar un caracter ``\'' a tu módem, necesitas - hacer algo como: - - <verb> - set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" - </verb> - - <p>resultando en la siguiente secuencia: - - <verb> - ATZ - OK - AT\X - OK - </verb> - - <p>o - - <verb> - set phone 1234567 - set dial "\"\" ATZ OK ATDT\\T" - </verb> - - <p>resultando en la siguiente secuencia: - - <verb> - ATZ - OK - ATDT1234567 - </verb> - - <sect2> - <heading>Ppp produce un seg-fault, pero no veo el fichero <tt/ppp.core/</heading> - - <p>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: - - <verb> - $ tar xfz ppp-*.src.tar.gz - $ cd ppp*/ppp - $ echo STRIP= >>Makefile - $ echo CFLAGS+=-g >>Makefile - $ make clean all - $ su - # make install - # chmod 555 /usr/sbin/ppp - </verb> - - <p>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. - - <p>Ahora, cuando ppp recibe una violación de segmentación - , creará un fichero core llamado ppp.core. A continuación - , deberías hacer lo siguiente: - - <verb> - $ su - # gdb /usr/sbin/ppp ppp.core - (gdb) bt - ..... - (gdb) f 0 - ..... - (gdb) i args - ..... - (gdb) l - ..... - </verb> - - <p>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. - - <sect2> - <heading> - El proceso que fuerza una llamada en modo auto nunca funciona - </heading> - - <p>Este es un problema conocido cuando <bf/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 <bf/iface/. - - - <p>El problema era que cuando el programa inicial llama a - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?connect" - name="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. - - <p>Hay varias maneras teóricas de solucionar este problema. Lo - mejor sería que el remoto reasignase la misma IP si fuese - posible <tt/:-)/ La versión actual de <bf/ppp/ hace esto, - pero otras muchas implementaciones no. - - <p>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 - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?libalias" - name="libalias(3)"> y el parámetro <bf/-alias/ de ppp. - - <p>Otra alternativa (y probablemente la mas eficaz) es implementar - una llamada al sistema que cambie todos los sockets de una IP a - otra. <bf/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. - - <p>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. - - <sect2> - <heading>¿Porqué muchos juegos no funcionan con el - parámetro -alias?</heading> - - <p>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. - - <p>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. - - <p>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 fichero de configuración del ppp - /etc/ppp/ppp.conf hará que las cosas funcionen: - - <verb> - alias port proto internalmachine:port port - </verb> - - <p>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. - - <p>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. - - <p>Si los números de puertos no se repiten, hay tres opciones - más: - - <p><bf>1)</bf> 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. - - <p>Esta es la solución más difícil, pero es la - mejor y hará que el software funcione con múltiples - máquinas. - - <p><bf>2)</bf> 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. - - <p><bf>3)</bf> Redireccionar todo el tráfico a la máquina - interna usando "alias addr". Esta es la solución más - sencilla. - - <sect3> - <heading>¿Ha hecho alguien una lista de puertos útiles?</heading> - - <p>Todavía no, pero se podría hacer, si hay - interés. En cada ejemplo, <tt>internal</tt> debe ser - reemplazado por la dirección IP de la máquina que - va a estar jugando. - - <itemize> - <item><bf>Quake</bf> - <p><tt>alias port udp internal:6112 6112</tt> - <p>Alternativamente, quizás estés interesado en - mirar en el - <htmlurl url="http://www.battle.net/support/proxy/" - name="www.battle.net">soporte de Quake a través de proxy">. - </itemize> - - <itemize> - <item><bf>Quake 2</bf> - <p><tt>alias port udp internal:27901 27910</tt> - </itemize> - - <itemize> - <item><bf>Red Alert</bf> - <p><tt>alias port udp internal:8675 8675</tt> - <p><tt>alias port udp internal:5009 5009</tt> - </itemize> - - <itemize> - <item><bf>Half Life</bf> - <p><tt>alias port udp internal:27005 27015</tt> - </itemize> - - <itemize> - <item><bf>PCAnywhere 8.0</bf> - <p><tt>alias port udp internal:5632 5632</tt> - <p><tt>alias port tcp internal:5631 5631</tt> - </itemize> - - - <sect2> - <heading>¿Qué son los errores FCS?</heading> - - <p>FCS significa <bf/F/rame <bf/C/heck <bf/S/equence. 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 <tt>show hdlc</tt>. - - <p>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. - - <p>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 <bf>debe</bf> usar control de flujo por software, usa el - comando <tt>set accmap 0x000a0000</tt> para indicar al <bf>ppp</bf> - que "escape" los carácteres ^Q y ^S. - - <p>Otra razón para ver muchos errores FCS puede ser que el - remoto haya dejado de "hablar" <bf/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 <tt>close clp</tt> (usando - el comando <tt>term</tt> podrás conectar de nuevo con el shell - de la máquina remota. - - <p>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. - - <sect2> - <heading>Nada de esto me ayuda - Estoy desesperado !</heading> - - <p>Si todo falla, envía toda la información que puedas, - incluyendo los ficheros de configuración, como arrancas el ppp, - las partes relevantes del fichero de log y la salida del comando - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?netstat" - name="netstat -rn"> (antes y despues de la conexión) a la lista - de distribución <url url="mailto:FreeBSD-questions@FreeBSD.org" - name="FreeBSD-questions@FreeBSD.org">, a la lista de - <url url="mailto:FreeBSD@es.FreeBSD.org" name="FreeBSD en - castellano"> o al grupo de news - <url url="news:comp.unix.bsd.FreeBSD.misc" - name="comp.unix.bsd.FreeBSD.misc"> y alguien te ayudará a - solucionar los problemas. - - <sect1> - <heading>No puedo crear el dispositivo <tt>/dev/ed0</tt>!</heading> - - <p>En el sistema de trabajo de red de Berkeley, los interfaces de - red solo son directamente accesibles por el código del kernel. Por - favor, mira el fichero <tt>/etc/rc.network</tt> y los man de los - programas de red allí mencionados. Si esto te deja totalmente - confundido, entonces tendrías que conseguir algun libro de - administración de red de cualquier sistema operativo basado en BSD; - con algunas excepciones significativas, administrar el sistema de red - en FreeBSD es básicamente igual que en SunOS 4.0 o Ultrix. - - <sect1> - <heading>¿Cómo puedo configurar alias de ethernets?</heading> - - <p>Añade ``<tt/netmask 0xffffffff/'' en el comando <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?ifconfig" name="ifconfig"> - como el siguiente: - - <verb> - ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff - </verb> - - <sect1> - <heading>¿Cómo hago para usar el otro puerto de una 3C503?</heading> - - <p>Si quieres usar los otros puertos, tendrás que especificar - parámetros adicionales en el comando - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ifconfig" - name="ifconfig">. El puerto por defecto es <tt/link0/. Para usar el - puerto AUI en lugar del BSN, usa <tt/link2/. Estos flags tendrían - que ser especificados usando las variable ifconfig_* en el fichero - <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf" - name="/etc/rc.conf">. - - <sect1> - <heading>Tengo problemas con NFS desde/hacia FreeBSD.</heading> - - <p>Algunas tarjetas de red son mejores que otras y algunas veces - pueden causar problemas con aplicaciones de uso intensivo de red - como NFS - - <p>Mira la <url url="../../handbook/nfs.html" name="entrada en el manual - de NFS"> para mas información sobre este tema. - - <sect1> - <heading>¿Porqué no puedo hacer NFS-mount desde Linux?</heading> - - <p>Algunas versiones de NFS para Linux solo aceptan peticiones - para montar unidades hechas desde un puerto privilegiado; intenta: - - <verb> - mount -o -P linuxbox:/blah /mnt - </verb> - - <sect1> - <heading>¿Porqué no puedo hacer NFS-mount desde una Sun?</heading> - - <p>Las estaciones de trabajo Sun con SunOS 4.x solo aceptan peticiones - de montar unidades hechas desde puertos privilegiados; intenta - - <verb> - mount -o -P sunbox:/blah /mnt - </verb> - - <sect1> - <heading>Tengo problemas usando ppp contra máquinas NeXTStep.</heading> - - <p>Intenta desactivar las extensiones TCP en - url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> - cambiando la siguiente variable a NO: - - <verb> - tcp_extensions=NO - </verb> - - <p>Las máquinas Xylogic's Annex también tienen este - problema, por lo que tienes que hacer el mismo cambio para conectar con - ellas. - - <sect1> - <heading>¿Cómo activo soporte de IP multicast?</heading> - - <p>Las operaciones multicast están totalmente soportadas en FreeBSD - 2.0 y superiores. Si quieres usar tu máquina como router multicast, - necesitarás cargar el módulo de kernel <tt/ip_mrouted_mod/ y - ejecutar el programa <tt/mrouted/. - - <p>Para mas información: - - <verb> -Producto Descripcion Donde ---------------- ----------------------- --------------------------------------- -faq.txt Mbone FAQ ftp.isi.edu:/mbone/faq.txt -imm/immserv IMage Multicast ftp.hawaii.edu:/paccom/imm.src.tar.Z - for jpg/gif images. -nv Network Video. ftp.parc.xerox.com: - /pub/net-reseach/exp/nv3.3alpha.tar.Z -vat LBL Visual Audio Tool. ftp.ee.lbl.gov: - /conferencing/vat/i386-vat.tar.Z -wb LBL White Board. ftp.ee.lbl.gov: - /conferencing/wb/i386-wb.tar.Z -mmcc MultiMedia Conference ftp.isi.edu: - Control program /confctrl/mmcc/mmcc-intel.tar.Z -rtpqual Tools for testing the ftp.psc.edu:/pub/net_tools/rtpqual.c - quality of RTP packets. -vat_nv_record Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z - and nv. - </verb> - - <sect1> - <heading>¿Qué tarjetas de red están basadas en el chipset DEC PCI?</heading> - - <p>Aquí tienes una lista hecha por <url url="mailto:gfoster@driver.nsta.org" - name="Glen Foster">: - - <verb> - Fabricante Modelo - ---------------------------------------------- - ASUS PCI-L101-TB - Accton ENI1203 - Cogent EM960PCI - Compex ENET32-PCI - D-Link DE-530 - Dayna DP1203, DP2100 - DEC DE435, DE450 - Danpex EN-9400P3 - JCIS Condor JC1260 - Linksys EtherPCI - Mylex LNP101 - SMC EtherPower 10/100 (Model 9332) - SMC EtherPower (Model 8432) - TopWare TE-3500P - Zynx ZX342 - </verb> - - <sect1> - <heading>¿Porqué tengo que usar el FQDN para hosts en mi servidor?</heading> - - <p>Probablemente el host estará en un dominio diferente; por - ejemplo, si estás en el dominio foo.bar.edu y quieres encontrar - un host llamado "mumble" en el dominio bar.edu, tendrás que - llamarlo por su nombre de dominio, "mumble.bar.edu", en vez de solo - "mumble". - - <p>Tradicionalmente, esto era permitido por los resolvers BIND BSD. - La versión actual de <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?named" name="bind"> que - se incluye en FreeBSD no resuelve abreviaciones de nombres para - hosts fuera de nuestro dominio. - - <sect1> - <heading>``Permission denied'' para todas las operaciones de red. - </heading> - - <p>Si tienes el kernel compilado con la opción <tt/IPFIREWALL/ - . debes tener en cuenta que la política por defecto es denegar - explícitamente todos los paquetes que no están - explícitamente permitidos. - - <p>Si involuntariamente has desconfigurado el firewall de tu sistema, - puedes restaurar la operatibilidad de la red tecleando el siguiente - comando como usuario root: - - <verb> - ipfw add 65534 allow all from any to any - </verb> - - <p>Para mas información en la configuración del firewall - de FreeBSD, mira la sección - <url url="../../handbook/firewalls.html" name="del manual">. - - <sect1> - <heading>¿Cuanto tiempo retrasa IPFW el tráfico?</heading> - - <p>Esta respuesta depende mucho en las reglas definidas y en la - versión del procesador. Para la mayoría de aplicaciones - que tienen que ver con la ethernet y pequeñas reglas, la - respuesta es, prácticamente nada. - - Aquí tienes una lista de cosas a tener en cuenta para crear reglas - de filtrado eficientes: - - <itemize> - - <item>Poner una regla "established" al inicio para manejar la - mayoría de trafico TCP. No pongas ninguna regla - <tt>allow tcp</tt> antes de esta. - - <item>Pon las reglas más usadas antes de las menos usadas - (<bf>sin modificar la permisividad del firewall</bf>). Puedes ver cuales - son las reglas más usadas examinando los contadores de paquetes - con la orden <tt>ipfw -a l</tt>. - - </itemize> - - <sect1> - <heading>¿Cómo puedo redirigir peticiones de una máquina - a otra?<(/heading> - - <p>Puedes redirigir peticiones FTP (y otros servicios) con el package - "socket", disponible en la colección de ports categoría - "sysutils". - Simplemente tienes que reemplazar la línea del servicio - correspondiente en el fichero /etc/services de la siguiente manera: - -<verb> -ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp -</verb> - - <p>donde "ftp.foo.com" y "ftp" son la máquina y puerto - de destino. - - <sect1> - <heading>¿Dónde puedo conseguir una herramienta de control de ancho de banda?.</heading> - - <p>Existen dos herramientas de control de ancho de banda para FreeBSD. - <url url="http://www.csl.sony.co.jp/person/kjc/programs.html" - name="ALTQ"> es gratis; Bandwidth Manager de - <url url="http://www.etinc.com" name="Emerging Technologies"> es un - producto comercial. - - <sect1> - <heading>¿Porqué aparece "/dev/bpf0: device not configured"? - </heading> - - <p>El driver Berkeley Packet Filter <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)"> necesita ser - activado para ejecutar programas que lo utilizan. Añade esto al - fichero de configuración de tu kernel y crea uno nuevo: - - <verb> - pseudo-device bpfilter # Berkeley Packet Filter - </verb> - - <p>A continuación, después de rebotar tendrás el - dispositivo. Esto puede hacerse entrando en el directorio <tt>/dev</tt> - y ejecutando el siguiente comando: - - <tscreen><verb> - # sh MAKEDEV bpf0 - </verb></tscreen> - - <p>Por favor, mira la <htmlurl url="../../handbook/kernelconfig-nodes.html" - name="entrada correspondiente en el handbook"> para más - información sobre la creación de dispositivos. - |