Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Sitios recomendados:
Su estructura es similar a la del X.25 Level 2, con algunas extensiones para hacerlo más
útil al entorno de la radioafición.
El protocolo Rose fue concebido por vez primera por Tom Moulton W2VY, y es una
implementación del X.25 designado para operar con el protocolo AX.25 a nivel de
enlace de datos. También provee un nivel de red. Las direcciones de Rose usan 10
dígitos numéricos. Los primeros 4 son llamados DNIC (Data Network Identification
Code) y son tomados de la recomendación X.121 del apéndice B de la CCITT. Se puede
obtener más información del Servidor Web de RATS.
Alan Cox desarrollo el primer kernel para soporte de AX.25 en Linux. Jonathon Naylor
continuó el desarrollo, agregó soporte para NetRom y Rose y es el actual creador del
código kernel. DAMA fue desarrollado por Joerg, DL1BKE. Baycom y SoundModem
fue agregado por Thomas Sailer. En la actualidad el software AX.25 Utility es
mantenido por multitud de colegas y programadores en la WEB SourceForge.
El código Linux soporta TNC´s en modo KISS y 6PACK , tarjetas Ottawa PI, Gracilis
PacketTwin y otras tarjetas basadas en el Z8530 SCC con el controlador genérico SCC,
y también tanto el puerto paralelo como el serie de los módem Baycom y los serie de los
módem YAM.
Los nuevos drivers SoundModem de Thomas Sailer soportan Soundblaster y tarjetas de
sonido basadas en los chips Crystal, por medio del uso de los drivers estardar de sonido
del Kernel , igualmente las tarjetas de sonido soportadas por Linux.
Para ayudarte a entender como tienes que pensar para configurarlo, en esta sección
describo la estructura básica del AX.25 y como encaja dentro del contexto de la
estructura del Linux.
______________________________________________ |AF_AX25 |
AF_NETROM |
AF_INET|AF_ROSE||=========|===========|=============|=========|
| | | | |
| | | TCP/IP | |
| | |________ | |
| | NET/ROM | | ROSE |
| |____________________|____|_________|
| AX.25 |
|_____________________________________________|
Este diagrama muestra que NetRom, Rose y TCP/IP corren sobre el AX.25, pero que a
nivel de programación de interface, cada uno de ellos es tratado como un protocolo
separado. Cuando escribimos un programa para usarlos, los "AF_" son simplemente
nombres dados a las "Address Family" (Familia de dirección) de cada uno de ellos. Lo
importante de notar es la implícita dependencia de la configuración del AX.25, antes de
configurar los dispositivos NetRom, Rose o TCP/IP.
Este diagrama, es un poco más general que el anterior, trata de mostrar las relaciones
entre las aplicaciones del usuario, el kernel y el hardware. También muestra la relación
con los Sockets aplicaciones de programación de interfaces, los módulos actuales de
protocolos, los dispositivos de trabajo en red del kernel y los manejadores de
dispositivos. Cualquier cosa de este diagrama depende de lo que está bajo de él, y en
general se debe configurar de abajo hacia arriba.
Por ej., si quieres correr el programa CALL,
A partir de la versión 2.2 del Kernel, el AX.25 es totalmente estable. Este documento
supone que estas usando esta o una versión del Kernel posterior, más actalizada.
Cuando escribo este documento va por la 2.4.9.
Las últimas versiones de las herramientas estándares de Linux para AX.25 y NetRom se
encuentran en:
www.tazenda.demon.co.uk/phil/net-tools.
Las viejas utilidades de AX.25 usadas en los Kernel 2.0 y 2.1, está, obsoletas y deben
reemplazarse por los nuevos paquetes alojados en: SourceForge.
• Librerias
• Herramientas
• Aplicaciones
3.1.4 Utilidades APRS.
• APRSD
• APRSDIGI
• 4. Instalando el software AX.25/NetRom/Rose.
• Para que funcione correctamente el soporte AX25, primero hay que configurar y
compilar un Kernel adecuado, luego instalar las utilidades AX25.
# cd /usr/src
# mv linux linux.old
# tar xzvf linux-2.4.9.tar.gz
# cd linux
Lógicamente en la tercera línea hay que poner la versión que tengamos.
• Las opciones marcadas '*' son obligatorias con 'Y' (si).El resto dependerá del
hardware que tengamos. Algunas opciones se comentan mas adelante con mas
detalle, si no las conoces, continua leyendo y luego vuelves otra vez aqui.
• Después de haber completado la configuración del kernel, estas preparado para
proceder a su compilación.
# make dep
# make clean
# make zImage
# make modules
# make modules_install
Los argumentos del comando configure aseguran que los ficheros se instalen en el
directorio /usr en los subdirectorios bin, sbin, etc y man. Si ejecutamos el comando
sin opciones , por defecto nos lo colocara en /usr/local.
En esta situación, tenemos los ficheros de arranque en /usr y /usr/local.
Si estamos seguros que ha sucedido esto, podemos hacer de nuevo make
/usr/local/etc/ax25 con el enlace simbólico a /etc/ax25 reiniciando todo el proceso
de instalación.
En la tabla T1, T2 y T3 están en segundos, el tiempo de IDLE está en minutos. Pero por
favor advertir que los valores usados en la interface sysctl son unidades internas donde
un segundo hay que multiplicarlo por 10, lo que permite una resolución de 1/10 de seg.
Si el valor del TIMER es 0, quiere decir que está desconectado.
Para poner un parámetro, todo lo que has de hacer es escribir el valor deseado en el
correspondiente fichero, por ej. Para verificar y poner la ventana de Rose harias algo
así:
# cat /proc/sys/net/rose/window_size
3
# echo 4 >/proc/sys/net/rose/window_size
# cat /proc/sys/net/rose/window_size
4
Para crear un dispositivo KISS se debe usar el programa kissattach. Simplemente haz lo
que sigue:
Ud. hace esto antes de configurar el AX.25. Los dispositivos que configuras en el
AX.25 son seudos-interfaces-TTY, (/dev/ttyq*), y no el dispositivo serie físico. Los
dispositivos seudos-TTY crean una especie de redireccionamientos o entubados (pipes)
a través de los cuales los programas para hablar con los dispositivos tty hablan con otros
programas destinados a hablar con dispositivos tty. Cada entubamiento tiene un
terminal maestro y otro esclavo. El maestro es llamado generalmente "/dev/ptyq*" y el
esclavo "/dev/ttyq*". Existe una relación de a pares de maestros y esclavos, así el
/dev/ptyq0 es el maestro y /dev/ttyq0 es su esclavo. Siempre debes abrir el maestro
antes de abrir el esclavo. Mkiss es el encargado de dividir un dispositivo serie simple en
dos dispositivos separados.
Ejemplo: si tienes una TNC doble conectada a 9600 bps a un dispositivo físico serie
/dev/ttyS0, el comando es el siguiente:
Esto creará dos dispositivos seudos-tty que aparecerán cada uno como una TNC de
puerto simple. Entonces tratarás a /dev/ttyq0 y /dev/ttyq1 como si fuera un dispositivo
serial común conectado a una TNC. Esto significa que usaras el comando kissattach
exactamente como se describió anteriormente, en cada uno de ellos, en el ejemplo para
los puertos AX.25 llamados port1 y port2. No deberías usar kissattach en el dispositivo
serie real como lo usa el programa mkiss.
El comando mkiss tiene un número de argumentos opcionales que Ud. puede usar, y son
:
-c
-s <velocidad>
-h
Habilita el control por hardware del puerto sere que por omisión está en off. La
mayoría de KISS no lo soportan, pero algunas sí.
-l
6PACK es un protocolo soportado por algunas TNC, es una alternativa al KISS. Se usa
de forma parecida al driver del KISS, usando el comando slattach en vez de comado
kissattach.
Thomas Sailer, a pesar de que todos decian que no funcionaría muy bien, ha
desarrollado soporte Linux para Baycom. Sus driver soportan el puerto serie Ser12, y
los módem de puerto paralelo Par96 y el extendido PicPar. Más información puede
obtenerse del sitio Web: Baycom Web Site.
El primer paso es determinar cual es el i/o y dirección del puerto serie o paralelo en el
cual tienes conectado tu módem Baycom. Cuando los tienes, ya puedes puedes
configurar tu Driver Baycom con ellos.
El Driver Baycom, cuando se configura, crea dispositivos de red llamados: bc0, bc1,
etc.
La utilidad sethdlc te permite configurar el driver con estos parámetros, o, si solo tienes
un módem Baycom puedes especificar los parámetros en el comando de línea insmod
cuando cargas el módulo Baycom.
Para el módem Par96 el el puerto paralelo LPT1: usando la detección por hardware
DCD:
# insmod hdlcdrv
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0
La página man de sethdlc tiene todos los detalles, pero un par de ej. Ilustrarán los
aspectos más importante de la configuración. El siguiente ej. presupone que ya tienes
cargado el módulo Baycom usando:
# insmod hdlcdrv
# insmod baycom
Los parámetros de acceso a los canales de AX.25 son los equivalentes a ppersist,
txdelay y slottime de KISS. Otra vez tienes que usar la utilidad sethdlc para hacer esto.
Configurar el dispositivo bc0 como half dúplex, con txdelay de 200 ms., slottime de 1
ms. y ppersist de 40:
El driver Baycom crea dispositivos estándares de red que puede usar el código del
kernel AX.25 . La configuración es similar a la de una tarjeta PI o PackletTwin.
# ifconfig bc0 up
# axparms -setcall bc0 EA4URE-15
El próximo paso en crear una entrada en el archivo /etc/ax25/axports como harías para
cualquier otro dispositivo. La entrada en el axports se asocia con el dispositivo de red
que has configurado con el Indicativo. La entrada en el archivo axports que tenga el
Indicativo con el cual configuró el dispositivo Baycom, es la que va a usarse para
referirnos a él.
Puedes tratar al nuevo dispositivo AX.25 como a cualquier otro. Puedes configurarlo
para TCP/IP, agregarlo a ax25d o correr NetRom o Rose, como mas te guste.
Thomas Sailer a construido un nuevo driver para el kernel que te permite usar tu tarjeta
de sonido como módem. Conecta tu equipo de radio directamente a la tarjeta de sonido
y haga packet!!. Thomas recomienda como mínimo una 486DX2/66, si quieres usar este
soft, ya que usa el cpu para todo el proceso digital de la señal.
Este driver actualmente emula los módem tipo 1200 bps AFSK, 4800 HAPN y 9600
FSK (Compatible G3RUH ). Las únicas tarjetas soportadas son los modelos
Soundblaster y WindowsSoundSystem y compatibles. Las tarjetas de sonido necesitan
algún tipo de circuitería para ayudar a usar el PTT (PushToTalk), y hay información
sobre esto en La página web de Thomas´s SoundModem PTT. Hay varias posibilidades
como son: detectar la salida de audio desde la tarjeta de sonido, o usar una salida del
puerto paralelo, serial o midi. Hay circuitos de ejemplo en el sitio de Thomas.
Cuando se configura, el driver SoundModem, crea dispositivos llamados: sm0, sm1, etc.
Los Driver SoundModem utilizan los mismos recursos que los drivers de sonido de
Linux. Por lo tanto si quieres usar SoundModem, debes estar seguro de que los
drivers de sonido de Linux no estén instalados. Puedes compilar ambos como
módulos e insertarlos y quitarlos a tu gusto.
Ejemplo: para una Soundblaster con dirección iobase 0x388, irq 10 y DMA 1, hay que
usar:
# setcrystal -s 0x388 -i 10 -d 1
Para una Windows Sound System con dirección base i/o 0x534, irq 5 y DMA 3,
usariamos:
# setcrystal -w 0x534 -i 5 -d 3
El parámetro [-f synthio] es para poner la dirección del sintetizador, y el [-c dma2] es
para poner el segundo canal de DMA para operación full dúplex.
La utilidad sethdlc te permite configurar los parámetros, o, si solo tienes una tarjeta de
sonido instalada puedes usar el comando insmod con los parámetros necesarios cuando
cargas el módulo de SoundModem.
# insmod hdlcdrv
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
Esta no es la mejor manera de hacerlo ya que sethdlc trabaja lo mismo para uno como
para varios.
La página man de sethdlc trae los detalles completos, pero un par de ejemplos aclararan
los aspectos mas importantes de la configuración. El siguiente ejemplo supone que ya
cargaste los módulos SoundModem usando:
# insmod hdlcdrv
# insmod soundmodem
Configurar el driver para soportar una tarjeta WSS como arriba emulando a un módem
compatible G3RUH 9600, como dispositivo sm0 usando el puerto paralelo en 0x378
para el PTT.
Configurar el driver para soportar una tarjeta Soundblaster como arriba emulando a un
módem compatible 4800 HAPN como dispositivo sm1 usando el puerto serie ubicado
en 0x2f8 para el PTT.
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10
dma 1 serio 0x2f8
Configurar el driverr para soportar una tarjeta Soundblaster como arriba emulando a un
módem compatible 1200 AFSK como dispositivo sm1 usando el puerto serie ubicado en
0x2f8 para el PTT.
Los parámetros de acceso a los canales de AX.25 son los equivalentes a ppersist,
txdelay y slottime de KISS. Otra vez usaremos la utilidad sethdlc para hacer esto.
De nuevo vez la página man de sethdlc trae la información completa, pero un ejemplo
ayuda:
Configurar el dispositivo sm0 como full duplex con TxDelay 100 ms., SlotTime 50 ms.,
PPersist 128.
Para que trabaje correctamente el modem con el equipo de Radio, es necesario que los
niveles de audio estén puestos correctamente. Lo mismo para SoundModem. Thomas
ha desarrollado utilidades para hacer este trabajo más fácil y se llaman: smdiag y
smmixer.
Smdiag
Smmixer
Ejemplo: Para arrancar el smdiag en modo "ojo" (eye) para un SoundModem sm0 :
# smdiag -i sm0 -e
# smmixer -i sm0
6.1.5.5.Configurando el kernel para usar un SoundModem.
El driver de SoundModem crea dispositivos de red estándares que puede usar el kernel
AX.25. La configuración es idéntica que para una tarjeta PI o PacketTwin.
# ifconfig sm0 up
# axparms -setcall sm0 vk2ktj-15
Puedes tratar el nuevo dispositivo AX.25 como a cualquier otro. Puedes configurarlo
para TCP/IP, agregarlo a ax25d o correr NetRom o Rose, como te plazca.
Thomas Sailer, ha escrito un driver para SoundModem, para que pueda ejecutarse en
modo usuario, usando los modulos de sonido propios del Kernel, de esta forma
podemos trabajar con las tarjetas de sonido que corren bajo Linux.
YAM es otro modem a 9600 baudios, diseñado por Nico Palermo. La información
sobre los driver para Linux, puede bajarse de http://www.teaser.fr/~frible/yam.html,
mas información de tipo general sobre este modem puede encontrarse en
http://www.microlet.com/yam/.
Este comando configura el primer puerto en la primera tarjeta PacketTwin detectada con
el Indicativo EA4URE-15 y lo activa (up). Para usar el dispositivo lo que necesitas
hacer ahora es agregar una entrada en /etc/ax25/axports con un Indicativo/ssid que
corresponde al citado, y estás listo para continuar.
Joerg Reuter, DL1BKE, ha desarrollado el soporte genérico para tarjetas SCC basadas
en Z8530. Su driver permite configurarlo para soportar un rango de diferentes tipos de
tarjetas y presenta una interface que parece una TNC KISS, de tal modo que la trata
como si fuera una TNC KISS.
Encontrarás muchas versiones. Selecciona la que mejor vaya con tu versión del kernel.
z8530drv-2.4a.dl1bke.tar.gz para 2.0.*
z8530drv-utils-3.0.tar.gz para 2.1.6 o mayor
Los siguientes comandos son los que usarás para compilar e instalar el paquete para el
kernel 2.0.30:
# cd /usr/src
# gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
# cd z8530drv
# make clean
# make dep
# make module # Si quiere construir el driver como módulo
# make for_kernel # Si quiere el driver incluido dentro del kernel
# make install
Si usas "make for_kernel" entonces deberás recopilar el kernel. Para estar seguro que se
ha incluido el soporte para z8530, debes estar seguro de haber contestado "y" a "Z8530
SCC kiss emulation driver for AX.25" cuando te lo preguntan en el "make config".
El driver z8530 SCC se creo para ser lo más flexible posible, para soportar la mayor
cantidad de tarjetas posibles. Esta flexibilidad trae aparejado el costo de una mayor
complicación en la configuración.
# sccinit
La primera sección esta dividida en partes o estrofas, cada estrofa representa un chip
8530. Cada estrofa es una lista de palabras claves con argumentos. Puedes especificar
por omisión en este fichero hasta 4 chips SCC. El #define MAXSCC 4 en scc.c puede
incrementarse si requieres soportar más.
chip
data_a
Esta palabra clave se usa para indicar la dirección del puerto de datos para el
canal "A" del z8530. El argumento es un número hex. Ej. 0x300
ctrl_a
Se usa para indicar la dirección del puerto de control del canal "A" del z8530..
El argumento es un número hex. Ej 0x304
data_b
Esta palabra clave se usa para indicar la dirección del puerto de datos para el
canal "B" del z8530. El argumento es un número hex. Ej. 0x301
ctrl_a
Se usa para indicar la dirección del puerto de control del canal "B" del z8530..
El argumento es un número hex. Ej 0x305
irq
Se usa para indicar el IRQ usado por la SCC 8530 descrita en esta estrofa. El
argumento es un entero. Por ej. 5
pclock
Se usa para indicar la frecuencia del reloj en el pin PCLK del 8530. El
argumento es la frecuencia en número entero de hetz, y por omisión usa
4915200, cuando no le indicamos otra.
board
El tipo de tarjeta que soporta esta SCC 8530. El argumento es una cadena de
caracteres y se permiten los siguientes:
PA0HZP
Tarjeta PA0HZP SCC
EAGLE
Tarjeta EAGLE
PC100
PRIMUS
BAYCOM
scc
Es opcional y se usa para habilitar el soporte para chip extendidos SCC (ESCC)
como los 8580, 85180 y 85280. El argumento es una cadena de caracteres y se
permite "yes" o "no". Por omisión "no"
vector
special
option
BayCom USCC
chip 1
data_a 0x300
ctrl_a 0x304
data_b 0x301
ctrl_b 0x305
irq 5
board BAYCOM
#
# SCC chip 2
#
chip 2
data_a 0x302
ctrl_a 0x306
data_b 0x303
ctrl_b 0x307
board BAYCOM
PA0HZP SCC card
chip 1
data_a 0x153
data_b 0x151
ctrl_a 0x152
ctrl_b 0x150
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
#
#
#
chip 2
data_a 0x157
data_b 0x155
ctrl_a 0x156
ctrl_b 0x154
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
DRSI SCC card
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
Si ya tienes una configuración funcionando para tu tarjeta bajo NOS, entonces puedes
usar el comando gencfg para convertir los comandos del driver PE1CHL del NOS al
formato necesario por el archivo de configuración del driver z8530.
Para usar el gencfg simplemente invóquelo con los parámetros usados para el driver
PE1CHL del NET/NOS. Por ejemplo:
device
speed
clock
dpll
halfdulex normal
external
divider
mode
rxbuffers
txbuffers
Indica el número de buffers de transmisión para los cuales se reserva memoria.
El argumento es un entero, por ej. 8
bufsize
txdelay
persist
slot
tail
fullduplex
wait
min
maxkey
idle
maxdef
txoff
softdcd
slip
6.1.10.4.Usando el driver.
Para usar el driver, trata simplemente a los dispositivo /dev/scc* como si fueran un
dispositivo tty con una TNC KISS conectada a el. Ejemplo: para configurar el kernel de
Linux para red y usar una tarjeta SCC deberías usar algo así:
Ud. también puede usar NOS para adjuntarr (attach)al kernel de la misma manera. Por
ejemplo del JNOS usarías algo así:
# sccstat /dev/scc0
Linux tiene compatibilidad con BPQ Ethernet. Esto te permite correr el protocolo
AX.25 sobre la LAN Ethernet y así usar tus maquinas Linux con otras máquinas BPQ
en tu LAN.
Los dispositivo de red BPQ se llaman "bpq[0-9]". El "bpq0" se asocia con "eth0" y así
sucesivamente.
Para configurar el soporte para BPQ, necesitas configurar el dispositivo ethernet con un
Indicativo AX.25. Los siguientes comandos harán ese trabajo:
Recuerda, de nuevo, que el Indicativo usado aquí debe corresponderse con la entrada en
el archivo /etc/ax25/axports que quieras usar para este puerto.
El BPQ Ethernet usa normalmente una dirección multicast. Linux no, y en cambio usa
la dirección normal de broadcast ethernet. Por lo tanto, el fichero NET.CFG para el
driver BPQ ODI debe modificarse para que se parezca a lo siguiente:
LINK SUPPORT
MAX STACKS 1
MAX BOARDS 1
INT 10 ;
PORT 300 ; to suit your card
FRAME ETHERNET_II
donde:
portname
callsign
baudrate
paclen
Largo máximo del paquete que quieras configurar para ese puerto cuando usa
AX.25 en modo conectado.
window
description
Un ejemplo:
Recuerda que debes asignar Indicativos/ssid únicos para cada puerto AX.25 que crees.
Crea una entrada para cada puerto AX.25 que quieras; esto incluye puertos KISS,
Baycom, SCC, PI, PT y SoundModem. Cada entrada aquí, describe exactamente un
dispositivo de red AX.25. Las entradas en este archivo estan asociadas con los
dispositivo de red mediante su Indicativo/ssid. Esta es una buena razón para requerir un
único Indicativo/ssid.
Este comando pone un camino para EA4URE a través del digi EA5B en el puerto
AX.25 llamado radio.
Aquí creamos una interface AX.25 con una dirección IP 44.136.8.5 y un MTU de 512.
Todavia podrias usar el comando ifconfig para configurar si fuera necesario otros
parámetros.
Si tienes algún otro tipo de interface, usa entonces el programa ifconfig para configurar
la dirección IP y la máscara de red para ese puerto y añadir una ruta o vía a ese puerto,
igualmente como lo harías con cualquier otra interface TCP/IP. El ejemplo siguiente es
para un dispositivo de tarjeta PI, pero trabaja igualmente bien para otro dispositivo de
red AX.25:
# ping -i 5 44.136.8.58
Fijate en que el argumento "-i 5" se usa para indicarle que mande un ping cada 5 seg. Y
no cada 1 seg. como es por defecto.
Donde:
name
callsign
Indicativo que va a usar el tráfico NetRom por este puerto. Advierte que este no
es el Indicativo al que los usuarios se van a conectar para tener acceso a una
interface tipo nodo. ( Esto se verá más tarde). Este Indicativo/ssid debería ser
único y no debería aparecer por ningún sitio en los ficheros /etc/ax25/axports o
/etc/ax25/nrports.
alias
paclen
medida máxima de los paquetes NetRom transmitidos por este puerto.
description
Ejemplo:
Este ej. crea un puerto NetRom conocido para el resto de la red NetRom como
"LINUX:EA4URE-9".
Donde:
axport
min_obs
def_qual
worst_qual
la peor calidad definida para este puerto. Cualquier ruta debajo de este valor será
ignorada.
verbose
determina si en este puerto existirá broadcast de ruteos NetRom completos o
solo broadcast propios.
Ejemplo:
# nrattach netrom
Este comando inicia el dispositivo NetRom (nr0) llamado netrom, configurado con los
detalles del fichero /etc/ax25/nrports.
# /usr/sbin/netromd -i
Este comando crea una ruta a un NetRom vecino como EA4A-9 con una calidad de 120,
esta bloqueada y no se borra automáticamente.
Entonces, para crear un dispositivo nr0 con IP 44.136.8.5, mtu de 512 y configurado
con los detalles del fichero /etc/ax25/nrports para un puerto NetRom llamado netrom,
deberías usar:
# /usr/sbin/nrattach netrom
# ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom EA4URE-9
# route add 44.136.8.5 nr0
Entonces, para cada host IP al que quieras llegar vía NetRom necesitas agregar una
entrada de ruta y arp. Para llegar a un host con IP 44.136.80.4 con dirección NetRom
BBS:EA4BBS vía un vecino NetRom llamado EA4SUT-0 usarás:
Los argumentos del comando nrparms "120" y "6" son los valores de cualidad y
obsolencia de la ruta.
Donde:
nombre
dirección
descripción
Ejemplo:
Advertir que Rose usa el indicativo/ssid configurado por defecto en cada puerto AX25,
a no ser que se especifique otra cosa.
Para configurar otro indicativo/ssid para Rose, debe usarse el comando rsparms:
Este ejemplo hace que linux escuche y use el indicativo/ssid EA4URE-10 en todos los
puertos AX25 configurados para llamadas Rose.
Este comando arranca el dispositivo Rose (rose0) configurado con los detalles indicados
en /etc/ax25/rsports bajo el nombre 'rose'.
Esto agrega una ruta al nodo Rose 5050295502 a traves del puerto AX25 llamado 'radio'
en tu /etc/ax25/axports hacia tu vecino EA4URE.
Puedes puede especificar una ruta con una máscara para captar varios destinos Rose
dentro de una simple entrada. Ej.:
Como vemos el formato es idéntico al del ejemplo anterior, excepto en el /4 . Esto hará
que capture todos los destinos que coincidan con los primeros 4 digitos (5050). Otra
forma de hacerlo es:
Una simple llamada NetRom a un nodo llamado con el alias PUNTAL sería:
OJO: Debes decirle al programa call en que puerto quieres hacer la llamada, ya que
el mismo nodo de destino puede alcanzarse por varios de los puertos que hayas
configurado.
Este archivo parece complicado a primera vista, pero rápidamente descubrirás que es
muy sencillo y práctico, con una pequeña trampa para ti que debes tener muy en cuenta.
Donde:
<port_name>
<peer>
window
T1
T2
Es el tiempo que el software AX.25 espera por otro paquete entrante antes de
preparar una respuesta. Unidades: 1 segundo.
T3
idle
<mode>
provee el mecanismo para determinar cierto tipo de permisos. Los modos son
habilitados o deshabilitados con una combinación de caracteres, cada uno
representando un permiso. Estos caracteres pueden ser tanto en mayúsculas
como en minúsculas y deben estar en un mismo bloque sin espacios.
U/u
V/v
Q/q
N/n
D/d
L/l
*/0
<uid>
<cmd>
<cmd-name>
nombre en texto del programa ejecutado que aparecerá en un ps. Normalmente
igual a <cmd> sin los directorios.
<arguments>
Se necesita una sección como la de arriba para cada interface AX.25, NetRom o Rose
que quieras que acepte conexiones entrantes AX.25, NetRom o Rose.
Hay dos líneas especiales en el párrafo, una comienza con "parameters" y la otra con
"default". Estas líneas son diferentes y cumplen funciones especiales.
La línea "default" actúa, como es obvio, como acepta_todo, de manera que cualquier
conexión sobre la interface <interface_call> que no tiene una regla específica, coincide
con la regla "default". Si no estuviera una regla por omisión, cualquier conexión que no
cumpliera una regla específica sería desconectada inmediatamente sin aviso.
<netrom>
parameters 1 10 * * * * *
NOCALL * * * * * * L
default * * * * * * 0 root /usr/sbin/node node
Este ejemplo dice que cualquiera que intente conectar con el distintivo VK2KTJ-0
escuchado en el puerto AX.25 llamado ´radio´ se le aplicarán las siguientes reglas:
Cualquiera que tenga el distintivo ´NOCALL´será desconectado, (uso del mode ´L´)
La línea parameters cambia dos valores de los por omisión del kernel (Window y T1) y
corre el programa /usr/sbin/axspawn para ellos. Cualquier copia del programa
/usr/sbin/axspawn que corra de esta manera aparecerá como axspawn en un lista ps. Las
dos líneas siguientes dan permiso para dos estaciones.
La última línea es la regla acepta-todo que todo el mundo obtendrá, inclusive VK2XLZ
y VK2DAY usando cualquier ssid diferente de -1. Esta definición pone todos los
parámetros implícitamente y causa que el programa pms se ejecute con una línea de
argumentos indicando que ha sido ejecutado por una conexión AX.25 y que el dueño es
VK2KTJ. (ver "Configurando el pms" para más detalles).
Las últimas dos son para conexiones Rose. La primera para aquella gente que fijó a
´vk2ktj-0´ y la segunda para ´VK2KTJ-1´ en su dirección de nodo Rose. Trabajan de
igual manera. Note las llaves para distinguir que es un puerto Rose.
# /usr/sbin/ax25d
Cuando has hecho esto, la gente debería poder hacer conexiones AX.25 a tu máquina
Linux. Para que arranque automáticamente cada ves que rebote, acuerdate de poner el
comando ax25d en los archivos rc.
Si esta línea termina con +, el usuario deberá teclear return antes de permitir el logeo.
Lo prefijado es no esperar. Cada configuración de host que siga a esta línea, tendrá el
programa axspawn ejecutandose cuando se conectan. Cuando se ejecuta el axspawn,
primero verifica que el argumento pasado sea un indicativo válido, saca el SSID, y
entonces verifica el archivo /etc/passwd para ver si ese usuario tiene cuenta
configurada. Si tiene una cuenta, y la contraseña es "" (null) o + es aceptado, y si hay
una contraseña, se le solicita. Si no hay cuenta habilitada, axspawn puede configurarse
para que cree una automáticamente.
# /etc/ax25/axspawn.conf
#
# permite creación instantánea de cuentas de usuarios
create yes
#
# Si lo de abajo es "no" o cualquier cosa, el usuario guest falla.
# Deshabilitado con "no"
guest no
#
# identificación o nombre de grupo para autocuentas
group ax25
#
# primer identificador de usuario a usar
first_uid 2001
#
# máximo id de usuario
max_uid 3000
#
# Donde agregar el directorio home de los nuevos usuarios
home /home/ax25
#
# shell del usuario
shell /bin/bash
#
# asociar id de usuario con distintivo para conexiones salientes.
associate yes
# indica comentario
create
Si esta puesto a ´yes´ entonces axspawn intentará crear una cuenta de usuario
para todo usuario que se conecte y no tenga una entrada en /etc/passwd.
guest
Nombre a usar para logeo de gente que se conecte y no tiene todavía una cuenta
de usuario y create esta puesto a ´no´. Usualmente es ax25 o guest.
group
Nombre de grupo a usar para cualquier usuario que se conecte y no tenga una
entrada en /etc/passwd.
first_uid
max_uid
home
shell
associate
Hay un par de archivos muy sencillos que debes crear para dar información sobre el
sistema a los usuarios, y también tendrás que agregar una entrada apropiada en el
ax25d.conf para que los usuarios conectados accedan al pms.
Esto simplemente ejecuta el PMS, diciéndole que está conectado a una conexión AX.25
y que el dueño del PMS es EA4URE. Leete las páginas man para conexiones por otros
métodos.
Sustituye este indicativo por el tuyo, y esto arrancará el PMS, diciéndole que usa el
estilo final-de-línea de unix y que el usuario a logear es ea4ure. asi puedes hacer todas
las cosas que un usuario normal puede hacer.
Adicionalmente puedes tratar de que otro nodo se conecte a ti para confirmar que el
ax25d.conf funciona correctamente.
Son programas muy sencillos. No hacen nada con los datos, de manera que solo tienes
que ocuparte del manejo del fin-de-línea.
Arranquemos con un ejemplo de cómo deberías usarlos. Imagina una pequeña red en tu
casa, una máquina linux actuando de gateway de radio y otra máquina, por ejemplo un
nodo BPQ conectado a ella por una conexión ethernet.
Normalmente, quieres que los usuarios de radio puedan conectarse al nodo BPQ,
deberían usar digipeat a través de tu nodo linux, o conectarse al programa de nodo de su
nodo linux y a continuación pedir conexión a través de el. El ax25_call simplifica este
trabajo si se llama desde el demonio ax25d.
Imagínate que el nodo BPQ tiene el distintivo EA4URE-9 y que la máquina linux tiene
el puerto AX.25/ethernet llamado ´bpq´. Imaginemos también que la máquina gateway
linux tiene un puerto de radio llamado ´radio´. Una entrada al /etc/ax25/ax25d.conf seria
algo así:
En el nodo remoto, EA5XXX vera una conección entrante con el distintivo local de
usuario AX25, y sera redirigido via el distintivo del nodo remoto.
La implementación Rose de linux no soporta esta capacidad a traves del kernel, pero
hay dos aplicaciones que cumplen estas funciones : rsuplnk y rsdwnlnk
Configuración típica:
#
{* via rose}
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 ea4ure-
5
#
Con esta configuración, cualquier usuario que establezca una conexión Rose en su nodo
linux con destino a alguien que específicamente no escucha localmente, será convertida
a AX25 por el puerto AX25 llamado 4800 y irá a traves del digipeater EA4URE-5.
#
[EA4URE-5* via 4800]
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose
#
Obseva la sintaxis especial para el indicativo local. El '*' significa que la aplicación será
invocada si se escucha el indicativo en el camino o path como digipiter de una
conexión.
Esta configuración permitirá a un usuario AX25 establecer una conexión Rose usando el
ejemplo de secuencia de conexión presentado en la introducción. Nadie intentando
reconectarse via EA4URE-5 en el puerto AX25 llamado 4800 será manejado a traves
del comando rsuplnk.
Aquí se asocia el indicativo AX.25 ´ea5ar´ con el usuario ´ric´ en la máquina. De tal
manera que un mail para ea5ar en el PMS se mandará a la cuenta Linux ric.
ATENCION Nunca debes asociar un indicativo con la cuenta root ya que puede causar
problemas en otras configuraciones.
Esta sección, la estamos escribiendo. También cubrirá aprsd, aprsmon, xastir, JavAPS,
etc
/proc/net/arp
/proc/net/ax25
/proc/net/ax25_bpqether
/proc/net/ax25_call
Contiene el mapeo de usuario Linux a indicativos AX.25 puestos por el
comando axparms -assoc.
/proc/net/ax25_route
/proc/net/nr
/proc/net/nr_neigh
/proc/net/nr_nodes
/proc/net/rose
/proc/net/rose_nodes
/proc/net/rose_neigh
/proc/net/rose_routes
A pesar de que la Programación de Red bajo Unix está fuera del alcance de este
documento, describiré los detalles elementales de cómo puedes hacer uso de los
protocolos AX.25, NetRom, y Rose dentro de tu software.
Para AX.25:
#include <netax25/ax25.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_AX25
Para NetRom:
#include <netax25/ax25.h>
#include <netrom/netrom.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_NETROM;
Para Rose:
#include <netax25/ax25.h>
#include <netrose/rose.h>
int s, addrlen = sizeof(struct sockaddr_rose);
struct sockaddr_rose sockaddr;
sockaddr.srose_family = AF_ROSE;
Las utilidades user_call son excelentes ejemplos con que trabajar. El código fuente de
ellas está incluido en el paquete de Utilidades AX.25. Si empleas un poco de tiempo
trabajando con ellas, verás rápidamente que el 90 por ciento del trabajo se invierte
preparándose para abrir el socket. Actualmente la conexión es fácil, prepararla lleva
tiempo.
El ejemplo es sencillo para no ser muy confuso. Si tienes alguna pregunta, diríjete
directamente a la lista linux-hams y alguien seguramente te ayudará.
22. Alguna configuración de ejemplo.
A continuación hay ejemplos de las configuraciones mas comunes. Solo son guías, ya
que hay tantas configuraciones posibles como redes de trabajo haya, pero ellas te
enseñaran algo para empezar.
. . . . . .
___ _________ .
| Network / \ . Network
| 44.136.8.96/29| | . 44.136.8/24 \ | /
| | Linux | . \|/
| | | . _____ __________ |
| eth0 | Router | . / \ / \ |
|_______________| |_____| TNC |____| Radio |__/
| 44.136.8.97 | and | . \_____/ \__________/
| | | sl0
| | Server | 44.136.8.5
| | | .
| | | .
| \_________/ .
_|_ . . . . . .
#!/bin/sh
# /etc/rc.net
# This configuration provides one KISS based AX.25 port and one
# Ethernet device.
echo "/etc/rc.net"
echo " Configuring:"
# end
/etc/ax25/axports
/etc/ax25/nrports
/etc/ax25/nrbroadcast
• El uso de los parámetros mss y window significan que puedo obtener el mejor
resultado tanto para la red ethernet como para la de radio.
• También corro en la máquina ruteadora el smail, http, ftp y otros demonios, de
manera que solo necesito esa máquina para facilitar a otros esos servicios.
• Esta máquina es solo un PC 386DX20 con 20Mb de disco duro y una
configuración Linux mínima.
. . . . . .
___ _________ .
| Network / \ . Network
| 154.27.3/24 | | . 44.136.16/24 \ | /
| | Linux | . \|/
| | | . _____ __________ |
| eth0 | IPIP | . / \ / \ |
___|_______________| |_____| TNC |____| Radio |___/
| 154.27.3.20 | Gateway | . \_____/ \__________/
| | | sl0
| | | 44.136.16.1
| | | .
| | | .
| \_________/ .
_|_ . . . . . .
# /etc/rc.net
# Este archivo es una simple configuración que provee un puerto de
radio
# KISS AX.25, un dispositivo ethernet, y utiliza el manejador de
entubado del
# kernel para hacer el encapsulado/desencapsulado IPIP
#
echo "/etc/rc.net"
echo " Configurando:"
#
echo -n " loopback:"
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
echo " done."
#
echo -n " ethernet:"
/sbin/ifconfig eth0 154.27.3.20 netmask 255.255.255.0 \
broadcast 154.27.3.255 up
/sbin/route add 154.27.3.20 eth0
/sbin/route add -net 154.27.3.0 netmask 255.255.255.0 eth0
echo " done."
#
echo -n " AX.25: "
kissattach -i 44.136.16.1 -m 512 /dev/ttyS1 4800
/sbin/ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.16.255
/sbin/route add -host 44.136.16.1 sl0
/sbin/route add -net 44.136.16.0 netmask 255.255.255.0 window 1024 sl0
#
echo -n " tunel:"
/sbin/ifconfig tunl0 44.136.16.1 mtu 512 up
#
echo Hecho.
#
echo -n "Routing ... "
source /etc/ipip.routes
echo done.
#
# end.
y:
# /etc/ipip.routes
# Este fichero ha sido generado usando el script munge
#
/sbin/route add -net 44.134.8.0 netmask 255.255.255.0 tunl0 gw
134.43.26.1
/sbin/route add -net 44.34.9.0 netmask 255.255.255.0 tunl0 gw
174.84.6.17
/sbin/route add -net 44.13.28.0 netmask 255.255.255.0 tunl0 gw
212.37.126.3
...
...
...
/etc/ax25/axports
#!/bin/sh
#
# From: Ron Atkinson <n8fow@hamgate.cc.wayne.edu>
#
#
# Este script es básicamente el script 'munge' escrito por Bdale
N3EUA
# para el demonio IPIP y esta modificado por Ron Atkinson N8FOW. Su
propósito
# es convertir el archivo de rutas de gateway con formato KA9Q NOS
# <usualmente llamado "encap.txt") en el formato de tablas de ruteo
Linux
# para el manejador de entubado de IP.
#
# Uso: archivo Gateway en stdin, archivo con formato de ruteos
Linux en stdout.
# eg. tunnel-munge < encap.txt > ampr-routes
#
# NOTA: antes de usar este script verifica o cambia los
# siguientes ítems:
#
# 1) Cambia la sección "Local routes" y "misc user routes" a rutas
# que correspondan a tu propia área. <borre las mías, por
favor!)
# 2) En la línea fgrep cambia la direccion IP por tu
# direccion IP del gateway a Internet. Si falla causará serios
# loops de rutas o lazos cerrados.
# 3) El nombre de la interface prefijada es 'tunl0'. Verifica que
esto
# es correcto para tu sistema.
echo "#"
echo "# Tabla de ruteos de entubado IP construido por $LOGNAME en
`date`"
echo "# by tunnel-munge script v960307."
echo "#"
echo "# Local routes"
echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0"
echo "#"
echo "# Misc user routes"
echo "#"
echo "# remote routes"
if (mask == "255.255.255.255")
printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\
,n[1],n[2],n[3],n[4],$5
else
printf "route add -net %s.%s.%s.%s gw %s netmask %s dev
tunl0\n"\
,n[1],n[2],n[3],n[4],$5,mask
}'
echo "#"
echo "# prefijado al resto de amprnet vía mirrorshades.ucsd.edu"
echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev
tunl0"
echo "#"
echo "# the end"
Este programa tiene dos modos importantes de operación: modo "digipeater" y modo
"tnc". En modo "tnc" el demonio es tratado como si fuera una tnc KISS, tu le pasas
frames encapsuladas KISS y el los transmitirá, esta es la configuración usual. En modo
"digipeater", tu tratas al demonio como si fuera un digipeater AX.25. Hay sustanciales
diferencias entre estos modos.
• El tty que el demonio ax26ipd abrirá y su velocidad ( usualmente una punta del
entubamiento)
• Que indicativo quieres usar en modo "digipeater"
• Intervalo de la baliza y su texto
• Cuando quieres encapsular los frames AX.25 en datagramas IP o UDP/IP. la
mayoría de los gateway AXIP usan encapsulamiento IP, algunos gateways están
detrás del cortafuegos que no aceptan IP con el id de protocolo AXIP, y son
forzados a usar UDP/IP. Lo que elijas debe de corresponder a lo que el host
TCP/IP de la otra punta del enlace este usando.
#
# archivo de configuración para la estación floyd.vk5xxx.ampr.org
#
# Selecciona transporte axip. "ip" es lo que quieres por la
# compatibilidad con la mayoría de los otros gateways
#
socket ip
#
# Fija el modo de operación del ax25ipd. (digi o tnc)
#
mode tnc
#
# Si seleccionaste digi, debes definir un indicativo. Si seleccionaste
# modo tnc, el indicativo es opcional, pero puede cambiar
# en el futuro! (2 indicativos si usas un puerto kiss dual)
#
#mycall vk5xxx-4
#mycall2 vk5xxx-5
#
# En modo digi, puede usar un alias. (2 para puerto dual)
#
#myalias svwdns
#myalias2 svwdn2
#
# Manda una identificación cada 540 segundos ...
#
#beacon after 540
#
# A continuación el texto de la baliza ...
# text ax25ip -- tncmode rob/vk5xxx -- Experimental AXIP gateway
#
# Puerto serial, o entubado conectado a un kissattach, en mi caso
#
device /dev/ttyq0
#
# Poner la velocidad, en baudios
#
speed 9600
#
# loglevel 0 - ninguna salida
# loglevel 1 - solamente información de configuración
# loglevel 2 - errores y eventos importantes
# loglevel 3 - errores y eventos importantes más seguimiento de frames
AX.25
# loglevel 4 - todos los eventos
# log 0 por el momento, syslog no esta trabajando todavía ...
#
loglevel 2
#
# Si estamos en modo digi, aquí podemos tener una tnc real, por lo
tanto
# usemos param para fijar los parámetros de la tnc ...
#
#param 1 20
#
# Definición de la dirección de broadcast. A todos las direcciones
listadas, les
# serán forwardeadas todas las rutas marcadas como capaces de
broadcast.
#
broadcast QST-0 NODES-0
#
# Definición de rutas AX.25, las que necesites.
# El formato es route (Indicativo/comodín) (ip del host de destino)
# ssid 0, rutea a todos los ssid´s.
#
# route <destcall> <destaddr> [flags]
#
# Banderas válidas :
# b - permite transmisión de broadcast por esta ruta
# d - Esta es la ruta prefijada.
#
route vk2sut-0 44.136.8.68 b
route vk5xxx 44.136.188.221 b
route vk2abc 44.1.1.1
#
#
22.3.3.Corriendo ax25ipd
/usr/sbin/ax25ipd &
Hay dos banderas que puede agregar a cualquier comando de ruta en el fichero
ax25ipd.conf. Estas dos banderas son:
Cualquier paquete que no coincida con ninguna ruta será transmitido por esta
ruta. (default = prefijada)
Ya que tanto Linux como NOS soportan el protocolo slip es posible conectar los dos
creando un enlace slip. Tu lo puedes hacer usando dos puertos serie interconectados con
un cable, pero esto sería costoso y lento. Linux prove un método que otros sistemas
operativos tipo-UNIX proveen y llaman "entubados" o "pipes". Estos son pseudos
dispositivo especiales que estan en el software como dispositivo tty estándares, pero que
en realidad enlazan con otro dispositivo de entubado. Para usar estos entubados, el
primer programa debe abrir la punta maestra del entubado, y entonces el segundo
programa abrir la punta esclava del mismo entubado. Cuando ambas puntas están
abiertas, los programas pueden comunicarse entre ellos simplemente escribiendo
caracteres en el entubado de la misma manera que si fuera un dispositivo terminal.
Para usar esto para conectar el kernel Linux con NOS u otro programa, primero debes
elegir un dispositivo de entubado a usar. Puedes encontrar uno si miras en el directorio
/dev. La punta maestra es llamada: ptyq[1-f] y la esclava: ttyq[1-f]. Recuerda que
vienen en pares, de manera que si seleccionas /dev/ptyqf como maestra, debes elegir
/dev/ttyqf como esclava.
Una ves elegido el par de dispositivo de entubado, debes conectar la punta maestra al
kernel de Linux y la esclava al programa NOS, ya que el Linux arranca primero y la
punta maestra debe de estar abierta primero. Recuerda también que tu kernel Linux debe
tener una dirección IP diferente hacia su NOS, de manera que necesitarás fijar una única
dirección para ello si no lo tienes todavía.
Configuras el entubado como si fuera un dispositivo serie, de manera que para crear un
enlace slip desde tu Linux, puedes usar los siguientes comandos:
# you can call the interface anything you want; I use "linux" for
convenience.
attach asy ttyqf - slip linux 1024 1024 38400
route addprivate 44.70.4.88 linux
Estos comandos crean un puerto slip llamado "linux" a través de la punta esclava del par
de dispositivo de entubamiento conectado al kernel Linux, y una ruta a el para hacerlo
trabajar. Cuando arranques el NOS, podrías hacer un ping o telnet a tu NOS desde tu
máquina Linux y viceversa. Si no lo haces, verifica que no hayas cometido ningún error,
especialmente que tengas las direcciones bien configurados, y que tengas los
dispositivos de entubado correctamente fijados.
rxecho ax25-tools Enruta los paquetes AX.25 por los puertos de forma
transparentey
sethdlc ax25-tools Get/set Linux HDLC información del driver del puerto
modem de packet radio
net2kiss ax25-tools Convertir el driver de la red AX.25 a una flujo KISS tipo
pseudo-tty