RDSI COMO
Antonio Verdejo Garc�a,
[email protected]
[email protected]
v0.2, 5 de Julio de 1998.
Este COMO explica c�mo configurar tarjetas pasivas RDSI para conex�
iones de red PPP con Linux (a Internet, servidores...). Describe los
pasos para dar soporte tanto f�sico como l�gico, as� como el m�todo de
conexi�n, con 1 y 2 canales, y con llamada bajo demanda.
______________________________________________________________________
�ndice General:
1. Introducci�n
2. Hardware Soportado - Recomendado
2.1. Modelos de tarjetas pasivas
2.2. Soy muy precavido, y estoy leyendo esto antes de comprar la
tarjeta. �Cu�l recomend�is?
3. Integraci�n f�sica
4. Configuraci�n BIOS
5. Configuraci�n de recursos usados por el dispositivo.
5.1. Dispositivos Plug & Play
5.2. Configuraci�n de dispositivos NO PnP
6. Instalaci�n y configuraci�n de controladores
6.1. Soporte espec�fico a la tarjeta
6.2. Configuraci�n del Kernel
6.2.1. Soporte gen�rico en el kernel
6.2.2. Soporte espec�fico a la tarjeta
6.3. Carga de los m�dulos - comprobaci�n del sistema
7. Instalaci�n y configuraci�n de software de aplicaci�n
7.1. Pero bueno, ��qu� c�mo conectooo?!
7.2. Scripts
7.2.1. rc.isdn para un solo canal
7.2.2. rc.isdn para dos canales
7.2.3. Explicaci�n de los scripts
7.2.4. ip-up
7.2.5. ip-down
8. Problemas Frecuentes
8.1. Al lanzar la conexi�n miro el /var/log/messages y s�lo veo
(una vez tras otra):
8.2. La conexi�n se corta tras un mensaje como:
8.3. Al inicializar el demonio ipppd obtengo el mensaje `` Can't
find usable ippp device'' . �A qu� es debido?
9. Por Hacer
10. Copyright y Propiedad Intelectual
11. Colof�n
11.1. �Y no ten�is nada que agradecer a nadie?
11.1.1. De Antonio Verdejo
11.1.2. De Francisco J. Montilla
12. Anexo: El INSFLUG
______________________________________________________________________
1. Introducci�n
Tanto bajo Linux como bajo cualquier sistema operativo (tal vez con la
diferencia de que Linux har� exactamente lo que le digamos, para bien
o para mal) los pasos l�gicos para hacer uso de cualquier perif�rico,
son los siguientes, del orden m�s f�sico al m�s l�gico:
1. Comprobar que la marca y modelo del dispositivo est�n soportados.
2. Integrar el dispositivo f�sicamente (pinchar la tarjeta o
conectarla, y dem�s conexiones accesorias).
3. Comprobar su integraci�n a nivel hardware: en los casos en que sea
posible, que el ordenador reconozca dicho dispositivo. Por ejemplo,
si el dispositivo es PnP, en BIOS Plug & Pray, aparecer� al
encender el ordenador, en alguna de las fases de testeo.
4. Comprobar / configurar qu� parametros usa (IRQ, Direcciones de
memoria base, etc).
5. Instalar los controladores de acuerdo a dichos par�metros.
6. Instalar el software / utilidades necesarios para el uso efectivo
de dichos dispositivos.
Este proceso debe debe realizarse siguiendo estrictamente dicho orden,
no pasando a la etapa siguiente a menos de que estemos completamente
seguros de haberse llevado a cabo bien la previa. Y se aplica a la
integraci�n de cualquier dispositivo bajo cualquier Sistema Operativo,
si bien no muchos de los que se hacen llamar as� hacen honor a su
nombre como lo hace Linux ;-).
2. Hardware Soportado - Recomendado
Pese a que las conexiones RDSI se pueden llevar a cabo tanto mediante
adaptadores externos como tarjetas pasivas internas, en este documento
nos centraremos en (y recomendamos) las tarjetas pasivas, por
considerarlas una opci�n mejor respecto a adaptadores externos RDSI,
ya que:
1. Su coste es generalmente 5 o 6 veces menor.
2. La diferencia de rendimiento es inexistente.
3. Es independiente de los puertos serie, no afectando al rendimiento
o incluso viabilidad, el tipo de UART que se tenga (esto es muy
importante si pensamos montar una pasarela a Internet con ese viejo
486 que rueda por la oficina).
4. El software y los drivers para las tarjetas pasivas internas
permiten hacer aut�nticas virguer�as, con una perfecta integraci�n,
a diferencia de los m�dems RDSI.
2.1. Modelos de tarjetas pasivas
La gran mayor�a de los modelos que se listan a continuaci�n son
tarjetas internas pasivas. El n�mero de tarjetas soportadas crece casi
con la misma velocidad que se suceden versiones del n�cleo. Tenga en
cuenta que si posee un adaptador externo (Zyxel o USR) el m�todo que
se emplear� ser� el primero descrito en este documento (usando los
scripts levemente modificados que se usan en una conexi�n con un m�dem
anal�gico).
Por fortuna, este tipo de dispositivos suelen ser poco comunes (por su
alto precio y nula diferencia en rendimiento en comparaci�n con una
tarjeta interna, adem�s de no soportar el dial on demand ---llamada
bajo demanda, en adelante DoD--- integrado directamente en el ipppd
que s� soportan los dispositivos ipppX).
En cualquier caso, los problemas de configuraci�n que presentan se
reducen al m�nimo, y pasan por ajustar (en determinados casos) la
cadena de inicializaci�n del gui�n de chat.
Nos centraremos pues, casi en exclusiva, en las tarjetas internas.
La lista est� sacada de los ficheros README.* que acompa�an a la parte
del arbol de fuentes correspondientes al soporte RDSI que modifica un
fichero .tar.gz del que hablaremos m�s adelante en este documento:
� Teles 8.0/16.0/16.3 y compatibles
� Teles 16.3c
� Teles S0/PCMCIA
� Teles PCI
� Teles S0Box
� Creatix S0Box
� Creatix PnP S0
� Compaq ISDN S0 ISA
� AVM A1 (Fritz, Teledat 150)
� ELSA Microlink PCC-16, PCF, PCF-Pro, PCC-8
� ELSA Quickstep 1000
� ELSA Quickstep 1000PCI
� ELSA Quickstep 3000 (igual que una QS1000)
� ELSA Quickstep 3000PCI
� ELSA PCMCIA
� ITK ix1-micro Rev.2
� Eicon.Diehl Diva 2.0 ISA y PCI (S0 y U, PRO no soportada)
� Eicon.Diehl Diva Piccola
� ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (c�digo I-IN100-ST-D)
� Dynalink IS64PH (versi�n OEM de ASUSCOM NETWORK INC. ISDNLink 128K
adapter)
� Tarjetas basadas en HFC-2BS0 (TeleInt SA1)
� Sedlbauer Speed Card (Speed Win, Teledat 100)
� Sedlbauer Speed Star (PCMCIA)
� USR Sportster internal TA (compatible Stollmann tina-pp V3)
� ith Kommunikationstechnik GmbH MIC 16 ISA card
� Traverse Technologie NETjet PCI S0 card
� Dr. Neuhaus Niccy PnP/PCI
Notas: PCF, PCF-Pro: por ahora, solo la parte ISDN est� soportada
� PCC-8: sin testear
� Teles PCMCIA es EXPERIMENTAL
� Teles 16.3c es EXPERIMENTAL
� Teles PCI es EXPERIMENTAL
� Teles S0Box es EXPERIMENTAL
� Eicon.Diehl Diva U interface sin testear
� ICN-ISDN-card
� PCBIT
� ISDN ISA SpellCaster
Tenga en cuenta que esta es una lista general. Muchos de los modelos
que aqu� aparecen, no se encuentran en el mercado espa�ol. La mayor�a
de las tarjetas son de origen alem�n. La PCBIT es un "honrosa"
excepci�n: est� fabricada en Portugal.
De las tarjetas distribuidas por Telef�nica y manufacturadas por
Alcatel (si no recordamos mal), las infames SPC-2 en cualquiera de sus
versiones (y sobre todo en la primera), ni hablaremos.
Ninguno de los que suscriben tienen noticia (pese a utilizar en parte
de su circuiter�a los chips Siemens) de que alguien haya conseguido
hacerla funcionar bajo Linux. En cualquier caso, su funcionamiento
(bajo un SO que incluya soporte para la misma) deja mucho que desear.
Y como siempre, visita obligada a la documentaci�n que incluye el
c�digo fuente del n�cleo (m�xime si se aventura a usar un kernel de la
serie 2.1) bajo Documentation/isdn para obtener una lista lo m�s
actualizada posible.
2.2. tarjeta. �Cu�l recomend�is? Soy muy precavido, y estoy leyendo
esto antes de comprar la
Como dec�amos en la secci�n ``'', ante todo, tarjetas pasivas internas
(que est�n soportadas, claro est�) frente a adaptadores RDSI externos.
En general, las tarjetas pasivas con circuiter�a Siemens, y
especialmente las que integran el juego de chipsets HSCX e ISAC, dado
que el driver HiSax es el m�s desarrollado y el que m�s empuje tiene.
Teniendo como criterios lo anterior, el rendimiento, la calidad, y la
colaboraci�n que las marcas tienen con Linux en general, y con los
desarrolladores de isdn4linux en particular:
1. ELSA
2. Creatix
3. Resto de tarjetas soportadas
La Creatix PnP es casi equivalente a la Teles 16.3 PnP (-- Ojo, NO la
Teles 16.3c PnP, que pese a estar soportada experimentalmente, no
tiene nada que ver en cuanto a calidad--) , si bien ha sido
desarrollada �ntegramente por Creatix; adem�s de la actitud positiva
de Creatix respecto Linux, a diferencia de Teles.
�Apoye a los fabricantes que apuestan por Linux!
3. Integraci�n f�sica
Aparte de las precauciones con la est�tica, (ag�rrese antes a alg�n
objeto con bastante masa y conexi�n a tierra, como una tuber�a o
radiador, para descargarla) es conveniente familiarizarnos con el
dispositivo, anotar cuando proceda qu� chipset tiene, si tiene o no
jumpers, si es as� para qu� valen, etc.
Aseg�rese de que la tarjeta queda firmemente asentada, m�s de un
problema inexplicable se ha debido muchas veces a esto.
En algunas placas base, especialmente las de 486, no da completamente
igual d�nde se pincha la tarjeta. Familiar�cese con su Placa Base.
Los dispositivos RDSI suelen conectarse mediante cables de pares pin-
a-pin, si bien no es estrictamente necesario que el cable sea de
pares. El conector suele ser un RJ-45, id�ntico a los usados para
redes. Normalmente la tarjeta traer� un cable, pero si no es as�, o
lo necesita m�s largo, con un cable de red UTP corriente valdr�.
Te�ricamente, y en configuraciones del bus pasivo (instalaci�n
telef�nica propiamente dicha) t�picas, el cable puede ser de unos
centenares de metros, si bien no hemos comprobado nunca de forma
pr�ctica este particular.
Una �ltima advertencia, para aquellos que est�n leyendo esto para
instalar en una empresa: los dispositivos RDSI suelen llevarse muy mal
con las centralitas, especialmente con las Siemens.
Si quiere ahorrarse quebraderos de cabeza, malos funcionamientos,
interminables actualizaciones del firmware de la centralita, y en la
mayor�a de los casos, para que simplemente funcione, exija que el bus
pasivo RDSI para la tarjeta sea dedicado y directo. Se ahorrar�
infinidad de problemas, y el funcionamiento ser� el que un entorno de
producci�n exige.
4. Configuraci�n BIOS
La mayor�a de las tarjetas de hoy en d�a son Plug & Play, y esto,
aunque parezca mentira, en BIOS con PnP es a veces una ventaja; la
mayor�a de ellas muestran al arrancar los dispositivos PnP que han
encontrado, por lo que si �ste es su caso, y no le aparece nada, puede
tener la absoluta certeza de que para el ordenador es como si no
existiese. En algunas placas, hay que especificar qu� recursos se
dejan para asignar a los dispositivos PnP.
En el resto de los casos, en combinaciones de placas / dispositivos no
Plug & Play, puede ser necesario efectuar alg�n retoque en la BIOS,
por ejemplo, si nuestra BIOS es PnP, pero el dispositivo no,
posiblemente deba reservar recursos y/o asignarlos en la BIOS para �l.
5. Configuraci�n de recursos usados por el dispositivo.
5.1. Dispositivos Plug & Play
Bajo Linux, y mientras se trabaja en un soporte directo en el kernel
para este "est�ndar", habremos de usar las herramientas del paquete
isapnptools para asignar los recursos precisos al dispositivo. Como su
nombre indica, solo valen para dispositivos PnP ISA, no para los PCI
(que de todas formas, casi siempre han sido PnP en cuanto a enchufar y
listo, no al est�ndar). La mayor�a de los servidores ftp que albergan
contenidos Linux las tienen, as� como las distribuciones Linux m�s
populares.
Para configurar la tarjeta, use el programa pnpdump y vuelque su
salida a un fichero, por ejemplo, a /tmp/isapnp.conf.
Deber� editarlo para reflejar los valores correctos. Una vez hecho
esto, con isapnp /tmp/isapnp.conf tendr� la tarjeta lista.
Luego de haber comprobado que los valores son correctos, y que la
tarjeta se inicializa correctamente, guarde el fichero
definitivamente, en /etc/isapnp.conf.
Al arrancar (y suponiendo que haya instalado o tuviera ya instaladas
correctamente las pnptools) los scripts de inicializaci�n se
encargar�n de todo autom�ticamente. En cualquier caso, y si viera que
isapnp no se ejecuta al arrancar el Linux, siempre le queda la
soluci�n de incluirlo en /etc/rc.d/rc.local o similar, o, en el peor
de los casos, ejecutarlo a mano.
El fichero generado por pnpdump del siguiente modo
[root@hal /root]# pnpdump > /tmp/isapnp.conf
y suponiendo que s�lo tenga una tarjeta PnP, una Teles.SO 16.3c PnP en
este caso, si tiene una SoundBlaster PnP, esto estar� al final
generalmente, y ser� similar a esto:
# $Id: pnpdump.c,v 1.8 1997/01/14 21:05:35 fox Exp $
# This is free software, see the sources for details.
# This software has NO WARRANTY, use at your OWN RISK
#
# For details of this file format, see isapnp.conf(5)
#
# Compiler flags: -DREALTIME
#
# Trying port address 0203
# Board 1 has serial identifier 0d 1a 09 0b 44 10 26 27 50
# (DEBUG)
(READPORT 0x0203)
(ISOLATE)
(IDENTIFY *)
# Card 1: (serial identifier 0d 1a 09 0b 44 10 26 27 50)
# TAG2610 Serial No 436800324 [checksum 0d]
# Version 1.0, Vendor version 1.1
# ANSI string -->TELES.S0/16.3c Plug&Play<--
#
# Logical device id TAG2610
# Device support I/O range check register
#
# Edit the entries below to uncomment out the configuration required.
# Note that only the first value of any range is given, this may be
changed if $# Don't forget to uncomment the activate (ACT Y) when happy
(CONFIGURE TAG2610/436800324 (LD 0
# Multiple choice time, choose one only !
# Start dependent functions: priority preferred
# Logical device decodes 16 bit IO address lines
# Minimum IO base address 0x0580
# Maximum IO base address 0x05bc
# IO base alignment 4 bytes
# Number of IO addresses required: 2
# (IO 0 (BASE 0x0580))
# IRQ 3, 4, 5, 9, 10, 11, 12 or 15.
# High true, edge sensitive interrupt (by default)
# (INT 0 (IRQ 3 (MODE +E)))
# Start dependent functions: priority acceptable
# Logical device decodes 16 bit IO address lines
# Minimum IO base address 0x0500
# Maximum IO base address 0x05bc
# IO base alignment 4 bytes
# Number of IO addresses required: 2
# (IO 0 (BASE 0x0500))
# IRQ 10, 11 or 12.
# High true, edge sensitive interrupt (by default)
# (INT 0 (IRQ 10 (MODE +E)))
# Start dependent functions: priority acceptable
# Logical device decodes 16 bit IO address lines
# Minimum IO base address 0x0680
# Maximum IO base address 0x06bc
# IO base alignment 4 bytes
# Number of IO addresses required: 2
# (IO 0 (BASE 0x0680))
# IRQ 10, 11 or 12.
# High true, edge sensitive interrupt (by default)
# (INT 0 (IRQ 10 (MODE +E)))
# Start dependent functions: priority functional
# Logical device decodes 16 bit IO address lines
# Minimum IO base address 0x1500
# Maximum IO base address 0x17fc
# IO base alignment 4 bytes
# Number of IO addresses required: 2
# (IO 0 (BASE 0x1500))
# IRQ 3, 4, 5, 9, 10, 11, 12 or 15.
# High true, edge sensitive interrupt (by default)
# (INT 0 (IRQ 3 (MODE +E)))
# End dependent functions
# Vendor defined tag: 84 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
# Vendor defined tag: 84 06 00 00 00 00 00
# (ACT Y)
))
# End tag... Checksum 0x00 (OK)
Simplemente hay que dejar una de las secciones (IO... ) e (INT...)
eliminando los comentarios, y asegurarse (esto es importante) de
eliminar el �ltimo comentario de la l�nea donde se lee # (ACT Y) para
activar la incializaci�n de la tarjeta con los valores escogidos...
Es conveniente anotar dichos valores, ya que los que tendremos que
utilizar posteriormente (an�telos).
Y ni que decir tiene que no debemos asignarle recursos que ya est�n
siendo usados por otros dispositivos. Familiar�cese con su sistema.
Un cat /proc/interrupts o un cat /proc/ioports le ayudar�,
especialmente antes de instalar la tarjeta en el ordenador, siempre y
cuando todos los dispositivos que tenga su ordenador sean reconocidos
por Linux, ya que los que no lo sean no aparecer�n en los listados y
no podremos saber qu� recursos est�n usando.
Refi�rase a la secci�n ``''.
Un fichero /etc/isapnp.conf, una vez eliminados todos los comentarios
suele tener este aspecto:
(READPORT 0x0203)
(ISOLATE)
(IDENTIFY *)
(CONFIGURE TAG2610/436800324 (LD 0
(IO 0 (BASE 0x0580))
(INT 0 (IRQ 3 (MODE +E)))
(ACT Y)
))
La salida del comando isapnp /etc/isapnp.conf, bien sea a mano o
durante el arranque del sistema, suele ser as�:
[root@hal /root]# isapnp /tmp/isapnp.conf
Board 1 has Identity 0d 1a 09 0b 44 10 26 27 50: TAG2610 Serial No 436800324 [checksum 0d]
5.2. Configuraci�n de dispositivos NO PnP
Se supone que ha le�do, entendido, y llevado a cabo con la absoluta
certeza de haberlo hecho bien, la secci�n ``''.
No conocemos todos los dispositivos NO PnP disponibles en el mercado
que funcionan con Linux. Pero la experiencia muestra que generalmente,
para su configuraci�n tiene las siguientes opciones:
� Usar alguna utilidad, generalmente bajo DOS o Windows.
� Usar Jumpers del dispositivo si los tiene
� Usar una utilidad para linux (en contad�simas ocasiones)
Normalmente, la m�s c�moda y fiable es la de los jumpers, ya que no
deberemos preocuparnos de si los reset borran la configuraci�n o no,
aunque en algunas tarjetas (Teles.SO 16.3 NO PnP por ejemplo) s�lo
posibilitan la asignaci�n de IOs. (Ojo, con esta tarjeta, son unos
microrruptores muy peque�os, generalmente con un poco de grasa por
encima).
En el primer caso, si son utilidades DOS, siempre podremos arrancar
con ese disquete antediluviano que rueda por el caj�n, y configurar.
Si es windows, y se tiene instalado tambi�n, tal vez tras unas
encomiendas a San Pancracio, si Murphy est� distra�do, y la suerte
est� de nuestro lado, consigamos convencerla de que use los recursos
que queremos.
En sistemas en los que afortunadamente no est� instalado, siempre
podemos probar a pincharla en uno que s� lo tenga, configurarla, y
volverla a pinchar en el sistema Linux, si bien no siempre funciona.
Otra posibilidad, si la suerte acompa�a, es comprobar (la mayor parte
de las veces mediante ensayo-error, y no siempre con absoluta certeza,
aunque un vistazo a la documentaci�n de la tarjeta ayuda bastante)
qu� par�metros por defecto tiene el dispositivo de f�brica, y usarlos,
siempre que no entren en conflicto con otros que ya tengamos
instalados; si es as�, dependiendo de dichos dispositivos puede ser
hasta m�s c�modo reconfigurarlos y dejar hueco al nuevo inquilino.
Recuerde (incluso anote, insistimos) qu� par�metros va a usar. Los
necesitar� m�s adelante.
6. Instalaci�n y configuraci�n de controladores
Los controladores son el software que hace funcionar al dispositivo, y
que da soporte l�gico al Sistema Operativo para interactuar con �l. En
Linux la integraci�n de este soporte se lleva a cabo configurando y
compilando el n�cleo o kernel, con lo que obtenemos un coraz�n del
Sistema Operativo a la medida de cada m�quina.
Linux ofrece la posibilidad de compilarlo �ntegro en el kernel o en
m�dulos aparte, que se cargan seg�n los necesite el sistema o no. Si
no est� familiarizado con todo esto, es momento de que lea el Kernel-
Como, disponible en el Insflug
http://www.insflug.org.
El kernel necesitar� tener dos tipos de soporte; uno gen�rico, (m�dulo
isdn) y otro espec�fico a la tarjeta (hisax, etc).
Como algunas tarjetas RDSI, especialmente las que tienen soporte
experimental, s�lo funcionan con controladores espec�ficos modulares,
nos centraremos en este tipo de soporte, por ser m�s universal.
No obstante, en los ejemplos supondremos que hacemos uso de kernels
estables (2.0.xx), aunque tengamos que parchearlos. Puede usar kernels
de desarrollo si lo prefiere, tan s�lo t�ngalo en cuenta en los
ejemplos que aplique y modif�quelos en consecuencia, sin olvidar que
estos kernels son para lo que son, desarrollo, no siendo muy id�neos
para la instalaci�n por primera vez de algo que se desconoce.
6.1. Soporte espec�fico a la tarjeta
Antes de continuar, suponemos que ha le�do la secci�n ``'' y que sabe
a ciencia cierta que su tarjeta est� soportada.
Si no parece estarlo, es conveniente que lea (s�, bueno, relea ;-) de
todos modos la documentaci�n que hay en
/usr/src/linux/Documentation/isdn que siempre estar� m�s actualizada
que este Como. Si no, no est� todo perdido; obtenga el �ltimo �rbol de
desarrollo de
ftp://ftp.suse.com/pub/isdn4linux/v2.0/isdn.tar.gz y
eche un vistazo a los ficheros de isdn/Documentation/isdn/, puede que
se lleve una grata sorpresa.
Si su tarjeta est� soportada en la distribuci�n est�ndar del kernel
actual (2.0.34 a d�a de hoy), salte a la secci�n ``''. Si necesita
parchear, siga leyendo.
Para a�adir soporte al kernel actual, integraremos una parte del �rbol
de fuentes modificada, que a�ada soporte para la misma. Obtenga el
fichero
ftp://ftp.suse.com/pub/isdn4linux/v2.0/isdn.tar.gz, suele ser
un enlace simb�lico a la �ltima versi�n del �rbol de desarrollo RDSI
disponible.
No obstante... el soporte es experimental. Casos t�picos son los de
las �ltimamente disponibles popularmente Teles.SO 16.3c o las Asuscom.
Los que suscriben no han visto nada anormal (cierto es que el tiempo
de que hemos dispuesto para testearlas ha sido breve) y tienen
noticias de varios servidores de los llamados de producci�n que est�n
funcionando sin problemas con kernels estables y estas tarjetas.
No obstante, no se parchea en el sentido estricto, ya que lo �nico que
se sustituye es la parte correspondiente a RDSI.
La parte del �rbol modificada lleva un fichero llamado std2kern que
hace el trabajo de parcheo por nosotros, siempre y cuando
/usr/src/linux sea el directorio donde residan las fuentes de linux.
Aseg�rese de que exista; si en su sistema el directorio se llama
/usr/src/linux-2.0.33, compruebe, y en su ausencia cree un enlace al
mismo llamado linux; por ejemplo:
cd /usr/src ;
ln -s linux-2.0.33 linux
Descomprima el �rbol de fuentes isdn: suponiendo que ha dejado el
fichero en /tmp:
( cd /usr/src; tar zxvf /tmp/isdn.tar.gz )
Acceda a /usr/src/isdn, y ejecute el comando std2kern -d:
cd /usr/src/isdn
no olvide el "./" para dar el path directo al fichero, en la mayor�a
de los sistemas el directorio actual no est� en el PATH por seguridad.
Compruebe que no se producen mensajes de error. Si es as�, averig�e
qu� sucede. Lo m�s t�pico es que se haya equivocado en la elecci�n de
fichero, y haya escogido uno para un kernel de otra versi�n (2.1.xx
por ejemplo).
6.2. Configuraci�n del Kernel
Una vez hemos llevado a cabo los pasos anteriores procederemos a la
configuraci�n y posterior recompilaci�n del kernel. Si no est�
habituado a esto, l�ase primero el Kernel-Como, disponible en Insflug,
vea secci�n ``INSFLUG''.
Acceda a /usr/src/linux y ejecute su m�todo preferido de
configuraci�n. Aseg�rese de activar, en la secci�n principal, Code
maturity level options el apartado Prompt for development and/or
incomplete code/drivers, o de lo contrario, el programa de
configuraci�n no le dar� opci�n a seleccionar controladores
experimentales.
Una vez hecho esto, seleccione:
6.2.1. Soporte gen�rico en el kernel
Vaya a la secci�n ISDN subsystem del men� principal:
� ISDN support como m�dulo (M).
� Support synchronous PPP
� Support generic MP (RFC 1717) (potestativo, necesario para canales
m�ltiples)
� Support audio via ISDN (potestativo)
Esto es para cuanto a soporte RDSI se refiere. En cuanto a soporte
PPP, cuestiones espec�ficas de redes, y dem�s aspectos, recurra al
Como apropiado.
6.2.2. Soporte espec�fico a la tarjeta
En la secci�n ISDN subsystem del men� principal, active el controlador
que d� soporte a su tarjeta. El m�s popular es el HiSax, si ese es su
caso, deber� adem�s especificar:
� Protocolo a soportar: en nuestro caso, HiSax Support for EURO/DSS1
y
� Cu�l de la familia de tarjetas soportadas por �l es la suya; si por
ejemplo es la veterana Teles.SO 16.3 NO PnP, la PnP, o la pcmcia
(NO la 16.3c OJO) seleccionar�a HiSax Support for Teles 16.3 or PNP
or PCMCIA.
De nuevo, no conocemos ni podemos conocer todas las tarjetas
soportadas por Linux. Es posible que en drivers experimentales haya
que indicar alguna otra opci�n; recurra a su sentido com�n, a la
documentaci�n (a la que no nos cansaremos de remitirle; este documento
no es m�s que una gu�a) y a nosotros, a fin de actualizar este Como.
Salga del men� guardando los cambios, y compile; no olvide el make
modules y el make modules_install, y reinstalar el LILO para dicho
kernel.
Para m�s informaci�n de c�mo recompilar el kernel, v�ase el Kernel-
Como, disponible en el Insflug, vea secci�n ``INSFLUG''.
6.3. Carga de los m�dulos - comprobaci�n del sistema
Ya he recompilado, instalado los m�dulos, y arrancado con el nuevo
kernel. Adem�s, he usado isapnp y todo parece haber ido bien... �Qu�
hago ahora?
Se ha ganado un descanso. T�mese algo... ;-) No, en serio. Ahora viene
la parte m�s interesante.
Hay varias formas de cargar los m�dulos, en cualquier caso, la manera
que nunca falla es hacerlo a mano directamente desde la l�nea de
comandos. Supondremos que hacemos uso del soporte espec�fico HiSax.
La sintaxis del m�dulo hisax es la que sigue, si bien es conveniente
leer (al final lo conseguiremos ;-), especialmente en drivers
experimentales, /usr/src/linux/Documentation/isdn/README.HiSax.
modprobe hisax type=<codigo tarjeta> protocol=<protocolo> io=<direccion E/S> irq=<interrupcion>
Ha llegado el momento de echar mano de donde tuviera anotados (�los
anot�?) los par�metros que asignara en las secciones ``'' y ``''.
Suponiendo que se trate de la tarjeta Teles.SO 16.3c PnP, que al fin y
al cabo, fue la causante en origen de este Como:
modprobe hisax type=14 protocol=2 io=<IO> irq=<IRQ>
Por ejemplo:
modprobe hisax type=14 protocol=2 io=0x0580 irq=11
con lo que si miramos en /var/log/messages deber�amos ver algo como:
Jun 23 12:05:11 hal kernel: HiSax: Driver for Siemens chip set ISDN cards
Jun 23 12:05:11 hal kernel: HiSax: Version 2.8
Jun 23 12:05:11 hal kernel: HiSax: Revisions 1.15.2.8/1.10.2.5/1.10.2.3/1.30.2.6/1.8.2.5
Jun 23 12:05:11 hal kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
Jun 23 12:05:11 hal kernel: HiSax: Teles 16.3c driver Rev. 1.1.2.2
Jun 23 12:05:11 hal kernel: teles3c: defined at 0x580 IRQ 3 HZ 100
Jun 23 12:05:11 hal kernel: teles3c: resetting card
Jun 23 12:05:11 hal kernel: Teles 16.3c: IRQ 11 count 0
Jun 23 12:05:11 hal kernel: Teles 16.3c: IRQ 11 count 1
Jun 23 12:05:11 hal kernel: HiSax: DSS1 Rev. 1.16.2.3
Jun 23 12:05:11 hal kernel: HiSax: 2 channels added
Jun 23 12:05:11 hal kernel: HiSax: module installed
El tipo 14 es el que se corresponde con la Teles 16.3c PnP, el
protocolo 2 es el usado en Espa�a para las conexiones RDSI, EURO ISDN
o EDSS1. Los otros dos valores (direcci�n de E/S e interrupci�n)
depender�n de su configuraci�n particular, que anot� en su momento,
�verdad?
Dependiendo del driver, este puede que se cargue aun con par�metros
err�neos, si bien no es el caso del HiSax, que rehusar� a hacerlo.
Si sospechamos que pese a haberse cargado (repetimos, no en el caso
del HiSax) hay por ejemplo conflictos de IRQ, o no est� usando la que
le hemos asignado, un indicador claro de esto es que al hacer un
cat /proc/interrupts
0: 9719062 timer
1: 342221 keyboard
2: 0 cascade
4: 495989 + serial
10: 1591809 ICN
12: 681 eth0
13: 1 math error
en un sistema con una tarjeta ICN la l�nea correspondiente a la irq
usada por el controlador contase con 0 interrupciones de contador
(segunda columna). Esto aplica para todos los dispositivos; si la
l�nea
10: 1591809 ICN
fuese
10: 0 ICN
ser�a un claro s�ntoma de que el driver ICN no est� usando dicha
interrupci�n, casi seguro por fallo de configuraci�n. Tan s�lo por
cargar correctamente, debe de poner el contador a 1 al menos.
Llegados a este punto, respire profundamente y si�ntase todo un gur�
Linuxero... ;-) Ya casi est� listo; para no tener que hacerlo en un
futuro a mano, y suponiendo que tiene las modutils correctamente
instaladas, edite o cree su /etc/conf.modules o /etc/modules.conf e
inserte las siguientes l�neas, (suponiendo que use por ejemplo una
Teles 16.3 NO PnP/ con la IRQ 10 y la io 0x180 :
alias isdn hisax
options hisax type=3 protocol=2 io=0x180 irq=10
ejecute depmod -a para computar/actualizar las dependencias entre
m�dulos; de ahora en adelante un modprobe hisax bastar�.
7. Instalaci�n y configuraci�n de software de aplicaci�n
Mi tarjeta parece que ya est� lista. �Puedo usar los scripts de
conexi�n a Infov�a que usaba hasta ahora?
No tal cual; necesitar� hacer ciertas modificaciones. Usaremos otro
m�todo para conectarnos a iNET. En vez de usar el pppd as�ncrono de
toda la vida, usaremos un pppd especial, s�ncrono, que permite algunas
lindezas: el ipppd.
Arranque su cliente ftp favorito, y dir�jase a
ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4linux*.tar.gz que es el
sitio oficial del ISDN4Linux. Ah� tiene una m�gnifica (aunque algo
falta de actualizaci�n) FAQ en un perfecto ingl�s que deber�a tener al
menos como punto de referencia.
Le remitir�amos a ella, pero si ha llegado hasta aqu� y hacemos eso
igual empezamos a sentir agudos pitidos en los oidos... ;-)
Descomprimimos, configuramos, compilamos e instalamos. De la lista de
utilidades las que m�s nos interesan, son isdnctrl (directorio isdn) y
el ipppd (directorio ppp4i4k/ipppd/version) porque son las que
usaremos en el m�todo que describiremos despu�s.
Normalmente, casi todas las distribuciones suelen llevar un paquete de
utilidades RDSI que incluyen los programas que mencionamos, am�n de
abundante documentaci�n y scripts de ejemplo. Busque en su
distribuci�n favorita.
No obstante, si por alguna raz�n no consigue compilar los elementos
necesarios, en
ftp://ftp.insflug.org/pub/RDSI/ tiene a su disposici�n
el software m�nimo necesario ya compilado.
Como en todo sistema UN*X la comunicaci�n con los dispositivos f�sicos
(tarjetas, discos...) se realiza por medio de ficheros. Necesitaremos
crear los dispositivos que har�n que el kernel pueda trabajar con la
tarjeta RDSI. Si usa un paquete de una distribuci�n es casi seguro que
crear�, si no lo est�n ya, las entradas necesarias en el directorio
/dev, si no es as�, ejecute make devices en el directorio ra�z de las
isdn4utils que baj� antes, ser� sufiente.
7.1. Pero bueno, ��qu� c�mo conectooo?!
Vamos con ello. Dos m�todos, uno de ellos mencionado someramente. Se
basa en aprovechar los scripts de conexi�n (que suponemos le
funcionan) usados con un m�dem anal�gico normal. Las variaciones son
m�nimas. A�ada en el gui�n de chat la cadena de inicio
ATS14=3&xxxxxxxxx (siendo xxxxxxxxx el numero de su linea RDSI)
y sustituya donde corresponda el dispositivo /dev/modem por
/dev/ttyI0. Usaremos el pppd normal y corriente que us�bamos antes con
el m�dem. Nada m�s que decir de este m�todo, salvo que no haga uso del
par�metro +ua en el fichero options, est� obsoleto en las �ltimas
versiones del paquete pppd. .
El segundo hace uso de las utilidades que nos bajamos anteriormente, y
nos permitir� conseguir llamadas bajo demanda (dial on demand, DoD).
Opci�n �sta muy interesante en redes donde se vaya a usar la conexi�n
RDSI para dar servicio iNET, por medio del enmascaramiento IP, a
varios puestos de una red local, pues posibilitar� el que la llamada
se efect�e autom�ticamente por tr�fico de paquetes (abrir un
navegador, lanzar el programa de correo, hacer un ping, etc.).
La parte m�s importante de este m�todo reside en los scripts usados
para configurar la conexi�n. Los hay de m�ltiples formas, m�s o menos
"sofisticados". Los incluidos en este documento puede que no sean para
ganar un Nobel, pero funcionan bastante bien. En este sentido, estamos
abiertos (no hace falta decirlo) a modificaciones y/o comentarios,
pero de eso hablaremos m�s tarde.
Unos puntos a destacar. Si queremos usar DoD, necesitaremos tener dos
scripts en /etc/ppp tambi�n incluidos, para asegurarnos que la ruta
por defecto apunte siempre a una direcci�n de iNET y al dispositivo
RDSI.
Esto, y, por supuesto, NO tener ninguna ruta por defecto a la(s)
tarjeta(s) de red (ethernet normalmente) que ya tuvi�ramos en nuestro
sistema: el demonio de PPP (pppd o ipppd) no reemplaza la ruta por
defecto, es un problema muy com�n en los grupos de noticias y en los
canales de Linux de IRC.
El s�ntoma es que la conexi�n se establece, pero no podemos salir a
iNET porque no tenemos se�alizado por d�nde hacerlo. No es el
prop�sito de este documento extenderse demasiado en temas de rutado,
pero en condiciones normales, no necesitaremos ruta por defecto,
podemos usar rutas est�ticas; dejaremos que el (i)pppd la establezca
cuando as� sea necesario.
Y ser� uno de los scripts (ip-down) el que se encargar� de que en todo
momento haya una ruta por defecto a iNET por la tarjeta RDSI.
7.2. Scripts
Hace cosa de un mes fueron enviados a la lista de correo (�a�n no est�
suscrito? �a qu� espera? ;-) del SLUG (
[email protected]),
de modo que si est� suscrito y no borra los mensajes, imagino que los
tendr�.
Pero como no todo el mundo est� en dicha lista (y este Como, que duda
cabe, no ser�a tal sin ellos), aqu� van:
7.2.1. rc.isdn para un solo canal
#!/bin/sh
#
# Thanks to Rainer Birkenmaier <
[email protected]>
# Hacked by Antonio Verdejo Garcia <
[email protected]>
# & Francisco J Montilla <
[email protected]>
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
LOCAL_NUMBER="xxxxxxxxx"
REMOTE_NUMBER="xxx"
LOCAL_IP="195.76.154.169" # IP falsa por la que establecer ruta por
# defecto, a fin de que salte el DoD
DEVICE="ippp0"
USER="user@ISP"
isdnctrl addif $DEVICE # Creamos un interfaz nuevo,'DEVICE'
isdnctrl addphone $DEVICE out $REMOTE_NUMBER # Numero al que llamar
isdnctrl eaz $DEVICE $LOCAL_NUMBER # EAZ: el numero de su RDSI
isdnctrl l2_prot $DEVICE hdlc # para PPP sincrono
isdnctrl l3_prot $DEVICE trans #
isdnctrl encap $DEVICE syncppp # encapsulacion de paquetes IP en
# en tramas PPP
isdnctrl huptimeout $DEVICE 300 # tiempo de inactividad tras el que
# desconectar: 300 sec. -> 5min
isdnctrl chargehup $DEVICE off # Colgar antes del siguiente paso
isdnctrl secure $DEVICE on # Aceptar llamadas de numeros
# autorizados solamente
ifconfig $DEVICE $LOCAL_IP
route add -net 195.76.154.0 $DEVICE
route add default $DEVICE
/sbin/ipppd user $USER remotename infovia -d defaultroute noipdefault \
ipcp-accept-local ipcp-accept-remote mru 1500 mtu 1500 lock -bsdcomp -pc -ac /dev/ippp0 &
las �ltimas dos l�neas son una en realidad; puede indicar que se
interprete como una sola tal y como se hace en el script con el \; o
bien ponerlo en una sola l�nea sin retorno de carro.
Aseg�rese de que ipppd est� en /sbin si transcribe tal cual este
script; si no es as�, modifique el path en el script.
Vea la secci�n ``'' para una explicaci�n acerca de qu� par�metros ha
de modificar y una explicaci�n sobre este script.
7.2.2. rc.isdn para dos canales
#!/bin/sh
#
# Thanks to Rainer Birkenmaier <
[email protected]>
# Hacked by Antonio Verdejo Garcia <
[email protected]>
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
LOCAL_NUMBER="xxxxxxxxx"
REMOTE_NUMBER="xxx"
LOCAL_IP="195.76.154.169" # dummy; the IPCP negotiation overwrite it
DEVICE="ippp0"
USER="user@ISP"
# additional for channel bundling:
DEVICE1="ippp128"
isdnctrl addif $DEVICE # Create new interface 'DEVICE'
isdnctrl addphone $DEVICE out $REMOTE_NUMBER # Set outgoung phone-number
isdnctrl eaz $DEVICE $LOCAL_NUMBER # Set local EAZ ..
isdnctrl l2_prot $DEVICE hdlc # for sync PPP: set Level 2 to HDLC
isdnctrl l3_prot $DEVICE trans # not really necessary, 'trans' is default
isdnctrl encap $DEVICE syncppp # encap the IP Pakets in PPP frames
isdnctrl huptimeout $DEVICE 300 # Hangup-Timeout is 300 sec. -> 5 min
isdnctrl chargehup $DEVICE off # Hangup before next Charge-Info
isdnctrl secure $DEVICE on # Accept only configured phone-number
# additional for channel bundling:
isdnctrl addslave $DEVICE $DEVICE1 # Create new slave interface 'DEVICE1'
isdnctrl addphone $DEVICE1 out $REMOTE_NUMBER # Set outgoung phone-number
isdnctrl eaz $DEVICE1 $LOCAL_NUMBER # Set local EAZ ..
isdnctrl l2_prot $DEVICE1 hdlc # for sync PPP: set Level 2 to HDLC
isdnctrl l3_prot $DEVICE1 trans # not really necessary, 'trans' is default
isdnctrl encap $DEVICE1 syncppp # encap the IP Pakets in PPP frames
isdnctrl huptimeout $DEVICE1 300 # Hangup-Timeout is 300 sec. -> 5 min
isdnctrl chargehup $DEVICE1 off # Hangup before next Charge-Info
isdnctrl secure $DEVICE1 on # Accept only configured phone-number
ifconfig $DEVICE $LOCAL_IP
route add -net 195.76.154.0 $DEVICE
route add default $DEVICE
/sbin/ipppd user $USER remotename infovia -d defaultroute noipdefault ipcp-accept-local \
ipcp-accept-remote mru 1500 mtu 1500 +mp lock -bsdcomp -pc -ac /dev/ippp0 /dev/ippp1 &
7.2.3. Explicaci�n de los scripts
Los scripts no necesitan demasiadas explicaciones. Sustituir user e
ISP por su nombre de usuario y el nombre de su proveedor (pepe@arrakis
por ejemplo) y poner los valores adecuados en LOCAL_NUMBER (el n�mero
de su RDSI) y en REMOTE_NUMBER (055 si usa Infov�a).
La direcci�n de LOCAL_IP es una direcci�n falsa, la negociaci�n IPCP
la sobreescribe, pero por una simple raz�n de coherencia, conviene
darle una IP v�lida del rango de su proveedor, y asignarle a ella la
ruta por defecto, (lo mismo se aplica para la direcci�n de red de la
ruta del final del script) esto es necesario para que funcione el DoD.
Las direcciones del ejemplo son de Intercom, pero valen de cualquier
manera (funciona tambi�n usando las mismas con otros proveedores).
Estas direcciones son las mismas que aparecen en los scripts ip-up e
ip-down:
7.2.4. ip-up
#!/bin/sh
/sbin/route del default
/sbin/route add default ippp0
7.2.5. ip-down
#!/bin/sh
/sbin/route del default
/sbin/ifconfig ippp0 down
/sbin/ifconfig ippp0 195.176.154.169
/sbin/route add -net 195.176.154.0 ippp0
/sbin/route add default ippp0
Es posible que alguno de los comandos que aparecen en estos dos
�ltimos guiones sean redundantes. De nuevo, estamos abiertos a
sugerencias.
El rc.isdn de la secci�n ``'' est� preparado para el uso de dos
canales y por lo tanto una conexi�n a 128 Kbps, usando uno de los
canales como esclavo del primero. La opci�n +mp es necesaria en este
caso, adem�s de que haya seleccionado en la compilaci�n del kernel, en
la secci�n general de RDSI, Support Generic MP (RFC 1717). (Compruebe
que exista la l�nea CONFIG_ISDN_MPP=y en el fichero
/usr/src/linux/.config, que es donde se almacena por defecto la
configuraci�n del n�cleo).
Tenga en cuenta que, como es l�gico, pagar� el doble... Aunque esto en
empresas no suele ser un problema, cuidado en casa, o ver� como las
facturas de Telef�nica tienden a infinito... ;-)
Para lanzar manualmente el segundo canal, ejecute isdnctrl addslave
ippp128; colgar� autom�ticamente tras un periodo sin tr�fico,
tardando lo que hayamos especificado en el par�metro huptimeout del
rc.isdn (en segundos).
Con determinados proveedores no se nota demasiado el lanzar el segundo
canal (Arrakis), con otros sin embargo, y tambi�n dependiendo del
origen de nuestro tr�fico, si se nota, y bastante...
Hay un demonio que se encarga de disparar/colgar el segundo canal
seg�n el tr�fico y la saturaci�n que detecte; puede obtenerse de
http://www.compound.se.
En futuras versiones, tendr� secci�n propia; por ahora, si tiene un
trabajo donde permitirse eso, se supone que tendr� nivel como para
manejarse con �l sin problemas.
8. Problemas Frecuentes
8.1. (una vez tras otra): Al lanzar la conexi�n miro el /var/log/mes�
sages y s�lo veo
Apr 15 10:34:08 wanda kernel: ippp0: dialing 0 055...
Apr 15 10:34:08 wanda kernel: ippp0: dialing 1 055...
Apr 15 10:34:08 wanda kernel: ippp0: dialing 2 055...
pero no veo nada m�s, �a qu� puede ser debido?
Es un problema f�sico. Revise la conexi�n del cable tanto en la
tarjeta como en el TR1. Revise la continuidad del cable as� mismo.
C�mbielo en �ltimo t�rmino. Aseg�rese de que su TR1 tiene servicio...
;-) y Aseg�rese de no estar pasando por ninguna centralita.
8.2. La conexi�n se corta tras un mensaje como:
Apr 15 15:58:28 wanda pppd[208]: Could not determine remote IP address
y seguidamente:
Apr 15 15:58:28 wanda pppd[208]: LCP terminated at peer's request
Apr 15 15:58:28 wanda kernel: isdn_net: local hangup ippp0
Apr 15 15:58:28 wanda kernel: ippp0: Chargesum is 0
Apr 15 15:58:28 wanda pppd[208]: Modem hangup
Apr 15 15:58:28 wanda pppd[208]: Connection terminated.
Es un problema bastante com�n debido a que Infov�a (en el supuesto de
que la use para conectar) no nos asigna, ---o no lo hace con
suficiente rapidez--- una direcci�n remota del enlace PPP. Hay un
soluci�n que funciona tanto en conexiones RDSI como RTC que consiste
en pasarle nosotros una direcci�n en el establecimiento de la
conexi�n. En el caso de conexiones v�a RTC (m�dem corriente y
moliente) incluya una l�nea en el /etc/ppp/options tal que:
:172.16.1.96
y deje el par�metro que le indica que, a pesar de todo, aceptaremos la
IP que el extremo nos asigne como remota (ipcp-accept-remote). La IP
que pongamos puede ser cualquiera, pero como siempre, y por seguir una
regla, ponga una de las que normalmente nos asigna Infov�a de su rango
(172.16.x.x por ejemplo).
Gracias a Horacio J. Pe�a por este detalle (el primero al que se lo
leimos en la lista del SLUG).
El caso de conexiones v�a RDSI (sobre todo en el caso de que usemos el
primer m�todo) se puede proceder de la misma forma, pues aunque se le
pasen par�metros al (i)pppd, el demonio leer� el fichero
/etc/ppp/options.
8.3. usable ippp device'' . �A qu� es debido? Al inicializar el
demonio ipppd obtengo el mensaje `` Can't find
Seg�n Frank Meyer, del grupo de desarrollo isdn4linux, se debe a que
al lanzar el ipppd, este calcula un n�mero aleatorio bas�ndose en la
funci�n gethostid() que provoca una resoluci�n DNS, usando para ello
el servidor de nombres que aparezca en /etc/resolv.conf.
Si no tenemos la conexi�n activa, esto l�gicamente no es posible y el
DNS no puede ser alcanzado (y hablamos en el caso general de que no se
disponga de un DNS local, como suele suceder com�nmente).
Para solucionarlo, incluya el nombre de su m�quina (incluido
localhost) en el /etc/hosts con el dominio completo que haya
especificado en /etc/resolv.conf. Hay otra soluci�n basada en un
parche no oficial para evitar este comportamiento por parte del ipppd;
el fichero syncPPP FAQ inclu�do en el directorio de documentaci�n de
las utilidades ISDN ampl�a este tema.
9. Por Hacer
� Por supuesto, integrar los comentarios y sugerencias que nos manden
amablemente en este documento. Realimentaci�n, graciaaas.
� Estudiar el ibod para la gesti�n din�mica de conexiones a 128K por
demanda de tr�fico.
� ToDo lo que se nos vaya ocurriendo... ;-)
10. Copyright y Propiedad Intelectual
El RDSI-Como es Copyright � 1998 Antonio Verdejo Garc�a & Francisco
Jos� Montilla Blanco.
Este trabajo puede ser reproducido en su totalidad o en parte, tanto
de forma impresa como electr�nica, sujeto a las siguientes
condiciones:
1. La notificaci�n del copyright y esta licencia debe preservarse
completa en todas las copias, tanto completas como parciales.
2. Cualquier traducci�n o trabajo derivado debe de ser aprobado por
los autores por escrito antes de su distribuci�n.
3. Si se distribuye el Trabajo parcialmente, deben de incluirse
instrucciones de d�nde obtener la versi�n completa original (en
forma impresa o electr�nica), as� como los medios para conseguirla.
4. Pueden ser reproducidas peque�as porciones como ilustraciones para
revistas o citas para otros trabajos sin esta notificaci�n de
permiso si se cita apropiadamente su procedencia.
11. Colof�n
Y bueno, por ahora esto es todo. Como una primera versi�n que es,
estar� plagada de peque�os (igual otros no tan peque�os) fallos,
incorrecciones y seguro que nos dejamos un mont�n de temas en el
tintero.
Eso s�, como hemos mencionado varias veces, nuestro buz�n de correo
est� abierto a todo tipo de sugerencias, correcciones, dudas (que si
humildemente podemos, intentaremos responder), as� como desinteresadas
donaciones para adquirir otras tarjetas... };) Lo que se os ocurra.
En cualquier caso, prometemos contestar.
11.1. �Y no ten�is nada que agradecer a nadie?
Ufff... Al contrario. No acabar�amos nunca. Pero vamos a intentarlo;
adem�s, es la parte m�s relajada de todo esto.
11.1.1. De Antonio Verdejo
Mi lista es interminable (tengo tanto que agradecer a tanta gente, y
esta es la m�a ;-), pero intentar� ser breve.
Para empezar, a Francisco Jos� Montilla, mi apa�ero, porque fue quien
me introdujo en esto de la RDSI y el Linux, gracias por tus
"SOfritos", y por la paciencia que tienes conmigo y el Quake.
Recuerdos a quien ya sabes. Gracias por todo, de verdad. �Ah!
y vigila tu espalda, un d�a aparecer� por DM4 con un bazoca y... ;-))
A toda la gente del Lucas, Insflug e HispaLinux. Inmejorable trabajo
el vuestro. A la gente de Enred (saludos ZoR) por organizar lo
inorganizable y darle forma de Party.
A Jes�s Fuentes Saavedra, por sus consejos. A Enrique Melero por
id�ntica raz�n. A I�aki Arenaza por estar trabajando tambi�n en el
tema RDSI. A Miguel Armas del Rio, por mantener la (creo) mejor lista
de Linux en castellano. A todos los contertulios de dicha lista por
sus sugerencias y �nimo, �seguid as�!
A Alvaro Villalva (aka unsCAred) por que siempre est� ah� con su
compilador preparado (-- FJM
y su buscador a punto... ;-)
A toda (TODA) la pe�a del canal linux del IRC Hispano (la lista no
tendr�a fin, prometo -prometemos- citaros a todos en una pr�xima
revisi�n de este documento, aunque sea en un anexo exclusivo ;-) por
ser como son, por ser como sois, �maj�simos!... y a las linuxeras, por
tener ese par de... O:-)
A mi hermano David, y en general a toda mi familia, por su apoyo.
Gracias especiales a Isa, Regi y Basi por cuidarme tan bien (�qu�
har�a yo sin vosotras!).
A mis amigos, mis mejores amigos (Jero, Javi, Alberto) porque siempre
se puede contar con ellos, y porque comprenden que a veces pase m�s
tiempo con Linux que con ellos...
A mis amigas, mis mejores amigas. A Bego�a, por todo. A Ana Roc�o, en
la distancia, porque s�.
A N. S. (``no s�'') por su mirada. Siempre. A Alberto (aka Case) por
sus cumplea�os.
A Marc, por la tarjeta que dio el empuj�n definitivo a este Como. Y a
la gente, que, junto a �l (``1 para to2 y to2 para 1''), me hacen
pensar diferente... Are U dudez?
A ``el gremio del cuervo'' por su m�sica (cojonuda) por su directo
(destroyer) y por darme una idea de lo larga que puede ser (y no
cortarme ante ello) una lista de agradecimientos... ;-) Y a Pepe, por
supuesto, por descubrirme este pedaso grupo. Hello man, I am the
Sun...
A tod@s l@s que me dejo (y de l@s que sin duda tendr� noticias).
Y en general, a toda la gente que hace que, cada d�a que me levanto,
no piense como S�neca, que dec�a Ma�ana ser� peor... ;-)
�Gracias!
11.1.2. De Francisco J. Montilla
A mi apa�ero Toni, por compartir esas madrugadas linuxeras, por
tenerme al d�a de lo que pasa en el mundo Linux, y por dejarme
masacrarle al Quake tan generosamente :P.
Y por dejarme sin nadie a quien agradecer. Abusooon!!!!!
A mi mujer, por aguantar estoicamente mis trasnochadas Linuxeras, mi
apegamiento ordenadoril, y animarme todav�a a darle duro a esto.
12. Anexo: El INSFLUG
El INSFLUG forma parte del grupo internacional Linux Documentation
Project, encarg�ndose de las traducciones al castellano de los Howtos
(Comos), as� como la producci�n de documentos originales en aquellos
casos en los que no existe an�logo en ingl�s.
En el INSFLUG se orienta preferentemente a la traducci�n de documentos
breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs.
:) ), etc.
Dir�jase a la sede del INSFLUG para m�s informaci�n al respecto.
En la sede del INSFLUG encontrar� siempre las �ltimas versiones de las
traducciones: www.insflug.org. Aseg�rese de comprobar cu�l es la
�ltima versi�n disponible en el Insflug antes de bajar un documento de
un servidor r�plica.
Se proporciona tambi�n una lista de los servidores r�plica (mirror)
del Insflug m�s cercanos a Vd., e informaci�n relativa a otros
recursos en castellano.
Francisco Jos� Montilla,
[email protected].
