RDSI Como 7
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 (
l-linux@calvo.teleco.ulpgc.es), 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:
rc.isdn para un solo canal
#!/bin/sh
#
# Thanks to Rainer Birkenmaier <rainer@kirk.mop.uni.ulm.de>
# Hacked by Antonio Verdejo Garcia <averdejog.galileo@nexo.es>
# & Francisco J Montilla <pacopepe@insflug.org>
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 expl para una explicación acerca de qué parámetros ha de modificar y una explicación sobre este script.
rc.isdn para dos canales
#!/bin/sh
#
# Thanks to Rainer Birkenmaier <rainer@kirk.mop.uni.ulm.de>
# Hacked by Antonio Verdejo Garcia <averdejog.galileo@nexo.es>
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 &
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:
ip-up
#!/bin/sh
/sbin/route del default
/sbin/route add default ippp0
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
isdn2 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.
Anterior Siguiente Indice