"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 Puede una maquina FreeBSD ser usada como router dedicado?

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

Esta opcion pondra la variable 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 , aunque en situaciones mas comlejas quizas quieras usar 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. Puedo conectar mi Win95 con Internet a traves de FreeBSD?

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.

Hay un util documento disponible que explica como configurar FreeBSD como un

y en tu FreeBSD.

Mira tambien la seccion . Por que falla la compilacion del ultimo BIND del ISC?

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

Si. 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", quizas 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 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 . El programa tiene una funcionalidad similar incluida, a traves del parametro -alias. La es usada en ambos casos. El ppp no funciona. Que estoy haciendo mal?

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

Este comando deberia ser tecleado en el prompt del /etc/ppp/ppp.conf (al inicio de la seccion 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 lineas: !ppp *.* /var/log/ppp.log

y que el fichero /var/log/ppp.log existe. Puedes encontrar mucha informacion sobre lo que esta pasando en las conexiones con el fichero de log.

Si tu version de ppp no entiende el comando "set log" deberias bajarte la . Esta compilara sin problemas en FreeBSD 2.1.5 y superiores. PPP no quiere marcar en modo -auto

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

por otra diciendo add 0 0 10.0.0.2

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 /etc/sysconfig) y hayas omitido la linea delete ALL

en el fichero ppp.conf. Si es este el caso vuelve a la seccion en el handbook. Que significa "No route to host"

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

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

Pasate por la seccion del handbook para mas informacion. Mi conexion se corta pasados 3 minutos

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

Donde ppp.conf, 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 o . Leete el man de para mas detalles. Mi coneion se corta en situaciones de carga

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 disable lqr Mi conexion se corta en periodos aleatorios

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.

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: set dial "...... ATS10=10 OK ......"

Mira en el manual de tu modem para mas detalles. No ocurre nada despues del mensaje Login OK

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

Sigo teniendo errores sobre el parametro magic

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.

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.

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.

Esto puede ser resuelto permitiendo que el remoto inicie la negociacion, poniendo la siguiente linea en el fichero ppp.conf: set openmode passive

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: 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 envia peticiones durante este periodo, ppp respondera inmediatamente sin esperar los 3 segundos establecidos. Las negociaciones LCP continuan hasta que se cierra la conexion

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

La mejor manera de evitar esto es configurar una de las partes de manera set openmode passive Se debe tener cuidado con esta opcion. Tambien se puede usar: set stopped N para limitar el numero de veces que set openmode active N donde Ppp se bloquea al conectar

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 disable pred1 Ppp se bloqua al abrir un shell de test

Cuando ejecutas el comando Si quieres ejecutar comando 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 linea: set log +tcp/ip

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.

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): 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 operacion.

En el caso del DNS, deberias determinar que es lo que esta 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 seccion para tener mas detalles acerca de como crear una fichero propio de configuracion de sendmail. Tambien deberias anyadir la siguiente linea 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). Que 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 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: disable pred1 PPP se cuelga durante transferencia de ficheros con errores I/OP

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.

La especificacion PPP dice que un MRU de 1500 siempre 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.

El problema puede solucionarse haciendo que el tamnyo del MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores. Por que no ppp no loguea la velocidad de la conexion?

Para loguear todas las linea de "conversacion" de tu modem, debes activar la siguiente opcion: set log +connect

Esto hara que loguee todo hasta la ultima cadena "expect" pedida.

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: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Aqui, tenemos nuestro CONNECT, enviamos nada, y esperamos un salto de linea, forzando al Ppp ignora el caracter `\' en mi chat script

PPP lee cada linea de los ficheros de configuracion para poder interpretar cadenas como 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).

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

resultado 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 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: $ 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 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.

Ahora, cuando ppp recibe una violacion de segmentacion, creara un fichero core llamado ppp.core. A continuacion, deberias hacer lo siguiente: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l .....

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

Este es un problema conocido cuando , 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.

Hay varias maneras teoricas de solucionar este problema. Lo mejor seria que el remoto reasignase la misma IP si fuese posible 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 y el parametro 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 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.

Ninguna de estas soluciones ha sido implementada (todavia). Nada de esto me ayuda - Estoy desesperado !

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 (antes y despues de la conexion) a la lista de distribucion o al grupo de news y alguien te ayudara 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 codigo del kernel. Por favor, mira el fichero /etc/rc.network 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. Como puedo configurar alias de ethernets?

Anyade `` como el siguiente: ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff Como hago para usar el otro puerto de una 3C503?

Si quieres usar los otros puertos, tendras que especificar parametros 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 informacion sobre este tema. Por que 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 Por que 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 maquinas 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 maquinas Xylogic's Annex tambien tienen este problema, por lo que tienes que hacer el mismo cambio para conectar con ellas. Como activo soporte de IP multicast?

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 Para mas informacion: 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. Que tarjetas de red estan basadas en el chipset DEC PCI?

Aqui tienes una lista hecha por: 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 Por que tengo que usar FQDN para hosts en mi servidor?

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

Tradicionalmente, esto era permitido por los resolvers BIND BSD. La version 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 opcion 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 informacion en la configuracion del firewall de FreeBSD, mira la seccion . Cuanto tiempo retrasa IPFW el trafico?

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: Poner una regla "established" al inicio para manejar la mayoria de trafico TCP. No pongas ninguna regla allow tcp antes de esta. Pon las reglas mas usadas antes de las menos usadas (sin modificar la permisividad del firewall). Puedes ver cuales son las reglas mas usadas examinando los contadores de paquetes con la orden ipfw -a l.