diff options
Diffstat (limited to 'es/FAQ/network.sgml')
| -rw-r--r-- | es/FAQ/network.sgml | 942 |
1 files changed, 942 insertions, 0 deletions
diff --git a/es/FAQ/network.sgml b/es/FAQ/network.sgml new file mode 100644 index 0000000000..e168d99e79 --- /dev/null +++ b/es/FAQ/network.sgml @@ -0,0 +1,942 @@ +<!-- $Id: network.sgml,v 1.1.1.1 1998-07-20 17:09:45 nik Exp $ --> +<!-- The FreeBSD Documentation Spanish Project --> + <sect> + <heading>Networking<label id="networking"></heading> + + <sect1> + <heading>Donde puedo encontrar informacion sobre "diskless booting"?</heading> + + <p>"Diskless booting" significa que una maquina FreeBSD sea arrancada + sobre una red, y lea los ficheros necesarios de un servidor y no + desde su disco duro. Para mas detalles, por favor, lee la seccion + <url url="../../handbook/diskless.html" + name="diskless booting del manual"> + + <sect1> + <heading> + Puede una maquina FreeBSD ser usada como router dedicado? + </heading> + + <p>Los estandards de Internet y las buenas practicas de ingenieria + nos prohiben proveer de la el forward de paquetes en la distribucion + estandard. Aun asi, puedes activar esta opcion 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 opcion pondra 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 tambien necesitaras 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 mas comlejas quizas quieras usar <em/GaTeD/ + disponible por ftp en <tt/ftp.gated.Merit.EDU/. + + <p>Es nuestro deber advertirte que estand 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 traves de FreeBSD?</heading> + + <p>Tipicamente, 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 Windows95. Esta es realmente un caso especial de la + pregunta anterior. + + <p>Hay un util documento disponible que explica como configurar + FreeBSD como un + <url url="http://www.ssimicro.com/~jeremyc/ppp.html" + name="PPP Dialup Router"> + + <p><bf/NOTA:/ Esto requiere, al menos, tener dos direcciones IP + fijas disponibles, y posiblemente tres o mas, dependiendo del + numero de maquinas que quieras conectar. Como alternativa, si no + tienes una direccion IP fija, puedes usar una de las subredes + privadas e instalar un proxie 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 tambien la seccion <ref id="direct-at" name="natd">. + + <sect1> + <heading> + Por que falla la compilacion del ultimo BIND del ISC? + </heading> + + <p>Hay un conflicto entre el fichero <tt/cdefs.h/ incluido en la + distribucion 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>Si. 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/handbook.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/userppp.html" + name="Handbook entry on PPP (user-mode version)"> + </itemize> + + <p>Si solo tienes acceso a Internet a traves de un "shell + account", quizas 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 mas maquinas), pero solo se te ha + asignado una unica direccion IP desde tu proveedor de Internet (o si + recibes las direcciones de manera dinamica), 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 direccion IP. + + <p>El programa + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> + tiene una funcionalidad similar incluida, a traves del parametro + -alias. La <htmlurl + url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library"> + es usada en ambos casos. + + + <sect1> + <heading> + El ppp no funciona. Que estoy haciendo mal?<label id="userppp"> + </heading> + + <p>Primero deberias leer la <htmlurl + url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp man page"> y + la <url url="../../handbook/userppp.html" + name="seccion 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 deberia ser tecleado en el prompt del <bf/ppp/ o + incluirse en el fichero de configuracion <tt>/etc/ppp/ppp.conf</tt> + (al inicio de la seccion <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 lineas: + + <verb> + !ppp + *.* /var/log/ppp.log + </verb> + + <p>y que el fichero <tt>/var/log/ppp.log</tt> existe. Puedes + encontrar mucha informacion sobre lo que esta pasando en las + conexiones con el fichero de log. + + <p>Si tu version de ppp no entiende el comando "set log" deberias + bajarte la + <url url="http://www.freebsd.org/~brian" name="ultima version">. + Esta compilara sin problemas en FreeBSD 2.1.5 y superiores. + + <sect2> + <heading>PPP no quiere marcar en modo -auto</heading> + + <p>Primero, asegurate de tener una ruta por defecto. Ejecutando + el comando url="http://www.freebsd.org/cgi/man.cgi?netstat"> + name="netstat -rn"> deberia 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 pagina man o del fichero de ejemplo ppp.conf.sample. Si no + tienes una ruta por defecto, puede ser por que estes usando una + version 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 version de <bf/ppp/ es de antes de FreeBSD 2.2.5, cambia la + linea + + <verb> + add 0 0 HISADDR + </verb> + + <p>por otra diciendo + + <verb> + add 0 0 10.0.0.2 + </verb> + + <p>Otra razon 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 linea + + <verb> + delete ALL + </verb> + + <p>en el fichero <tt>ppp.conf</tt>. Si es este el caso vuelve a la + seccion <url url="../../handbook/userppp:final.html" + name="configuracion final del sistema"> en el handbook. + + <sect2> + <heading>Que significa "No route to host"</heading> + + <p>Este error se debe normalmente a la falta de la seccion + + <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 dinamica o no sabes la + direccion de tu gateway. Si estas usando el modo interactivo, puedes + teclear lo siguiente despues de entrar en <tt/packet mode/: + + <verb> + delete ALL + add 0 0 HISADDR + </verb> + + <p>Pasate por la seccion + <url url="../../handbook/userppp:dynamicIP.html" + name="PPP and Dynamic IP addresses"> del handbook para mas + informacion. + + <sect2> + <heading>Mi conexion se corta pasados 3 minutos</heading> + + <p>El timeout de ppp por defecto es de 3 minutos. Se puede ajustar + con la linea: + + <verb> + set timeout NNN + </verb> + + <p>Donde <bf/NNN/ es el numero de segundos de inactividad antes de + cerrar la conexion. Si <bf/NNN/ es 0, la conexion no se cerrara + nunca por timeout. Es posible poner este comando en el fichero + <tt>ppp.conf</tt>, o teclearla en el prompt del modo interactivo. + Tambien es posible ajustarla en cualquier momento mientras la + conexion este 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 mas detalles. + + <sect2> + <heading>Mi coneion se corta en situaciones de carga</heading> + + <p>Si tienes la opcion Link Quality Reporting (LQR) configurada + es posible que demasiados paquetes LQR se pierdan entre tu + maquina y el remoto. PPP deduce que la linea es mala y corta la + conexion. En versiones anteriores a la 2.2.5 de FreeBSD, LQR + estaba activado por defecto. Ahora esta desactivado por defecto. + LQR puede ser activado con la linea + + <verb> + disable lqr + </verb> + + <sect2> + <heading>Mi conexion se corta en periodos aleatorios</heading> + + <p>Algunas veces, en lineas telefonicas de baja calidad o con + mucho ruido, o lineas con la opcion de llamada en espera activada, + el modem corta la conexion por que piensa (erroneamente) que ha + perdido la portadora. + + <p>Hay una opcion en muchos modems para determiar la tolerancia + a perdidas temporales de portadora. En un USR Sportster por + ejemplo, esta es medida por el registro S10 en decimas de segundo. + Para hacer que tu modem sea mas resistente, puedes anyadir la + siguiente secuencia "send-expect" a la cadena de llamada: + + <verb> + set dial "...... ATS10=10 OK ......" + </verb> + + <p>Mira en el manual de tu modem para mas detalles. + + <sect2> + <heading>No ocurre nada despues del mensaje Login OK</heading> + + <p>En versiones anteriores a FreeBSD 2.2.5, una vez estaba la + conexion establecida, + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" + name="ppp"> espera a que el remoto inicie la negociacion LCP + (Line COntrol Protocol). Muchos proveedores de Internet no + iniciaran la negociacion esperando que sea el cliente el + que lo haga. Para forzar al <bf/ppp/ a iniciar el LCP, usa la + siguiente linea: + + <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) + esta activo por defecto. De todas maneras, la siguiente seccion + explica cuando pueden haber problemas. + + <sect2> + <heading>Sigo teniendo errores sobre el parametro magic</heading> + + <p>Ocasionalmente, justo despues de la conexion, 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 conexion. Algunas + implementaciones de ppp no pueden solucionar este problema, y, + aunque parezca que la conexion esta establecida, veras + repetidas peticiones y aceptaciones de configuracion en el fichero + de log hasta que una de las dos partes cierra la conexion. + + <p>Esto ocurre normalmente en servidores con disco lentos que + tienen problemas para gestionar eficientemente los puertos + serie. Tambien existen informes de problemas en conexiones + mediante slirp. La razon 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 todavia + activo en el puerto del servidor, el cliente ppp lo unico que + ve son sus propios paquetes "reflejados" por el servidor. + + <p>Una parte de la negociacion LCP es establecer un numero + magico 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 envia paquetes LCP, ve que el mismo "magic" + vuelve en el paquete reflejado y lo da como no valido (envia NAK). + Este todavia ve el paquete reflajado con NAK (lo que significa que + el ppp debe cambiar su "magic"). Esto produce un enorme numero 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 numero suficiente de negociaciones LCP y + corta la conexion. Mientras tanto, el cliente, que ya no ve los + paquetes reflejados, recibe sin problemas la desconexion del + servidor y tambien cierra la conexion. + + <p>Esto puede ser resuelto permitiendo que el remoto inicie la + negociacion, poniendo la siguiente linea en el fichero ppp.conf: + + <verb> + set openmode passive + </verb> + + <p>Esto indica al ppp que espere a que el servidor comience la + negociacion LCP. Es posible que algunos servidores nunca inicien + la negociacion. 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 envia + peticiones durante este periodo, ppp respondera inmediatamente sin + esperar los 3 segundos establecidos. + + <sect2> + <heading> + Las negociaciones LCP continuan hasta que se cierra la conexion</heading> + + <p>Existe actualmente un problema de implementacion en <bf/ppp/ en + la que no asocia las respuestas LCP, CCP & IPCP con sus + peticiones originales. Como resultado, si una implementacion + <bf/ppp/ es mas lenta durante 6 segundos que la remota, la remota + enviara dos peticiones de configuracion LCP adicionales. + Esto es fatal. + + <p>Considera dos implementaciones, <bf/A/ y <bf/B/. <bf/A/ empieza + a enviar peticiones LCP inmediatamente despues 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 linea tiene el + ECHO desactivado, si no, veriamos los problemas de "magic number" + descritos en el apartado anterior. <bf/B/ envia un REQ, y a + continuacion envia un ACK al primer REQ de <bf/A/. Esto resulta en + que <bf/A/ entra en modo <bf/OPENED/ y envia 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 qye 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 envia 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 conexion. + + <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 negociacion. Esto puede realizarse con el + comando: + + <verb> + set openmode passive + </verb> + + Se debe tener cuidado con esta opcion. Tambien se puede usar: + + <verb> + set stopped N + </verb> + + para limitar el numero de veces que <bf/ppp/ espera a que el remoto + comience la negociacion. Alternativamente, puedes user el comando: + + <verb> + set openmode active N + </verb> + + donde <bf/N/ es el numero de segundos que espera antes de empezar + la negociacion. Mira en el manual para mas detalles. + + <sect2> + <heading>Ppp se bloquea al conectar</heading> + + <p>Antes de la version 2.2.5 era posible que la conexion se corte + nada mas iniciarse debido a un problema en la negociacion de + compresion Predictor1. Esto solo pasa si las dos partes intentan + negociar con diferentes protocolos de control de compresion (CCP). + Este problema ya esta corregido, pero si estas usando una version + antigua de <bf/ppp/, el problema puede solucionarse con la linea + + <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/ ejecutara esos + argumentos). Ppp esperara a que se complete el comando antes de + continuar. Si intentas usar la conexion ppp mientras se ejecuta el + comando, parecera que la conexion se ha colgado. Esto es por que + <bf/ppp/ esta esperando a que se complete la ejecucion del comando. + + <p>Si quieres ejecutar comando como este, usa el comando <tt/!bg/ en + su lugar. Esto ejecutara el comando en background, y ppp continua + sin problemas con la conexion. + + <sect2> + <heading>Ppp sobre un cable null-modem no funciona</heading> + + <p>No hay manera que <bf/ppp/ detecte automaticamente que una + conexion directa se ha cortado. Es debido a las lineas que se usan + en un cable serie null-modem. Cuando usamos este tipo de conexion, + LQR deberia 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 linea: + + <verb> + set log +tcp/ip + </verb> + + <p>Esto guardara todo el trafico que pase a traves de la conexion. + La proxima vez que se realice una llamada no deseada, podras ver + la causa convenientemente guardada. + + <p>Ahora puede 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 linea (esto no hara que los paquetes de DNS queden + parados cuando la conexion esta 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 operacion. + + <p>En el caso del DNS, deberias determinar que es lo que esta + 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 + seccion <ref id="ispmail" name="Configuracion de correo"> para tener + mas detalles acerca de como crear una fichero propio de configuracion + de sendmail. Tambien deberias anyadir la siguiente linea 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>Que 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 esta intentando negociar compresion + Predictor1, y el remoto no quiere negociar ningun tipo de + compresion. Estos mensajes son sin importancia, pero si quieres + eliminarlos, puedes desactivar la compresion Predicto1 localmente: + + <verb> + disable pred1 + </verb> + + <sect2> + <heading>PPP se cuelga durante transferencia de ficheros con errores I/OP</heading> + + <p>En la version FreeBSD 2.2.2 y anteriores, habia un problema en + el driver tun que no permitia paquetes entrantes con un tamanyo + mayor que el MTU del interface. La recepcion de un paquete mayor + que el MTU resulta en un error IO que es logueado via syslogd. + + <p>La especificacion PPP dice que un MRU de 1500 <bf>siempre</bf> + deberia ser aceptada como minimo, 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 este enviando paquetes + de 1500, haciendo que tu conexion se bloquee. + + <p>El problema puede solucionarse haciendo que el tamnyo del + MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores. + + <sect2> + <heading>Por que no ppp no loguea la velocidad de la conexion?</heading> + + <p>Para loguear todas las linea de "conversacion" de tu modem, debes + activar la siguiente opcion: + + <verb> + set log +connect + </verb> + + <p>Esto hara que + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> + loguee todo hasta la ultima cadena "expect" pedida. + + <p>Si quieres ver la velocidad de tu conexion y usas PAP o CHAP + (y por lo tanto no tienes nada que "chatear" despues del CONNECT + en el script de marcado), debes estar seguro de indicarle al ppp que + espera la linea "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>Aqui, tenemos nuestro CONNECT, enviamos nada, y esperamos un + salto de linea, forzando al <bf/ppp/ que lea la respuesta del + CONNECT. + + <sect2> + <heading>Ppp ignora el caracter `\' en mi chat script</heading> + + <p>PPP lee cada linea de los ficheros de configuracion para poder + interpretar cadenas como <tt/set phone "123 456 789"/ correctamente. + Para especificar un caracter ``"'', debes usar la contrabarra (``\''). + + <p>Cuando el interprete lee cada argumento, reinterpreta el argumento + para buscar alguna secuencia especial de escape como ``\P'' or ``\T''. + Como resultado de esta dobre lectura, recuerda que has de usar el + numero correcto de escapes (contrabarras). + + <p>Si quieres enviar un caracter ``\'' a tu modem, necesitas hacer + algo como: + + <verb> + set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" + </verb> + + <p>resultado 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 deberian + hacer un core dump. Por que ppp funciona con un id de usuario 0, + el sistema operativo no escribira la imagen del core en disco. + Si ppp termina con errores de "segmentation violation" o cualquier + otra senyal que normalmente causa un core dumped, y quieres poder + hacer un debug de ese core, asegurate de usar la ultima version 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 tendras instalada una version "debuggable" de ppp. Tendras + 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 violacion de segmentacion, creara + un fichero core llamado ppp.core. A continuacion, deberias 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 informacion puede hacer posible diagnosticar el + problema. Si estas familiarizado con gdb, puedes encontrar otras + pistas como que causo el dump y las direcciones y valores de las + variables mas relevantes. + + <sect2> + <heading> + El proceso que fuerza una llamada en modo auto nunca funciona + </heading> + + <p>Este es un problema conocido cuando <bf/ppp/ esta configurado + para negociar una IP dinamica local con el remoto. Cuando ese + 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 conexion. Si, como resultado de la asignacion dinamica + de IP, la direccion del interface es cambiada, el punto final del + socket original sera invalido. Los siguientes paquetes enviados al + remoto normalmente seran descartados. Aun si no lo son, cualquier + respuesta no sera enrutada hacia la maquina de origen por que la + direccion IP de la maquina de origen ha cambiado. + + <p>Hay varias maneras teoricas de solucionar este problema. Lo + mejor seria que el remoto reasignase la misma IP si fuese posible + <tt/:-)/ + + <p>El metodo mas sencillo desde nuestra parte, seria 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 parametro <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/ deberia usar esta llamada para modificar los + sockets de todos los programas existentes cuando una nueva direccion + IP es negociada. + + <p>Una tercera opcion es permitir que un interface se active sin + IP. Los paquetes salientes tendrian un IP de 255.255.255.255 hasta + que el primer SIOCAIFADDR ioctl este hecho. Esto permitiria 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. + + <p>Ninguna de estas soluciones ha sido implementada (todavia). + + <sect2> + <heading>Nada de esto me ayuda - Estoy desesperado !</heading> + + <p>Si todo falla, envia toda la informacion que puedas, incluyendo + los ficheros de configuracion, 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 conexion) a la lista de + distribucion <url url="mailto:freebsd-questions@FreeBSD.org" + name="freebsd-questions@FreeBSD.org"> o al grupo de news + <url url="news:comp.unix.bsd.freebsd.misc" + name="comp.unix.bsd.freebsd.misc"> y alguien te ayudara 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 codigo del kernel. Por + favor, mira el fichero <tt>/etc/rc.network</tt> y los man de los + programas de red alli mencionados. Si esto te deja totalmente + confundido, entonces tendrias que conseguir algun libro de + administracion de red de cualquier sistema operativo basado en BSD; + con algunas excepciones significativas, administrar el sistema de red + en FreeBSD es basicamente igual que en SunOS 4.0 o Ultrix. + + <sect1> + <heading>Como puedo configurar alias de ethernets?</heading> + + <p>Anyade ``<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>Como hago para usar el otro puerto de una 3C503?</heading> + + <p>Si quieres usar los otros puertos, tendras que especificar + parametros 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 tendrian 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 informacion sobre este tema. + + <sect1> + <heading>Por que 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>Por que 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 maquinas 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 maquinas Xylogic's Annex tambien tienen este problema, por lo + que tienes que hacer el mismo cambio para conectar con ellas. + + <sect1> + <heading>Como activo soporte de IP multicast?</heading> + + <p>Las operaciones multicast estan totalmente soportadas en FreeBSD + 2.0 y superiores. Si quieres usar tu maquina como router multicast, + necesitaras cargar el modulo de kernel <tt/ip_mrouted_mod/ y + ejecutar el programa <tt/mrouted/. + + <p>Para mas informacion: + + <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>Que tarjetas de red estan basadas en el chipset DEC PCI?</heading> + + <p>Aqui 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 + DEC DE435 + 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>Por que tengo que usar FQDN para hosts en mi servidor?</heading> + + <p>Probablemente el host estara en un dominio diferente; por ejemplo, + si estas en el dominio foo.bar.edu y quieres encontrar un host + llamado "mumble" en el dominio bar.edu, tendras 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 version 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 opcion <tt/IPFIREWALL/ + . debes tener en cuenta que la politica por defecto es denegar + explicitamente todos los paquetes que no estan explicitamente + 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 informacion en la configuracion del firewall de FreeBSD, mira + la seccion <url url="../../handbook/firewalls.html" name="del manual">. + + <sect1> + <heading>Cuanto tiempo retrasa IPFW el trafico?</heading> + + <p>Esta respuesta depende mucho en las reglas definidas y en la + version del procesador. Para la mayoria de aplicaciones que tienen + que ver con la ethernet y pequenyas reglas, la respuesta es, + practicamente nada. + + Aqui 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 + mayoria de trafico TCP. No pongas ninguna regla + <tt>allow tcp</tt> antes de esta. + + <item>Pon las reglas mas usadas antes de las menos usadas (<bf>sin + modificar la permisividad del firewall</bf>). Puedes ver cuales + son las reglas mas usadas examinando los contadores de paquetes con + la orden <tt>ipfw -a l</tt>. + + </itemize> + + </sect> + |