"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 ¿Puede una máquina FreeBSD ser usada como router dedicado?

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 : gateway_enable=YES # Set to YES if this host will be a gateway

Esta opción pondrá la variable 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 , aunque en situaciones más complejas quizás quieras usar 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. ¿Puedo conectar mi Win95 con Internet a través de FreeBSD?

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.

Hay un útil documento disponible que explica como configurar FreeBSD como un

y en tu FreeBSD.

Mira también la sección . ¿Por que falla la compilación del último BIND del ISC?

Hay un conflicto entre el fichero compat/include/sys/cdefs.h. ¿Soporta FreeBSD SLIP y PPP?

Sí. Mira las paginas man de , , y . trabaja exclusivamente con conexiones entrantes y con conexiones salientes.

Estos programas son descritos en las siguientes secciones del :

Si solo tienes acceso a Internet a traves de un "shell account", quizás quieras mirar el package . Puede darte un (limitado) acceso a servicios como ftp y http. ¿Soporta FreeBSD NAT o Masquerading?

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 . El programa tiene una funcionalidad similar incluida, a través del parámetro -alias. La es usada en ambos casos. El ppp no funciona. ¿Qué estoy haciendo mal?

Primero deberías leer el y la . Activa los logs con el comando set log Phase Chat Connect Carrier lcp ipcp ccp command

Este comando debería ser tecleado en el prompt del /etc/ppp/ppp.conf (al inicio de la sección default 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: !ppp *.* /var/log/ppp.log

y que el fichero /var/log/ppp.log existe. Puedes encontrar mucha información sobre lo que está pasando en las conexiones con el fichero de log.

Si tu versión de ppp no entiende el comando "set log" deberías bajarte la . Esta compilará sin problemas en FreeBSD 2.1.5 y superiores. PPP no quiere marcar en modo -auto

Primero, asegúrate de tener una ruta por defecto. Ejecutando el comando url="http://www.FreeBSD.org/cgi/man.cgi?netstat"> name="netstat -rn"> deberías ver dos entradas como estas: 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

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 que no entiende la palabra add 0 0 HISADDR

por otra diciendo add 0 0 10.0.0.2

Otra razón para la inexistencia de la ruta por defecto es que sin darte cuenta hayas creado un default router en el fichero /etc/rc.conf (anteriormente llamado /etc/sysconfig) y hayas omitido la línea delete ALL

en el fichero ppp.conf. Si es este el caso vuelve a la sección en el handbook. ¿Qué significa "No route to host"?

Este error se debe normalmente a la falta de la sección MYADDR: delete ALL add 0 0 HISADDR

en el fichero /etc/ppp/ppp.linkup. 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 delete ALL add 0 0 HISADDR

Pásate por la sección del handbook para más información. Mi conexión se corta pasados 3 minutos

El timeout de ppp por defecto es de 3 minutos. Se puede ajustar con la línea: set timeout NNN

Donde ppp.conf, 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 o . Leete el man de para más detalles. Mi conexión se corta en situaciones de carga

Si tienes la opción Link Quality Reporting (LQR) configurada es posible que demasiados paquetes LQR se pierdan entre tu máquina y el remoto. PPP deduce que la línea es mala y corta la conexión. En versiones anteriores a la 2.2.5 de FreeBSD, LQR estaba activado por defecto. Ahora está desactivado por defecto. LQR puede ser activado con la línea disable lqr Mi conexión se corta en periodos aleatorios

Algunas veces, en líneas telefónicas de baja calidad o con mucho ruido, o líneas con la opción de llamada en espera activada, el módem corta la conexión por que piensa (erróneamente) que ha perdido la portadora.

Hay una opción en muchos modems para determiar la tolerancia a pérdidas temporales de portadora. En un USR Sportster por ejemplo, esta es medida por el registro S10 en décimas de segundo. Para hacer que tu módem sea más resistente, puedes añadir la siguiente secuencia "send-expect" a la cadena de llamada: set dial "...... ATS10=10 OK ......"

Mira en el manual de tu módem para más detalles. No ocurre nada después del mensaje Login OK

En versiones anteriores a FreeBSD 2.2.5, una vez estaba la conexión establecida, 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 set openmode active

Sigo teniendo errores sobre el parámetro magic

Ocasionalmente, justo después de la conexión, puedes ver mensajes en el log referentes a "magic number is the same". Algunas veces, estos mensajes son inofensivos, y otras veces uno de los dos extremos finaliza la conexión. Algunas implementaciones de ppp no pueden solucionar este problema, y, aunque parezca que la conexión está establecida, verás repetidas peticiones y aceptaciones de configuración en el fichero de log hasta que una de las dos partes cierra la conexión.

Esto ocurre normalmente en servidores con disco lentos que tienen problemas para gestionar eficientemente los puertos serie. También existen informes de problemas en conexiones mediante slip. La razón es que en el tiempo que tarda el servidor en salir del getty y ejecutar el ppp, el cliente manda los paquetes de inicio LCP. Al estar el ECHO todavía activo en el puerto del servidor, el cliente ppp lo único que ve son sus propios paquetes "reflejados" por el servidor.

Una parte de la negociación LCP es establecer un número mágico para cada una de los dos extremos de las conexiones para que los "reflejos" puedan ser detectados. El protocolo dice que cuando el remoto intenta negociar el mismo "magic number", se debe enviar un NAK para seleccionar un nuevo "magic number". Durante el periodo de tiempo que el servidor tiene el ECHO activado en el puerto, el cliente ppp envía paquetes LCP, ve que el mismo "magic" vuelve en el paquete reflejado y lo da como no válido (envia NAK). Este todavía ve el paquete reflajado con NAK (lo que significa que el ppp debe cambiar su "magic"). Esto produce un enorme número de cambios de "magic number" que son introducidos en el buffer tty del servidor. Tan pronto como el ppp arranca en el servidor, es bombardeado con cambios de "magic numbers" e inmediatamente decide que ya ha realizado el número suficiente de negociaciones LCP y corta la conexión. Mientras tanto, el cliente, que ya no ve los paquetes reflejados, recibe sin problemas la desconexión del servidor y también cierra la conexión.

Esto puede ser resuelto permitiendo que el remoto inicie la negociación, poniendo la siguiente línea en el fichero ppp.conf: set openmode passive

Esto indica al ppp que espere a que el servidor comience la negociación LCP. Es posible que algunos servidores nunca inicien la negociación. Si este es el caso, puedes hacer algo como: set openmode active 3

Esto le indica al ppp que sea pasivo durante 3 segundos, y despues comience a enviar peticiones LCP. Si el remoto envía peticiones durante este periodo, ppp responderá inmediatamente sin esperar los 3 segundos establecidos. Las negociaciones LCP continuan hasta que se cierra la conexión

Existe actualmente un problema de implementación en Considera dos implementaciones, Esto pasa hasta que una de las partes piensa que ya ha realizado suficientes reintentos y corta la conexión.

La mejor manera de evitar esto es configurar una de las partes de manera set openmode passive Se debe tener cuidado con esta opción. También se puede usar: set stopped N para limitar el número de veces que set openmode active N donde Ppp se bloquea al conectar

Antes de la versión 2.2.5 era posible que la conexión se corte nada más iniciarse debido a un problema en la negociación de compresión Predictor1. Esto solo pasa si las dos partes intentan negociar con diferentes protocolos de control de compresión (CCP). Este problema ya está corregido, pero si estás usando una versión antigua de disable pred1 Ppp se bloqua al abrir un shell de test

Cuando ejecutas el comando Si quieres ejecutar comandos como este, usa el comando Ppp sobre un cable null-modem no funciona

No hay manera que enable lqr

LQR es aceptado por defecto si es negociado por el remoto. ¿Por que llama sin motivo el ppp en modo -auto?

Si Para determinar la causa, usa la siguiente línea: set log +tcp/ip

Esto guardara todo el tráfico que pase a través de la conexión. La próxima vez que se realice una llamada no deseada, podrás ver la causa convenientemente guardada.

Ahora puedes desactivar las llamadas producidas por esa causa. Usualmente, este tipo de problemas se debe a consultas de DNS. Para prevenir que las consultas de DNS puedan establecer conexiones usa la siguiente línea (esto no hará que los paquetes de DNS queden parados cuando la conexión está establecida): set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0

Esto no siempre es aconsejable, ya que puede afectar a la capacidad de realizar conexiones bajo demanda - muchos programas necesitan hacer una consulta al DNS antes de poder realizar cualquier operación.

En el caso del DNS, deberías determinar que es lo que está intentando realizar esas consultas de DNS. Muchas veces, es el culpable. Debes asegurarte configurar el sendmail de manera que no realice ninguna consulta al DNS. Mira la sección 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 define(`confDELIVERY_MODE', `d')dnl

Esto hara que sendmail encole todo el correo hasta que no se procese la cola (usualmente, sendmail es invocado con "-bd -q30m", indicandole que procese la cola cada 30 minutos) o hasta que se ejecuta el comando "sendmail -q" (por ejemplo, desde el fichero ppp.linup). ¿Qué significan estos errores CCP?

Sigo viendo los siguientes errores en el fichero de log: CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6)

Esto es porque ppp está intentando negociar compresión Predictor1, y el remoto no quiere negociar ningún tipo de compresión. Estos mensajes son sin importancia, pero si quieres eliminarlos, puedes desactivar la compresión Predictor1 localmente: disable pred1 PPP se cuelga durante transferencia de ficheros con errores I/OP

En la versión FreeBSD 2.2.2 y anteriores, había un problema en el driver tun que no permitía paquetes entrantes con un tamaño mayor que el MTU del interface. La recepción de un paquete mayor que el MTU resulta en un error IO que es logueado vía syslogd.

La especificación PPP dice que un MRU de 1500 siempre debería ser aceptada como mínimo, a pesar de lo que se negocie mediante LCP, de todas maneras, es posible que hayas disminuido el MTU por debajo de 1500 y tu proveedor te esté enviando paquetes de 1500, haciendo que tu conexión se bloquee.

El problema puede solucionarse haciendo que el tamaño del MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores. ¿Por que ppp no loguea la velocidad de la conexión?

Para loguear todas las líneas de "conversación" de tu módem, debes activar la siguiente opción: set log +connect

Esto hará que loguee todo hasta la última cadena "expect" pedida.

Si quieres ver la velocidad de tu conexión y usas PAP o CHAP (y por lo tanto no tienes nada que "chatear" después del CONNECT en el script de marcado), debes estar seguro de indicarle al ppp que espera la línea "CONNECT con algo como esto: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Aquí, tenemos nuestro CONNECT, enviamos nada, y esperamos un salto de línea, forzando al Ppp ignora el carácter `\' en mi chat script

PPP lee cada línea de los ficheros de configuración para poder interpretar cadenas como Cuando el intérprete lee cada argumento, reinterpreta el argumento para buscar alguna secuencia especial de escape como ``\P'' o ``\T''. Como resultado de esta doble lectura, recuerda que has de usar el número correcto de escapes (contrabarras).

Si quieres enviar un caracter ``\'' a tu módem, necesitas hacer algo como: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

resultando en la siguiente secuencia: ATZ OK AT\X OK

o set phone 1234567 set dial "\"\" ATZ OK ATDT\\T"

resultando en la siguiente secuencia: ATZ OK ATDT1234567 Ppp produce un seg-fault, pero no veo el fichero

Ppp (o cualquier otro programa de este tipo), nunca deberían hacer un core dump. Por que ppp funciona con un id de usuario 0, el sistema operativo no escribirá la imagen del core en disco. Si ppp termina con errores de "segmentation violation" o cualquier otra señal que normalmente causa un core dumped, y quieres poder hacer un debug de ese core, asegúrate de usar la última versión de ppp, y haz lo siguiente: $ tar xfz ppp-*.src.tar.gz $ cd ppp*/ppp $ echo STRIP= >>Makefile $ echo CFLAGS+=-g >>Makefile $ make clean all $ su # make install # chmod 555 /usr/sbin/ppp

Ahora tendrás instalada una versión "debuggable" de ppp. Tendrás que ser root para poder ejecutar ppp ya que todos sus privilegios han sido revocados. Cuando arranques ppp, acuerdate del directorio en el que te encuentras.

Ahora, cuando ppp recibe una violación de segmentación , creará un fichero core llamado ppp.core. A continuación , deberías hacer lo siguiente: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l .....

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. El proceso que fuerza una llamada en modo auto nunca funciona

Este es un problema conocido cuando El problema era que cuando el programa inicial llama a , el IP del interface tun es asignado al punto final del socket. El kernel crea el primer paquete saliente y establece la conexión. Si, como resultado de la asignación dinámica de IP, la dirección del interface es cambiada, el punto final del socket original será invalido. Los siguientes paquetes enviados al remoto normalmente serán descartados. Aun si no lo son, cualquier respuesta no será enrutada hacia la máquina de origen por que la dirección IP de la máquina de origen ha cambiado.

Hay varias maneras teóricas de solucionar este problema. Lo mejor sería que el remoto reasignase la misma IP si fuese posible 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 y el parámetro Otra alternativa (y probablemente la mas eficaz) es implementar una llamada al sistema que cambie todos los sockets de una IP a otra. 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. ¿Porqué muchos juegos no funcionan con el parámetro -alias?

La razón por la que muchos de los juegos no funcionan es por que la máquina externa intentará abrir una conexión o enviar paquetes UDP (no solicitados) a la máquina interna. El software "alias" no sabe que esos paquetes debrín enviarse a la máquina interna.

Para que las cosas funcionen, asegúrate que la única cosa que está funcionando es el software con el que tienes problemas, entonces ejecuta tcpdump en el interface tun del gateway o ejecuta el log tcp/ip del ppp ("set log +tcp/ip" en el gateway.

Cuando arrancas el software que no funciona, deberís ver paquetes que pasan a través del gateway. Cuando algo vuelve del exterior, será rechazado (ese es el problema). Apunta el número de puerto de esos paquetes y cierra el software que no funciona. Haz esto varias veces para comprobar si el número de puerto se repite. Si es así, la siguiente línea en el fichero de configuración del ppp /etc/ppp/ppp.conf hará que las cosas funcionen: alias port proto internalmachine:port port

donde "proto" puede ser "tcp" o "udp", "internalmachine" es la máquina a la que quieres que los paquetes sean enviados y "port" es el número de puerto de destino de los paquetes.

No podrás usar ese software en otras máquinas sin modificar el comando anterior, y ejecutar el software simultaneamente en dos máquinas internas no será posible - después de todo, el mundo exterior está viendo a toda tu red como una sola máquina.

Si los números de puertos no se repiten, hay tres opciones más:

1) Desarrollar el soporte en libalias. Ejemplos de estos "casos especiales" los puedes encontrar en /usr/src/lib/libalias/alias_*.c (alias_ftp.c es un buén prototipo). Esto usualmente supone leer ciertos paquetes salientes conocidos, identificando la instrucción que le indica a la máquina exterior que inicie una conexión con la máquina interna en un puerto específico (aleatorio) y configurar un "ruta" en la tabla de alias para que los paquetes siguientes sepan donde ir.

Esta es la solución más difícil, pero es la mejor y hará que el software funcione con múltiples máquinas.

2) Usar un proxy. La aplicación debe soportar socks5 por ejemplo, o (como en el caso del "cvsup") debería tener una opción "pasiva" que evita que el remoto intente abrir conexiones con la maquina local.

3) Redireccionar todo el tráfico a la máquina interna usando "alias addr". Esta es la solución más sencilla. ¿Ha hecho alguien una lista de puertos útiles?

Todavía no, pero se podría hacer, si hay interés. En cada ejemplo, internal debe ser reemplazado por la dirección IP de la máquina que va a estar jugando. Quake

alias port udp internal:6112 6112

Alternativamente, quizás estés interesado en mirar en el soporte de Quake a través de proxy">. Quake 2

alias port udp internal:27901 27910 Red Alert

alias port udp internal:8675 8675

alias port udp internal:5009 5009 Half Life

alias port udp internal:27005 27015 PCAnywhere 8.0

alias port udp internal:5632 5632

alias port tcp internal:5631 5631 ¿Qué son los errores FCS?

FCS significa show hdlc.

Si tu conexión es mala (o si tu driver serie está rechazando paquetes), verás errores FCS ocasionales. En general no tienes porque preocuparte de ellos. Si tienes un módem externo, asegúrate que el cable está correctamente aislado de interferencias - esto debería erradicar el problema.

Si tu conexión se corta tan pronto como has conectado y ves gran cantidad de errores FCS, puede ser por que ti conexión no es de 8 bits. Asegúrate de que tu módem no está usando control de flujo (XON/XOFF) por software. Si tu conexión de datos debe usar control de flujo por software, usa el comando set accmap 0x000a0000 para indicar al ppp que "escape" los carácteres ^Q y ^S.

Otra razón para ver muchos errores FCS puede ser que el remoto haya dejado de "hablar" close clp (usando el comando term podrás conectar de nuevo con el shell de la máquina remota.

Si no hay nada en el log que indique por que se ha terminado la conexión, deberís preguntar al administrador del sistema remoto porqué ha terminado la sesión. Nada de esto me ayuda - Estoy desesperado !

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 (antes y despues de la conexión) a la lista de distribución , a la lista de o al grupo de news y alguien te ayudará a solucionar los problemas. No puedo crear el dispositivo /dev/ed0!

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 /etc/rc.network 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. ¿Cómo puedo configurar alias de ethernets?

Añade `` como el siguiente: ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff ¿Cómo hago para usar el otro puerto de una 3C503?

Si quieres usar los otros puertos, tendrás que especificar parámetros adicionales en el comando . El puerto por defecto es . Tengo problemas con NFS desde/hacia FreeBSD.

Algunas tarjetas de red son mejores que otras y algunas veces pueden causar problemas con aplicaciones de uso intensivo de red como NFS

Mira la para mas información sobre este tema. ¿Porqué no puedo hacer NFS-mount desde Linux?

Algunas versiones de NFS para Linux solo aceptan peticiones para montar unidades hechas desde un puerto privilegiado; intenta: mount -o -P linuxbox:/blah /mnt ¿Porqué no puedo hacer NFS-mount desde una Sun?

Las estaciones de trabajo Sun con SunOS 4.x solo aceptan peticiones de montar unidades hechas desde puertos privilegiados; intenta mount -o -P sunbox:/blah /mnt Tengo problemas usando ppp contra máquinas NeXTStep.

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: tcp_extensions=NO

Las máquinas Xylogic's Annex también tienen este problema, por lo que tienes que hacer el mismo cambio para conectar con ellas. ¿Cómo activo soporte de IP multicast?

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 Para mas información: 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. ¿Qué tarjetas de red están basadas en el chipset DEC PCI?

Aquí tienes una lista hecha por : 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 ¿Porqué tengo que usar el FQDN para hosts en mi servidor?

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".

Tradicionalmente, esto era permitido por los resolvers BIND BSD. La versión actual de que se incluye en FreeBSD no resuelve abreviaciones de nombres para hosts fuera de nuestro dominio. ``Permission denied'' para todas las operaciones de red.

Si tienes el kernel compilado con la opción Si involuntariamente has desconfigurado el firewall de tu sistema, puedes restaurar la operatibilidad de la red tecleando el siguiente comando como usuario root: ipfw add 65534 allow all from any to any

Para mas información en la configuración del firewall de FreeBSD, mira la sección . ¿Cuanto tiempo retrasa IPFW el tráfico?

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: Poner una regla "established" al inicio para manejar la mayoría de trafico TCP. No pongas ninguna regla allow tcp antes de esta. Pon las reglas más usadas antes de las menos usadas (sin modificar la permisividad del firewall). Puedes ver cuales son las reglas más usadas examinando los contadores de paquetes con la orden ipfw -a l. ¿Cómo puedo redirigir peticiones de una máquina a otra?<(/heading>

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: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp

donde "ftp.foo.com" y "ftp" son la máquina y puerto de destino. ¿Dónde puedo conseguir una herramienta de control de ancho de banda?.

Existen dos herramientas de control de ancho de banda para FreeBSD. es gratis; Bandwidth Manager de es un producto comercial. ¿Porqué aparece "/dev/bpf0: device not configured"?

El driver Berkeley Packet Filter necesita ser activado para ejecutar programas que lo utilizan. Añade esto al fichero de configuración de tu kernel y crea uno nuevo: pseudo-device bpfilter # Berkeley Packet Filter

A continuación, después de rebotar tendrás el dispositivo. Esto puede hacerse entrando en el directorio /dev y ejecutando el siguiente comando: # sh MAKEDEV bpf0

Por favor, mira la para más información sobre la creación de dispositivos.