doc/es_ES.ISO8859-1/FAQ/network.sgml

<!-- $Id: network.sgml,v 1.3 1998-11-26 22:33:33 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 &amp; 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>

    <sect1>
       <heading>Como puedo redirigir peticiones de una maquina a otra?<(/heading>

       <p>Puedes redirigir peticiones FTP (y otros servicios) con el package
       "socket", disponible en la coleccion de ports categoria "sysutils".
       Simplemente tienes que reemplazar la linea 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 maquina y puerto de destino.


  </sect>