1167 lines
50 KiB
Text
1167 lines
50 KiB
Text
<!-- $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.
|
|
|