Linux Amateur Radio AX.25 HOWTO

1.1. Modifiche rispetto alla versione precedente

• Questo documento ha un nuovo curatore.

• Il documento è stato convertito nel formato DocBook SGML. La maggior parte delle informazioni tabellari sono state convertite in tabelle.

• Il documento è stato rilasciato sotto licenza GNU FDL.

• Sono state aggiunte nuove informazioni sui driver per Baycom, YAM, 6PACK e soundmodem, in user mode.

• È stata aggiunta una sezione sull'APRS

• Sono stati effettuati diversi altri aggiornamenti poiché l'ultima versione di questo documento risaliva al 1997. Probabilmente ci sono ancora molti errori e diverse informazioni non più valide.

1.2. Dove reperire nuove versioni di questo documento

La fonte migliore è da un archivio del Linux Documentation Project. In particolare il Linux Documentation Project gestisce un server Web nel quale questo documento vi appare come the AX25-HOWTO. Questo documento è inoltre disponibile in vari formati presso il Linux Documentation Project.

[NdT: la traduzione italiana è disponibile presso il sito dell'Italian Linux Documentation Project, reperibile all'indirizzo http://it.tldp.org (oppure http://ildp.pluto.it)]

È sempre possibile contattarmi, ma dato che passo le nuove versioni del documento direttamente al coordinatore del LDP, è probabile che io non sia in grado di darvi versioni complete più aggiornate di quella presente nell'archivio

1.3. Documenti correlati

C'è parecchia documentazione che tratta del networking in Linux in generale e che raccomando calorosamente di leggere poiché sarà di grande aiuto nello sforzo di capire più a fondo l'argomento.

• Linux Networking HOWTO

• Linux Ethernet HOWTO

• Linux Firewall and Proxy Server HOWTO

• Linux 2.4 Advanced Routing HOWTO

• NET/ROM-Node mini-Howto

È possibile che incontriate riferimenti a un documento chiamato HAM HOWTO. Questo documento è obsoleto ed è stato sostituito dall'Hamsoft Linux Ham Radio Applications and Utilities Database. Ulteriori informazioni di carattere generale si possono trovare all'interno di altri Linux HOWTO.

2.1. Come tutto si combina assieme

Quella in Linux è un'implementazione dell AX.25 del tutto nuova. Sebbene assomigli in molti modi a quella di NOS, BPQ o altre implementazioni AX.25, non è uguale a nessuna di queste. L'AX.25 di Linux è in grado di essere configurato in modo tale da poter comportarsi praticamente come le altre implementazioni, ma il processo di configurazione è del tutto diverso.

Per aiutarvi a capire a cosa occorra pensare mentre si effettua la configurazione, questa sezione descrive alcune delle caratteristiche strutturali dell'implementazione AX.25 e come questa si inserisce nel contesto dell'intera struttura di Linux.

Diagramma semplificato dei livelli dei protocolli di rete

_____________________________________________ | | | | | | AF_AX25 |AF_NET/ROM | AF_INET | AF_ROSE | |=========|===========|=============|=========| | | | | | | | | TCP/IP | | | | |________ | | | | NET/ROM | | ROSE | | |____________________|____|_________| | AX.25 | |_____________________________________________|

Questo schema illustra con chiarezza come NET/ROM, Rose e TCP/IP lavorino sopra l'AX.25, ma anche che, ognuno di questi, sia considerato come un diverso protocollo a livello applicazione. I nomi che iniziano con '_' sono quelli dati alla 'Address Family' di ognuno dei seguenti protocolli nei programmi che ne fanno uso. La cosa importante che va messa in luce in questo caso, è l'implicita dipendenza dalla configurazione dei dispositivi AX.25, che si riflette in quella dei dispositivi NET/ROM, ROSE o TCP/IP.

Diagramma dei moduli software dell'implementazione di rete in Linux

 ___________________________________________________________________________
|         |           |                       ||          |                 |
| User    | Programmi |   call        node    ||  Daemons | ax25d  mheardd  |
|         |           |   pms         mheard  ||          | inetd  NET/ROMd  |
|_________|___________|_______________________||__________|_________________|
|         | Sockets   |open(), close(), listen(), read(), write(), connect()|
|         |           |_____________________________________________________|
|         |           |   AF_AX25   |  AF_NET/ROM |   AF_ROSE   |  AF_INET  |
|         |___________|_____________|_____________|_____________|___________|
|Kernel   | Protocolli|   AX.25     |   NET/ROM   |     ROSE    | IP/TCP/UDP|
|         |___________|_____________|_____________|_____________|___________|
|         | Devices   |   ax0,ax1   |  nr0,nr1    | rose0,rose1 | eth0,ppp0 |
|         |___________|_____________|_____________|_____________|___________|
|         | Drivers   | Kiss   PI2   PacketTwin   SCC   BPQ     | slip ppp  |
|         |           |     Soundmodem      Baycom              | ethernet  |
|_________|___________|_________________________________________|___________|
|Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card |
|_________|_________________________________________________________________|

Questo diagramma è un po' più generale di quello precedente e vuole mostrare la relazione che intercorre tra le applicazioni utente, il kernel e l'hardware. In particolare si nota il rapporto esistente tra le interfacce di programmazione delle applicazioni (API) a livello di Socket, i moduli effettivamente relativi ai vari protocolli, i dispositivi di rete del kernel e i driver. Ogni cosa in questo diagramma dipende da ciò che è presente sotto di lui, quindi in generale le configurazioni devono essere fatte dal basso verso l'alto. Se, per esempio, si vuole far funzionare il programma call, occorre anche configurare l'hardware, poi assicurarsi che il kernel abbia l'opportuno driver, che sia stato creato l'opportuno dispositivo di rete, che il kernel includa il protocollo desiderato e che a sua volta, esponga un interfaccia di programmazione che possa essere utilizzata dal programma call. La stesura di questo documento ricalca a grandi linee quest'ordine.

3.1. Dove reperire il kernel, gli strumenti e i programmi di utilità

---

3.1.2. Gli strumenti di rete

L'ultima versione standard degli strumenti di rete di Linux supporta l'AX.25 e NET/ROM e si può trovare su http://www.tazenda.demon.co.uk/phil/net-tools.

La versione più recente del pacchetto ipchains si trova su http://netfilter.filewatcher.org/ipchains.

Di solito, comunque, non è necessario scaricarsi ed installare questi programmi poiché ogni distribuzione recente dovrebbe includerli.

4.1. La compilazione del kernel

Se avete già familiarità col processo di compilazione del Kernel potete saltare questa sezione; state ben attenti comunque, a selezionare le opzioni appropriate, al momento della compilazione. Se non siete ancora pratici continuate a leggere. Può essere consigliabile anche una lettura del Linux Kernel HOWTO.

La posizione dove comunemente si decomprimono i sorgenti del kernel è la directory /usr/src, nella quale viene creata una sottodirectory chiamata linux. Per eseguire questa operazione, occorre essere loggati come root ed eseguire una sequenza di comandi simile alla seguente:

# cd /usr/src # mv linux linux.old # tar xzvf linux-2.4.9.tar.gz # cd linux

Dopo aver decompresso il sorgente del kernel ed applicato l'aggiornamento, occorre eseguire lo script di configurazione e scegliere le opzioni che permettono al kernel di adattarsi al vostro hardware, e le funzionalità che volete che siano implementate nel kernel stesso. Per fare ciò usate il comando:

# make menuconfig

Se siete sotto X, è possibile avere un'interfaccia grafica usando:

# make xconfig

È possibile anche usare:

# make config

Verrà descritto il metodo di configurazione a menu (menuconfig) perché è più comodo e semplice nella scelta delle opzioni, ma potete usare anche l'altro, se vi trovate più a vostro agio.

In entrambi i casi vi verranno proposte una serie di opzioni alle quali dovete rispondere 'Y' (sì) o 'N' (no) (potreste anche voler rispondere 'M' se siete intenzionati ad usare i moduli del kernel, ma per semplicità supponiamo che non lo siate, modificate le scelte in modo appropriato nel caso sceglieste di usare un kernel di tipo modulare).

Le opzioni più importanti per la parte di configurazione relativa all'AX.25 sono:

Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers ... General setup ---> ... [*] Networking support ... Networking options ---> <*> UNIX domain sockets ... [*] TCP/IP networking ... [?] IP: tunneling ... Amateur Radio Support ---> --- Packet Radio protocols [*] Amateur Radio AX.25 Level 2 protocol [?] AX.25 DAMA Slave support [?] Amateur Radio NET/ROM protocol [?] Amateur Radio X.25 PLP (Rose) AX.25 network device drivers ---> [?] Serial port KISS driver [?] Serial port 6PACK driver [?] BPQ Ethernet driver [?] High-speed (DMA) SCC driver for AX.25 [?] Z8530 SCC driver [?] BAYCOM ser12 fullduplex driver for AX.25 [?] BAYCOM ser12 halfduplex driver for AX.25 [?] BAYCOM picpar and par96 driver for AX.25 [?] BAYCOM epp driver for AX.25 [?] Soundcard modem driver [?] soundmodem support for Soundblaster and compatible cards [?] soundmodem support for WSS and Crystal cards [?] soundmodem support for 1200 baud AFSK modulation [?] soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal) [?] soundmodem support for 2400 baud AFSK modulation (8MHz crystal) [?] soundmodem support for 2666 baud AFSK modulation [?] soundmodem support for 4800 baud HAPN-1 modulation [?] soundmodem support for 4800 baud PSK modulation [?] soundmodem support for 9600 baud FSK G3RUH modulation <?> YAM driver for AX.25

Le opzioni che ho indicato con '* sono quelle alle quali si deve rispondere 'Y'. Il resto dipende da che hardware avete e quali altre opzioni volete includere. Alcune di queste saranno descritte più avanti in dettaglio, per cui se non sapete ancora che funzionalità implementare, andate avanti nella lettura e ritornate su questo argomento più tardi.

Dopo aver completato la configurazione del kernel dovreste essere in grado di compilarlo senza problemi con i seguenti comandi:

# make dep # make clean # make zImage

Assicuratevi di spostare il file del kernel arch/i386/boot/zImage nel posto in cui lo ritenete più opportuno, di editare il vostro file /etc/lilo.conf e rieseguire lilo per essere sicuri che il nuovo boot di Linux avvenga con nuovo kernel appena compilato

---

4.1.1. A proposito dei moduli del Kernel

Compilare i driver come moduli del kernel può essere una soluzione utile se si ha intenzione di utilizzare l'AX.25 soltanto occasionalmente e si vuole essere in grado di caricarlo o scaricarlo a richiesta in modo da risparmiare risorse di sistema. Qualcuno, però, ha riscontrato problemi a far funzionare i driver modularizzati in quanto più complicati da configurare. In caso si voglia compilare uno o più driver come modulo, occorre anche dare i seguenti comandi:

# make modules # make modules_install

per installare i moduli nella posizione appropriata.

Occorrerà anche aggiungere alcune voci nel file /etc/modules.conf in modo da assicurarsi che il programma kerneld sappia dove localizzare i moduli del kernel. Occorrerebbe aggiungere/modificare:

alias net-pf-3 ax25 alias net-pf-6 NET/ROM alias net-pf-11 rose alias tty-ldisc-1 slip alias tty-ldisc-3 ppp alias tty-ldisc-5 mkiss alias bc0 baycom alias nr0 NET/ROM alias pi0a pi2 alias pt0a pt alias scc0 optoscc (o uno degli altri driver scc) alias sm0 soundmodem alias tunl0 newtunnel alias char-major-4 serial alias char-major-5 serial alias char-major-6 lp

Nei sistemi Linux basati su Debian queste voci dovrebbero andare nel file /etc/modutils/aliases e poi andrebbe lanciato il comando /sbin/update-modules.

4.2. Le librerie, i programmi e gli strumenti AX.25

Una volta compilato il nuovo kernel e fatto il reboot con questo, occorre compilare ed installare i programmi, le librerie e gli strumenti per gestire il protocollo AX.25.

Per compilare ed installare libax25 occorre dare una serie di comandi simili a questi:

# cd /usr/src # tar xzvf libax25-0.0.7.tar.gz # cd libax25-0.0.7 # ./configure --exec_prefix=/usr --sysconfdir=/etc --localstatedir=/var # make # make install

Gli argomenti del comando configure fanno sì che i file vengano installati nelle posizioni "standard" sotto la directory /usr nelle sottodirectory bin, sbin, etc e man. Infatti, dando il comando configure senza opzioni, tutti i file verranno messi sotto /usr/local. Questo può portare al fatto di avere i file di configurazione sia sotto /usr che /usr/local. Se si vuole essere sicuri che ciò non succeda si può creare il link simbolico /usr/local/etc/ax25 che punta a /etc/ax25 nella primissima fase dell processo d'installazione, in modo da non doversene preoccupare.

Se questa è la prima installazione sulla vostra macchina, si può dare anche il comando:

# make installconf

per installare anche alcuni file di esempio dentro la directory /etc/ax25/ dai quali partire per creare la propria configurazione.

A questo punto si può effettuare l'installazione degli strumenti AX.25 in questo modo:

# cd /usr/src # tar xzvf ax25-tools-0.0.6.tar.gz # cd ax25-tools-0.0.6 # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # make # make install # make installconf (se si vogliono installare i file di configurazione)

E finalmente installare le applicazioni AX.25:

# cd /usr/src # tar xzvf ax25-apps-0.0.4.tar.gz # cd ax25-apps-0.0.4 # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # make # make install # make installconf (se si vogliono installare i file di configurazione)

Se si ricevono messaggi d'errore del tipo:

gcc -Wall -Wstrict-prototypes -O2 -I../lib -c call.c call.c: In function `statline': call.c:268: warning: implicit declaration of function `attron' call.c:268: `A_REVERSE' undeclared (first use this function) call.c:268: (Each undeclared identifier is reported only once call.c:268: for each function it appears in.)

allora bisogna assicurarsi di avere il pacchetto ncurses correttamente installato nel proprio sistema. Lo script di configurazione tenta di localizzare il pacchetto nelle posizioni più comuni, ma alcune distribuzioni la installano in modo errato, e per questa ragione lo script non riesce a trovarlo.

5.1. Cosa sono tutte queste T1, T2, N2 eccetera?

Non tutte le implementazioni AX.25 sono quelle di un TNC2. Linux usa una nomenclatura che si differenzia in alcune parti da quella usata da chi ha fatto packet solamente con un TNC. La tabella che segue dovrebbe essere d'aiuto per interpretare ognuna delle variabili di configurazione, in modo da poterne capire il significato quando se ne parlerà di nuovo più avanti.

5.2. Parametri configurabili durante l'attività

Il kernel consente di modificare diversi parametri "al volo". Se si controlla con attenzione la directory /proc/sys/net/ si possono notare diversi file con nomi che descrivono diversi parametri della configurazione della rete. Ognuno dei file nella directory /proc/sys/net/ax25/ rappresenta una porta AX.25 configurata. Il nome del file si riferisce al nome della porta.

La struttura dei file in /proc/sys/net/ax25/portname/ è la seguente:

Nella tabella T1, T2 e T3 sono dati in secondi, mentre quello di Idle è in minuti. Si noti, però, che i valori usati nell'interfaccia sysctl sono dati in unità interne, dove il tempo in secondi è moltiplicato per 10 in modo da avere una risoluzione di 1/10 di secondo. Ponendo pari a zero i valori che lo permettono (come T3 e Idle) li si disabilita.

La struttura dei file in /proc/sys/net/NET/ROM/ è la seguente:

La struttura dei file in /proc/sys/net/rose/ è la seguente:

Per modificare un parametro, tutto ciò che occorre è scrivere il valore desiderato nel file stesso; ad esempio per controllare e modificare la grandezza della finestra ROSE, si può usare ad esempio:

# cat /proc/sys/net/rose/window_size 3 # echo 4 >/proc/sys/net/rose/window_size # cat /proc/sys/net/rose/window_size 4

6.1. Creazione del dispositivo di rete AX.25

Il dispositivo di rete è ciò che viene manipolato quando si usa il comando 'ifconfig'. È l'oggetto attraverso il quale il kernel di Linux spedisce e riceve i dati. Quasi sempre un dispositivo di rete ha una porta fisica ad esso associata, ma vi sono casi in cui ciò non è necessario. Il dispositivo di rete fa riferimento direttamente a un driver di dispositivo.

Nel codice AX.25 di Linux ci sono diversi driver. Il più comune è probabilmente il driver KISS, ma ci sono anche i driver SCC, Baycom e SoundModem.

Ogni driver, quando viene lanciato, crea un dispositivo di rete

---

6.1.5. Creazione di un dispositivo SoundModem

Opzioni di compilazione del Kernel:

Amateur Radio support ---> [*] Amateur Radio support --- Packet Radio protocols <*> Amateur Radio AX.25 Level 2 protocol ... AX.25 network device drivers ---> --- AX.25 network device drivers ... <*> Soundcard modem driver [?] soundmodem support for Soundblaster and compatible cards [?] soundmodem support for WSS and Crystal cards [?] soundmodem support for 1200 baud AFSK modulation [?] soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal) [?] soundmodem support for 2400 baud AFSK modulation (8MHz crystal) [?] soundmodem support for 2666 baud AFSK modulation [?] soundmodem support for 4800 baud HAPN-1 modulation [?] soundmodem support for 4800 baud PSK modulation [?] soundmodem support for 9600 baud FSK G3RUH modulation ...

Thomas Sailer ha sviluppato un driver per il kernel che permette l'uso come modem della scheda audio la quale, una volta connessa direttamente alla radio, può essere usata per fare packet. L'autore raccomanda di usare per lo meno un 486DX2/66 con questo sistema, poiché tutta la parte di elaborazione del segnale digitale egrave; compiuta dalla CPU del calcolatore.

Attualmente il driver emula i modem 1200 bps AFSK, 4800 HAPN e 9600 FSK (compatibile G3RUH). Le uniche schede audio attualmente supportate sono quelle compatibili SoundBlaster e WindowsSoundSystem. Se si possiede una scheda audio di tipo diverso, si può provare ad usare il soundmodem in modalità utente (user-mode) descritta più avanti in questo documento.

L'uso delle schede audio richiede della circuiteria addizionale in grado di pilotare il Push-To-Talk; le informazioni per realizzare tale dispositivo sono disponibili nell' apposita pagina sul sito web di Thomas Salier. Ci sono alcune opzioni possibili: rilevare l'uscita dalla scheda audio, o usare l'uscita da una porta parallela, seriale, o MIDI. Sul sito di Thomas sono presenti esempi di realizzazione di circuiti per ognuno di questi metodi.

Quando viene configurato, il driver SoundModem crea dei dispositivi di rete chiamati: sm0, sm1, sm2 eccetera.

Il driver SoundModem usa le stesse risorse del driver sonoro di Linux, per cui se si vuole usare il modem, occorre accertarsi che il driver sonoro non sia installato. Si possono naturalmente compilare entrambi i driver come moduli, in modo da inserirli e rimuoverli a piacimento.

---

6.1.5.1. Configurazione della scheda audio

Il driver SoundModem non inizializza la scheda audio. A questo scopo, il pacchetto ax25-utils include un'utilità chiamata 'setcrystal' che può essere usata per le schede audio basate sul chipset Crystal. Se si possiede una scheda basata su un'altro chipset occorre usare qualche altro programma per inizializzarla. La sintassi dell'utilità è piuttosto semplice:

setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]

Quindi, per esempio, volendo configurare una SoundBlaster all'indirizzo base di i/o 0x388, irq 10 e dma 1 si userà :

# setcrystal -s 0x388 -i 10 -d 1

Per configurare una scheda Window Sound System all'indirizzo base di i/o 0x534, irq 5 e dma 3 si userà:

# setcrystal -w 0x534 -i 5 -d 3

Il parametro [-f synthio] serve per impostare l'indirizzo del sintetizzatore, mentre il parametro [-c dma2] serve per impostare il secondo canale DMA in modo da avere la possibilità di operare il full duplex.

---

6.1.5.2. Configurazione del driver Soundmodem

Una volta configurata la scheda audio, occorre configurare il driver, fornendogli informazioni sulla posizione della scheda audio e su che tipo di modem si intende emulare.

L'utilità sethdlc permette di configurare il driver con questi parametri. Se si ha solo una scheda audio installata, i parametri si possono specificare anche dal comando insmod al momento del caricamento del modulo soundmodem.

Ad esempio, una semplice configurazione con una scheda SoundBlaster configurata come negli esempi precedenti che emula un modem a 1200 bps:

# insmod hdlcdrv # insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1

Questo non è in realtà il modo più indicato per fare questa operazione. L'utilità sethdlc si usa con la stessa facilità con un dispositivo così come con diversi.

Le pagine man di sethdlc contengono tutte le informazioni richieste, però un paio di esempi possono illustrare gli aspetti più importanti della configurazione di questa utilità. Negli esempi seguenti si suppone che i moduli Soundmodem siano già stati caricati usando:

# insmod hdlcdrv # insmod soundmodem

o che il kernel sia già stato compilato con questo tipo di supporto.

Configurazione del driver per il supporto della scheda Windows SoundSystem configurata come negli esempi precedenti e impostata in modo da emulare un modem G3RUH 9600 compatibile come dispositivo sm0 usando una porta parallela all'indirizzo 0x378 per pilotare il Push-To-Talk:

# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378

Configurazione del driver per supportare la scheda Soundblaster configurata come negli esempi precedenti per emulare un modem HAPN a 4800 bps come dispositivo sm1 usando la porta seriale all'indirizzo 0x2f8 per pilotare il Push-To-Talk:

# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8

Configurazione del driver per supportare la scheda SoundBlaster configurata come negli esempi precedenti e impostata in modo da emulare un modem 1200 bps AFSK come dispositivo sm1usando la porta seriale all'indirizzo 0x2f8 per pilotare il Push-To-Talk della radio:

# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8

---

6.1.5.3. Configurazione dei parametri di accesso al canale AX.25

I parametri di accesso al canale AX.25 sono equivalenti ai parametri KISS ppersist, txdelay e slottime. La loro modifica si effettua ancora una volta col comando sethdlc.

Ancora una volta le pagine man di sethdlc sono la fonte di informazioni più completa, tuttavia un paio di esempi in più non fanno male:

Configurazione del dispositivo sm0 con TxDelay di 100 mS, SlotTime di 50mS, PPersist di 128 e full duplex:

# sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full

Si noti che le temporizzazioni sono espresse in millisecondi.

---

6.1.5.4. Messa a punto del driver e del livello audio

Per ogni modem radio è molto importante che i livelli audio siano impostati correttamente e il SoundModem non fa eccezione. Thomas Sailer ha per questo scritto alcune utilità che facilitano questo compito, chiamate smdiag e smmixer.

smdiag

fornisce due tipi di visualizzazione del segnale in ingresso: come oscilloscopio e con un diagramma ad occhio.

smmixer

permette di effettuare la modifica del livello audio in ricezione ed in trasmissione.

Per lanciare l'utilità smdiag per il dispositivo SoundModem sm0 in modalità 'diagramma ad occhio' si usa il comando:

# smdiag -i sm0 -e

Per lanciare l'utilità smmixer per il dispositivo SoundModem sm0 si usa il comando:

# smmixer -i sm0

---

6.1.5.5. Configurazione del Kernel AX.25 per l'uso con SoundModem

Il driver Soundmodem crea dei dispositivi di rete standard che il codice del Kernel AX.25 è in grado di sfruttare. La configurazione è sostanzialmente la stessa di quella per una scheda PI o PacketTwin.

Il primo passo è quello di configurare il dispositivo con un nominativo AX.25. l'utilità ifconfig può essere utile allo scopo.

# /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 up

assegna al dispositivo SoundModem sm0 il nominativo AX.25 VK2KTJ-15. In alternativa sarebbe possibile usare il comando axparms, ma occorre pure ifconfig per attivarlo.

# ifconfig sm0 up # axparms -setcall sm0 vk2ktj-15

Il passo successivo è quello di creare una voce nel file /etc/ax25/axports come si farebbe per ogni altro dispositivo. La voce nel file axports è associata col dispositivo di rete configurato per il nominativo ad esso legato; verrè usata quella col nominativo assegnato al dispositivo SoundModem.

A questo punto si userè il nuovo dispositivo AX.25 come ogni altro; lo si potrà; configurare per l'uso col TCP/IP, aggiungerlo a ax25d e usarci sopra NET/ROM o ROSE a proprio piacimento.

6.2. Creazione del file /etc/ax25/axports

/etc/ax25/axports è un semplice file di testo, da creare con un editor. Il suo formato è il seguente:

portname callsign baudrate paclen window description

dove:

La mia è la seguente:

radio VK2KTJ-15 4800 256 2 4800bps 144.800 MHz ether VK2KTJ-14 10000000 256 2 BPQ/ethernet device

Si ricordi di usare un nominativo/ssid univoco per ogni porta AX.25 che si crea. Occorre creare, dunque, una voce per ogni dispositivo AX.25 che si vuole utilizzare (KISS, SCC, PI, PT, Baycom o SoundModem che sia). Ogni voce descrive un singolo dispositivo di rete AX.25 che sono associati alle porte attraverso il nominativo/ssid, per questo esso deve essere univoco.

6.3. Configurazione del routing AX.25

È possibile configurare l'elenco dei digipeater da utilizzare per raggiungere un host specifico, operazione che risulta utile sia per le operazioni AX.25 che basate su IP. Il comando axparms permette di effettuare questa operazione; le pagine man sono sempre la fonte migliore di informazioni su questo comando, ma un semplice esempio può essere:

# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT

Questo comando indica che il percorso per VK2XLZ deve avvenire tramite il digipeater VK2SUT sulla porta AX.25 chiamata radio.

8.1. Configurazione di /etc/ax25/nrports

Il primo file è /etc/ax25/nrports. Questo file descrive le porte NET/ROM pressapoco nello stesso modo in cui /etc/ax25/axports descrive le porte AX.25. Ogni dispositivo NET/ROM che si vuole creare deve avere una voce di descrizione all'interno del file /etc/ax25/nrports. Normalmente una macchina Linux avrà configurato un unico dispositivo NET/ROM che usa un certo numero delle porte AX.25 definite, ma in alcune situazioni, come ad esempio nei BBS, si potrebbero volere diversi alias NET/ROM.

Questo file è formattato nel seguente modo:

name callsign alias paclen description

Dove:

Un tipico esempio potrebbe essere il seguente:

netrom VK2KTJ-9 LINUX 236 Linux Switch Port

In questo modo viene creata una porta NET/ROM, conosciuta dal resto della rete NET/ROM come 'LINUX:VK2KTJ-9'.

Questo programma viene usato da programmi come call.

8.2. Configurazione di /etc/ax25/nrbroadcast

Il secondo file di configurazione è /etc/ax25/nrbroadcast. Questo file può contenere diverse voci; normalmente ci dovrebbe essere una voce per ogni porta AX.25 su cui si vuole consentire il traffico NET/ROM.

Questo file ha il seguente formato:

axport min_obs def_qual worst_qual verbose

Dove:

Un esempio può essere il seguente:

radio 1 200 100 1

8.3. Creazione del dispositivo di rete NET/ROM

Una volta pronti i due file, occorre creare il dispositivo NET/ROM con un metodo molto simile a quello usato per creare i dispositivi AX.25.In questo caso si usa il comando nrattach, che funziona pressapoco nello stesso modo di axattach, ad eccezione del fatto che crea dei dispositivi di rete NET/ROM chiamati 'nr[0-9]'.. Anche in questo caso, per primo verrà creato il dispositivo 'nr0', poi 'nr1' eccetera. Per creare il dispositivo per la porta NET/ROM definita in precedenza si userà:

# nrattach netrom

Questo comando inizializzerà il dispositivo NET/ROM (nr0) chiamato netrom configurato nel modo definito dai parametri del file /etc/ax25/nrports.

8.4. Lancio del demone NET/ROM

Il kernel di Linux gestisce tutto il protocollo NET/ROM, ad eccezione di alcune funzioni. Il demone NET/ROM gestisce le tabelle di instradamento (routing tables) e genera la trasmissione del routing NET/ROM. Il demone NET/ROM viene lanciato dal comando:

# /usr/sbin/netromd -i

A questo punto il file /proc/net/nr_neigh dovrebbe cominciare a riempirsi di informazioni relative ai nodi NET/ROM adiacenti.

Si ricordi di mettere il comando /usr/sbin/netromd nei propri file rc, in modo che il demone venga lanciato ogni volta che si fa ripartire il sistema.

8.5. Configurazione del routing NET/ROM.

Volendo configurare degli instradamenti NET/ROM statici per degli host specifici si può usare il comando nrparms; ancora una volta si rimanda alle pagine man relative, non prima di proporre un esempio come il seguente:

# /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9

Questo comando abilita una route NET/ROM per #MINTO:VK2XLZ-10 attraverso VK2SUT-9 sulla porta AX.25 chiamata 'radio'.

Si possono creare manualmente voci per nuovi host vicini usando sempre il comando nrparms. Ad esempio:

# /usr/sbin/nrparms -routes radio VK2SUT-9 + 120

questo comando crea VK2SUT-9 come nodo NET/ROM adiacente con qualità 120; questa voce sarà statica e quindi non sarà cancellata automaticamente.

10.1. Configurazione di /etc/ax25/rsports

Il file nel quale si configurano le interfacce ROSE è /etc/ax25/rsports. In esso vengono descritte le porte ROSE più o meno nello stesso modo in cui il file /etc/ax25/axports descrive le porte AX.25.

Questo file è formattato nel seguente modo:

name address description

Dove:

Un esempio potrebbe essere il seguente:

rose 5050294760 Porta Rose

Si noti che, a meno di specificare diversamente, il ROSE usa il nominativo/ssid di default configurato su ogni porta AX.25.

Per configurare un nominativo/ssid da far usare al ROSE su ogni porta, si usa il comando rsparms come segue:

# /usr/sbin/rsparms -call VK2KTJ-10

Questo esempio fa sì che la macchina Linux usi il nominativo VK2KTJ-10 in tutte le porte AX.25 configurate per traffico ROSE.

10.2. Creazione di un dispositivo di rete ROSE

Una volta creato il file /etc/ax25/rsports si possono creare i dispositivi ROSE allo stesso modo in cui sono stati creati i dispositivi AX.25. In questo caso si usa il comando rsattach, che crea i dispositivi di rete chiamati 'rose[0-5]'. La prima volta viene creato 'rose0', la seconda 'rose1' e così via. Ad esempio:

# rsattach rose

Questo comando inizializza il dispositivo ROSE (rose0) configurato nel modo descritto nel file /etc/ax25/rsports per la porta chiamata 'rose'.

10.3. Configurazione del routing ROSE

Attualmente il protocollo ROSE supporta solo l'instradamento statico. L'utilità rsparms permette di configurare la tabella di routing ROSE per Linux.

Ad esempio:

# rsparms -nodes add 5050295502 radio vk2xlz

aggiunge una route al nodo ROSE 5050295502 attraverso una porta AX.25 chiamata 'radio' nel file /etc/ax25/axports, per un host col nominativo VK2XLZ.

Le route possono essere specificate con una maschera per includere diverse destinazioni in un unica voce ROSE. La sintassi è la seguente:

# rsparms -nodes add 5050295502/4 radio vk2xlz

che è identica all'esempio precedente, ad eccezione del fatto che si applica ad ogni destinazione che ha un indirizzo che inizia con le quattro cifre 5050. Una forma alternativa per questo comando è:

# rsparms -nodes add 5050/4 radio vk2xlz

che è probabilmente quella meno ambigua

12.1. Creazione del file /etc/ax25/ax25d.conf

Questo è il file di configurazione per il demone AX.25 ax25d, che gestisce le connessioni entranti AX.25, NET/ROM e ROSE.

Ad una prima occhiata può apparire un po' criptico, ma presto si nota come in pratica sia molto semplice, avendo l'accortezza di evitare una piccola trappola.

Il formato generale del file ax25d.conf è il seguente:

# Questo è un commento ed è ignorato dal progamma ax25d. [nome_porta] || <nome_porta> || {nome_porta} <peer1> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments> <peer2> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments> parameters window T1 T2 T3 idle N2 <mode> <peer3> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments> ... default window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>

Dove:

Occorre una sezione scritta nel formato visto sopra per ogni interfaccia AX.25, NET/ROM o ROSE dalla quale si vogliano accettare connessioni.

Nel paragrafo ci sono due tipi speciali di righe: uno inizia con la stringa 'parameters' e l'altro con la stringa 'default' (sì, c'è differenza). Queste servono per funzioni speciali.

Lo scopo delle linee 'default' dovrebbe essere ovvio; queste regolano il comportamento di quelle connessioni per le quali non sono specificate regole specifiche. In assenza di una regola di 'default', ogni connessione che non è riconducibile ad una regola definita, sarà rifiutata e il chiamante disconnesso senza alcun messaggio.

La riga 'parameters' assolve un compito più sottile, qui sta la trappola menzionata precedentemente. In ogni campo di ogni definizione per una regola di connessione, si può usare il carattere '*' per dire 'usa i valori di default'. La linea 'parameters' è quella che definisce questi valori. Lo stesso kernel ha alcuni valori di default che possono essere usati se non li si specifica con la linea 'parameters' La trappola è che questi valori di default si applicano solo alle regole sotto la linea 'parameters'. Si possono avere diverse linee 'parameters' per interfaccia in modo da creare gruppi di configurazioni di default. È importante notare che 'parameters' non permette di settare i valori dei campi 'uid' o 'command'.

12.2. Un semplice esempio di file ax25d.conf

Ok, a questo punto si impone un esempio chiarificatore:

# ax25d.conf for VK2KTJ - 02/03/97 # Questo file di configurazione usa le porte definite precedentemente # <peer> Win T1 T2 T3 idl N2 <mode> <uid> <exec> <argv[0]>[<args....>] [VK2KTJ-0 via radio] parameters 1 10 * * * * * VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u + VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u + NOCALL * * * * * * L default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj [VK2KTJ-1 via radio] default * * * * * 0 root /usr/sbin/node node <NET/ROM> parameters 1 10 * * * * * NOCALL * * * * * * L default * * * * * * 0 root /usr/sbin/node node {VK2KTJ-0 via rose} parameters 1 10 * * * * * VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u + VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u + NOCALL * * * * * * L default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj {VK2KTJ-1 via rose} default * * * * * 0 root /usr/sbin/node node radio

Questo esempio dice che chiunque voglia connettersi alla stazione 'VK2KTJ-0' ascoltato sulla porta AX.25 chiamata 'radio' dovrà sottostare alle seguenti regole:

Chiunque abbia il nominativo col valore 'NOCALL' non viene fatto entrare; si noti l'uso del modo 'L'.

La linea parameters modifica due parametri rispetto a quelli di default del kernel (Window e T1) e verrà lanciato il programma /usr/sbin/axspawn per loro. Ogni istanza di /usr/sbin/axspawn lanciata in questo modo apparirà come axspawn nell'output di un comando ps. Le due linee successive danno le regole per due stazioni che riceveranno questi permessi.

L'ultima linea nel paragrafo costituisce la regola che sarà applicata a tutti gli altri (compresi VK2XLZ e VK2DAY se usano un SSID diverso da -1). Questa definizione imposta implicitamente tutti i parametri e fa sì che il programma pms sia lanciato con un argomento che indica che funziona su una connessione AX.25, e che il nominativo utilizzato per rispondere è VK2KTJ. (Si veda il paragrafo 'Configurazione del PMS' per maggiori dettagli).

La configurazione successiva accetta connessioni a VK2KTJ-1 tramite la porta radio e lancia il programma node per chiunque si connetta.

Poi c'è una configurazione NET/ROM (si noti l'uso delle parentesi acute "< >"). Questa è più semplice: stabilisce che chiunque si connetta alla porta dal nome 'NET/ROM' farà partire il programma node, a meno che non abbia nominativo 'NOCALL', nel qual caso viene disconnesso.

Le ultime due configurazioni sono per le connessioni Rose; la prima per chi chiama 'vk2ktj-0', l'altra per chi chiama 'VK2KTJ-1 all'indirizzo di nodo Rose della macchina. Queste funzionano esattamente allo stesso modo; si noti l'uso delle parentesi graffe per caratterizzarle come porte Rose.

L'esempio sopra illustrato è piuttosto banale, ma penso che chiarisca sufficientemente le caratteristiche significative della sintassi del file di configurazione. Una descrizione approfondita di quest'ultima si può trovare nelle pagine man di ax25d.conf. Un esempio più dettagliato è incluso, invece, nelle Liax25-utils.

12.3. Lanciare ax25d

Una volta approntati i due file di configurazione, si può lanciare ax25d col comando:

# /usr/sbin/ax25d

Una volta fatto questo, i corrispondenti dovrebbero essere in grado di effettuare connessioni AX.25 alla vostra macchina Linux. Si ricordi di mettere il comando ax25d nei propri file rc, in modo che venga lanciato ogni volta che la macchina viene fatta ripartire.

13.1. Creazione del file /etc/ax25/node.conf

Il file node.conf è dove viene scritta la configurazione principale del nodo. È un semplice file di testo ed è formattato nel seguente modo:

# /etc/ax25/node.conf # file di configurazione del programma node(8). # # Le linee che iniziano con '#' sono commenti e vengono ignorate. # Hostname # Specifica il nome della macchina che fa da nodo. hostname radio.gw.vk2ktj.ampr.org # Rete Locale # Permette di specificare cosa dev'essere considerato 'locale' # per il controllo dei permessi usando nodes.perms. localnet 44.136.8.96/29 # Occultamento di alcune porte # Se viene specificato, questo parametro permette di rendere le porte # invisibili agli utenti. Le porte qui elencate non saranno riportate # dal comando (P)orts. hiddenports rose NET/ROM # Identificazione del nodo. # Questo apparirà al prompt del nodo. NodeId LINUX:VK2KTJ-9 # Porta NET/ROM # Questo è il nome della porta NET/ROM che verrà usata per # le connessioni NET/ROM in uscita dal nodo. NrPort NET/ROM # Node Idle Timeout # Specifica il tempo di idle in secondi per le connessioni fatte # a questo nodo (cioè quanto possono rimanere inattive prima che la # connessione venga interrotta. idletimout 1800 # Connection Idle Timeout # Specifica il tempo di idle in secondi per le connessioni fatte # attraverso questo nodo. conntimeout 1800 # Riconnessione # Specifica se gli utenti debbano essere riconnessi al nodo # se la loro connessione remota si interrompe, o se debbano essere # definitivamente disconnessi. reconnect on # Alias dei comandi # Permette di rendere semplici dei comandi di nodo più articolati. alias CONV "telnet vk1xwt.ampr.org 3600" alias BBS "connect radio vk2xsb" # Aliases dei comandi esterni # Permette di eseguire dei comandi esterni all'interno del nodo. # La sintassi è: # extcmd <nomecmd> <flag> <userid> <comando> # Flag == 1 è l'unica funzione implementata. # <comando> è formattato sullo stile di ax25d.conf extcmd PMS 1 root /usr/sbin/pms pms -u %U -o VK2KTJ # Logging # Stabilisce la quantità di informazioni che vengono scritte nel log. # 3 per il maggior numero di informazioni, 0 per disabilitare il log. loglevel 3 # Il carattere di escape # 20 = (Control-T) EscapeChar 20

13.2. Creazione del file /etc/ax25/node.perms

node consente di assegnare permessi agli utenti. Questi permessi permettono di stabilire quali utenti, ad esempio, sono autorizzati a far uso di opzioni come i comandi (T)elnet e (C)onnect. Il file node.perms viene usato per stabilire questo genere di permessi e contiene cinque campi chiave; in ognuno di questi un asterisco '*' serve per indicare 'qualunque cosa' e viene usato per creare le regole di default.

Un esempio di file nodes.perms potrebbe essere il seguente:

# /etc/ax25/node.perms # #L'operatore del nodo è VK2KTJ, ha password 'secret' e ha tutti #i permessi per tutti i tipi di connessione vk2ktj * * secret 255 # Ai seguenti nominativi è impedito connettersi NOCALL * * * 0 PK232 * * * 0 PMS * * * 0 # Agli utenti INET è impedito connettersi. * inet * * 0 # Gli utenti AX.25, NET/ROM, Local, Host e AMPR possono fare (C)onnect # e (T)elnet a host locali e ampr, ma non ad altri indirizzi IP. * ax25 * * 159 * NET/ROM * * 159 * local * * 159 * host * * 159 * ampr * * 159

13.3. Configurazione di node per funzionare da ax25d

Il programma node viene lanciato di solito dal programma ax25d. Per fare questo occorre aggiungere delle particolari regole al file /etc/ax25/ax25d.conf. Nella configurazione che adotto, voglio permettere agli utenti di scegliere se connettersi a node o ad altri servizi. ax25d consente di fare questo attraverso l'intelligente creazione di alias delle porte. Ad esempio, data la configurazione di ax25d presentata sopra, si vuole configurare node in modo che venga lanciato per tutti gli utenti che si connettono a VK2KTJ-1 Per fare questo si aggiunge questo al file /etc/ax25/ax25d.conf:

[vk2ktj-1 via radio] default * * * * * 0 root /usr/sbin/node node

Questo dice che il kernel di Linux risponderà ad ogni richiesta di connessione al nominativo 'VK2KTJ-1' ascoltato sulla porta chiamata 'radio' lanciando il programma node

13.4. Configurazione di node per funzionare da inetd

Se si vuole che i propri utenti siano in grado di fare telnet su una porta della macchina e avere accesso a node lo si può fare piuttosto facilmente. La prima cosa da decidere e a quale porta gli utenti si devono connettere In questo esempio si è arbitrariamente scelta la porta 4000, sebbene Toi nella sua documentazione fornisca i passi per sostituire il normale demone Telnet con node.

Occorre modificare due file.

In /etc/services occorre aggiungere:

node 3694/tcp #OH2BNS's node software

E in /etc/inetd.conf va aggiunto:

node stream tcp nowait root /usr/sbin/node node

Una volta fatto questo, facendo ripartire il programma inetd, ogni utente connesso via telnet alla porta 3694 della macchina riceverà la richiesta di login, l'eventuale richiesta di password e sarà connesso a node.

14.1. Creazione del file /etc/ax25/axspawn.conf

È possibile modificare il comportamento di axspawn agendo sul file di configurazione /etc/ax25/axspawn.conf che è formattato nel seguente modo:

# /etc/ax25/axspawn.conf # # permette la creazione automatica di account utente create yes # # accesso come utente guest (ospite) se sopra si è scelto "no" o se tutto # fallisce. Disabilita con "no" guest no # # nome del gruppo o group id degli utenti creati automaticamente group ax25 # # primo user id da usare first_uid 2001 # # massimo numero di user id max_uid 3000 # # dove creare la home directory dei nuovi utenti home /home/ax25 # # shell dell'utente shell /bin/bash # # lega lo user id al nominativo per le chiamate in uscita associate yes

Gli otto parametri di configurazione di axspawn hanno il seguente significato:

15.1. Creazione del file /etc/ax25/pms.motd

Il file /etc/ax25/pms.motd contiene il 'messaggio del giorno' che verrà inviato a chi si connette dopo lo header usuale del BBS. Si tratta di un file di testo; qualunque cosa vi inseriate sarà presentata all'utente all'atto della connessione.

15.2. Creazione del file /etc/ax25/pms.info

Anche /etc/ax25/pms.info è un semplice file di testo, nel quale si possono mettere informazioni più dettagliate sulla configurazione della propria stazione, che viene inviato all'utente in risposta al comando Info dal prompt PMS>.

15.3. Associazione di nominativi AX.25 con gli utenti di sistema

Quando un utente connesso manda posta ad un nominativo AX.25, pms si aspetta che questo sia mappato o associato con un reale utente creato sulla vostra macchina. Questo è descritto in una sezione a parte.

15.4. Aggiunta di PMS in /etc/ax25/ax25d.conf

L'aggiunta di pms al proprio file ax25d.conf è un'operazione molto semplice, tuttavia c'è una piccola cosa da tenere in considerazione. Dave ha aggiunto degli argomenti alla linea di comando di pms per permettergli di gestire diverse regole di testo di fine linea. AX.25 e NET/ROM, per convenzione, si aspettano che la fine della linea di testo sia indicata dal comando di ritorno a capo e dall'avanzamento di linea (carriage return, linefeed), mentre nei sistemi Unix standard si usa solo il comando di nuova linea (newline). Quindi per esempio, se si vuole aggiungere una voce per indicare il lancio del programma pms come azione di default per ogni connessione, si aggiunge una linea di questo tipo:

default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj

Questo lancia il programma pms, indicandogli che deve gestire una connessione AX.25 e che il gestore del bbs è vk2ktj. Si vedano le relative pagine man per vedere come indicare al programma altri tipi di connessione.

15.5. Test del PMS

Per testare il PMS, si può dare il seguente comando dal prompt della shell: # /usr/sbin/pms -u vk2ktj -o vk2ktj Sostituire il proprio nominativo con quello dell'autore, in modo che il comando lanci il pms indicandogli che deve usare la convenzione Unix per il comando di fine linea e che l'utente che si connette è vk2ktj. In questo modo ci si trova nella stessa situazione di un utente remoto che si connette.

In aggiunta a questo si può provare a far connettere altri nodi alla propria macchina in modo da controllare che le impostazioni in ax25d.conf siano corrette.

17.1. Configurazione del downlink ROSE

Per configurare la propria macchina Linux perché accetti connessioni ROSE e stabilisca collegamenti AX.25 per nominativi diversi da quelli locali occorre aggiungere una voce nel proprio file. /etc/ax25/ax25d.conf. Di solito si configura questa voce come scelta di default per ogni connessione ROSE entrante. Ad esempio si può decidere di gestire localmente chiamate Rose a destinazioni come NODE-0 o NODE-1, e di passare le altre chiamate al comando rsdwnlink, assumendo che siano utenti AX.25.

Una tipica configurazione può dunque essere:

# {* via rose} NOCALL * * * * * * L default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5 #

Con questa configurazione, ogni utente che stabilisce una connessione ROSE con l'indirizzo del vostro nodo Linux e con un nominativo di destinazione che non avete esplicitamente specificato, sarà convertita in una connessione AX.25 dalla porta 4800 usando come digipeater VK2KTJ-5.

17.2. Configurazione di un uplink ROSE

Per configurare la propria macchina Linux affinché accetti le connessioni AX.25 allo stesso modo di un nodo ROM Rose occorre aggiungere le voci opportune nel proprio file /etc/ax25/ax25d.conf che assume un aspetto simile a questo:

# [VK2KTJ-5* via 4800] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose #

Si noti la speciale sintassi per il nominativo locale. il carattere '*' indica che l'applicazione dovrebbe essere invocata se il nominativo è presente nel percorso digipeater di una connessione.

Questa configurazione permette ad un utente AX.25 di effettuare connessioni Rose usando l'esempio presentato nell'introduzione. Ogni connessione che tenti di usare VK2KTJ-5 come digipeater sulla porta AX.25 chiamata 4800 sarà gestita dal comando rsuplnk

21.1. Le famiglie degli indirizzi

La programmazione di rete per AX.25, NET/ROM e Rose è, in Linux, piuttosto simile a quella per TCP/IP, visto che la differenza maggiore sta nelle diverse famiglie di indirizzi e nella loro diversa struttura.

I nomi delle famiglie degli indirizzi per AX.25, NET/ROM e Rose sono rispettivamente AF_AX25, AF_NET/ROM e AF_ROSE.

21.2. I file header

Occorre sempre includere i file header 'netax25/ax25.h', nonchè 'NET/ROM/NET/ROM.h' o 'netrose/rose.h' se avete a che fare con questi protocolli. La struttura di base sarà simile alla seguente:

Per 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

Per NET/ROM:

#include <netax25/ax25.h> #include <NET/ROM/NET/ROM.h> int s, addrlen = sizeof(struct full_sockaddr_ax25); struct full_sockaddr_ax25 sockaddr; sockaddr.fsa_ax25.sax25_family = AF_NET/ROM;

Per 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;

21.3. Trattamento dei nominativi ed esempi

Nella libreria lib/ax25.a delle AX.25-utilities vi sono routine che effettuano la conversione e il trattamento dei nominativi, anche se naturalmente potete scriverne di vostre.

Le utilità user_call sono eccellenti esempi su cui impostare il vostro lavoro; spendendoci su un po' di tempo si comprende come il novanta percento del lavoro consiste nel riuscire ad aprire il socket. Per la verità effettuare la connessione è semplice, è la preparazione che richiede tempo.

Gli esempi sono semplici a sufficienza da non creare confusione. In caso di dubbi è buona cosa rivolgersi alla mailing list linux-hams, dove senz'altro ci sarà qualcuno che vi darà una mano.

22.1. Piccola LAN Ethernet con macchina Linux che fa da router verso una LAN radio

Molti hanno delle piccole reti locali a casa e vogliono connettere le macchine ivi presenti alla rete radio. Questo è il tipo di configurazione che uso a casa. Ho fatto in modo di avere un blocco di indirizzi a me allocato che per comodità posso catturare in una singola route e che uso per la mia LAN domestica. Il vostro coordinatore IP locale vi assisterà se volete farlo anche voi. Gli indirizzi per la rete locale Ethernet formano un sottoinsieme degli indirizzi della LAN radio; quella che segue è la configurazione che adotto:

. . . . . . ___ _________ . | Rete / \ . Rete | 44.136.8.96/29| | . 44.136.8/24 \ | / | | Router | . \|/ | | | . _____ __________ | | eth0 | Linux | . / \ / \ | |_______________| |_____| TNC |____| Radio |__/ | 44.136.8.97 | e | . \_____/ \__________/ | | | sl0 | | Server | 44.136.8.5 | | | . | | | . | \_________/ . _|_ . . . . . .

#!/bin/sh # /etc/rc.net # Questa configurazione rende disponibile una porta KISS AX.25 # e un dispositivo Ethernet. echo "/etc/rc.net" echo " Sto configurando:" echo -n " loopback:" /sbin/ifconfig lo 127.0.0.1 /sbin/route add 127.0.0.1 echo " fatto." echo -n " ethernet:" /sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \ broadcast 44.136.8.103 up /sbin/route add 44.136.8.97 eth0 /sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0 echo " fatto." echo -n " AX.25: " kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800 ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255 route add -host 44.136.8.5 sl0 route add -net 44.136.8.0 window 1024 sl0 echo -n " NET/ROM: " nrattach -i 44.136.8.5 NET/ROM echo " Routing:" /sbin/route add default gw 44.136.8.68 window 1024 sl0 echo " default route." echo done. # end

/etc/ax25/axports

# nome nominativo velocità paclen window descrizione 4800 VK2KTJ-0 4800 256 2 144.800 MHz

/etc/ax25/nrports

# nome nominativo alias paclen descrizione NET/ROM VK2KTJ-9 LINUX 235 Linux Switch Port

/etc/ax25/nrbroadcast

# nome_ax25 min_obs def_qual worst_qual verbose 4800 1 120 10 1

• Occorre che IP_FORWARDING sia abilitato nel vostro kernel.

• Quando necessario fare riferimento ai file di configurazione AX.25 presentati nelle sezioni precedenti.

• Ho scelto di usare un indirizzo IP per la mia porta radio che non fa parte del blocco usato per la mia rete. Ciò non è obbligatorio, per quella porta si sarebbe potuto tranquillamente usare anche 44.136.8.97.

• 44.136.8.68 è il mio gateway locale dove il traffico IPIP viene incapsulato, e per questo vi punto la mia route di default.

• Ogni macchina sulla mia rete Ethernet ha una route:

  route add -net 44.0.0.0 netmask 255.0.0.0 \ gw 44.136.8.97 window 512 mss 512 eth0

  L'uso dei parametri mss e window permette di ottimizzare le connessioni sia dal lato radio che da quello Ethernet.

• Sulla macchina router vengono fatti girare smail, http, ftp ed altri demoni, in modo che questa sia l'unica macchina che fornisce servizi ad altri.

• La macchina che funge da router è un piccolo 386DX20 con un disco fisso da 20Mb ed una installazione di Linux minimale.

22.2. Configurazione del gateway di incapsulamento IPIP

Alcune informazioni sul routing qui fornite, sono obsolete. Il setup è cambiato dai tempi del kernel 2.0.x, e ora andrebbe utilizzato il comando "ip" presente nel pacchetto iproute2, come descritto nell'Advanced Routing HOWTO.

Linux oggi è utilizzato spessissimo per i gateway di incapsulamento TCP/IP in tutto il mondo. Il driver per il tunneling supporta route di incapsulamento multiple rendendo obsoleto il vecchio demone ipip.

Una configurazione tipica è simile alla seguente:

. . . . . . ___ _________ . | Rete / \ . Rete | 154.27.3/24 | | . 44.136.16/24 \ | / | | Gateway | . \|/ | | | . _____ __________ | | eth0 | Linux | . / \ / \ | ___|_______________| |_____| TNC |____| Radio |___/ | 154.27.3.20 | IPIP | . \_____/ \__________/ | | | sl0 | | | 44.136.16.1 | | | . | | | . | \_________/ . _|_ . . . . . .

I file di configurazione che si usano sono:

# /etc/rc.net # Questa è una semplice configurazione che rende disponibile una # porta radio KISS AX.25, un dispositivo Ethernet e sfrutta il tunnel # driver del kernel per effettuare l'incapsulamento/deincapsulamento # IPIP # echo "/etc/rc.net" echo " Sto configurando:" # echo -n " loopback:" /sbin/ifconfig lo 127.0.0.1 /sbin/route add 127.0.0.1 echo " fatto." # 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 " fatto." # 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 " tunnel:" /sbin/ifconfig tunl0 44.136.16.1 mtu 512 up # echo fatto. # echo -n "Routing ... " source /etc/ipip.routes echo fatto. # # end.

e:

# /etc/ipip.routes # Questo file è generato dallo 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

# nome nominativo velocità paclen window descrizione 4800 VK2KTJ-0 4800 256 2 144.800 MHz

Alcuni punti su cui soffermarsi:

• Il nuovo driver per il tunnelling usa il campo gw nella tabella di routing al posto del parametro pointopoint per specificare l'indirizzo del gateway IPIP remoto. Questo è il motivo per cui ora sono supportate route multiple per ciascuna interfaccia.

• Si possono configurare due dispositivi di rete con lo stesso indirizzo. In quest'esempio sia sl0 che tunl0 sono stati configurati con l'indirizzo IP della porta radio; in questo modo il gateway remoto vede l'indirizzo corretto nei datagrammi incapsulati che il gateway locale gli invia.

• I comandi di routing usati per generare le route incapsulate possono essere generati da una versione modificata dello script munge che viene riportato più sotto. I comandi di routing vengono scritti in un file separato e letto usando il comando bash source /etc/ipip.routes (supponendo di aver chiamato /etc/ipip.routes il file in questione). Il file deve essere nel formato delle route di NOS.

• Si noti l'uso dell'argomento window nel comando route. Impostando opportunamente questo parametro si migliorano le prestazioni del collegamento radio.

Il nuovo script tunnel-munge:

#!/bin/sh # # Da: Ron Atkinson <n8fow@hamgate.cc.wayne.edu> # # Questo script è basato sullo script 'munge' scritto da Bdale N3EUA # per il demone IPIP, modificato da Ron Atkinson N8FOW. Il suo scopo # è quello di convertire un file di gateway nel formato NOS di KA9Q # (chiamato di solito 'encap.txt') nel formato delle tabelle di # routing di Linux per il tunnel driver IP # # Uso: File dei gateway su stdin, file nel formato Linux su stdout. # esempio: tunnel-munge < encap.txt > ampr-routes # # NOTA: Prima di usare questo script assicurarsi di controllare ed # eventualmente cambiare i seguenti parametri: # # 1) Cambiare le sezioni 'Route locali e 'Altre route # dell'utente' con le route presenti nella vostra area # (rimuovete le mie!) # 2) Sulla riga di fgrep assicurarsi di cambiare l'indirizzo IP # con il VOSTRO indirizzo di gateway internet. Se non si # effettua questa operazione si rischiano seri routing loop. # 3) L'interfaccia ha nome di default 'tunl0'. Assicurarsi che # questa assunzione sia corretta sul vostro sistema. echo "#" echo "# Tabella di routing con IP tunnelling generata da $LOGNAME il `date`" echo "# dallo script tunnel-munge v960307." echo "#" echo "# Route locali" echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0" echo "#" echo "# Altre route dell'utente" echo "#" echo "# route remote" fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \ awk '{ split($3, s, "/") split(s[1], n,".") if (n[1] == "") n[1]="0" if (n[2] == "") n[2]="0" if (n[3] == "") n[3]="0" if (n[4] == "") n[4]="0" if (s[2] == "1") mask="128.0.0.0" else if (s[2] == "2") mask="192.0.0.0" else if (s[2] == "3") mask="224.0.0.0" else if (s[2] == "4") mask="240.0.0.0" else if (s[2] == "5") mask="248.0.0.0" else if (s[2] == "6") mask="252.0.0.0" else if (s[2] == "7") mask="254.0.0.0" else if (s[2] == "8") mask="255.0.0.0" else if (s[2] == "9") mask="255.128.0.0" else if (s[2] == "10") mask="255.192.0.0" else if (s[2] == "11") mask="255.224.0.0" else if (s[2] == "12") mask="255.240.0.0" else if (s[2] == "13") mask="255.248.0.0" else if (s[2] == "14") mask="255.252.0.0" else if (s[2] == "15") mask="255.254.0.0" else if (s[2] == "16") mask="255.255.0.0" else if (s[2] == "17") mask="255.255.128.0" else if (s[2] == "18") mask="255.255.192.0" else if (s[2] == "19") mask="255.255.224.0" else if (s[2] == "20") mask="255.255.240.0" else if (s[2] == "21") mask="255.255.248.0" else if (s[2] == "22") mask="255.255.252.0" else if (s[2] == "23") mask="255.255.254.0" else if (s[2] == "24") mask="255.255.255.0" else if (s[2] == "25") mask="255.255.255.128" else if (s[2] == "26") mask="255.255.255.192" else if (s[2] == "27") mask="255.255.255.224" else if (s[2] == "28") mask="255.255.255.240" else if (s[2] == "29") mask="255.255.255.248" else if (s[2] == "30") mask="255.255.255.252" else if (s[2] == "31") mask="255.255.255.254" else mask="255.255.255.255" 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 "# si utilizza mirrorshades.ucsd.edu come gateway di default per la parte rimanente di amprnet" echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0" echo "#" echo "# the end"

22.3. Configurazione del gateway di incapsulamento AXIP

Molti gateway radioamatoriali per Internet incapsulano l'AX.25, NET/ROM e Rose oltre che il tcp/ip. L'incapsulamento di frame AX.25 in datagrammi IP viene descritta nell'RFC-1226 da Brian Kantor. Nel 1991 Mike Westerhof ha scritto un'implementazione del demone di incapsulamento dell'AX.25 per Unix, che viene proposta per Linux nelle ax25-utils in una versione leggermente migliorata.

Un gateway di incapsulamento AXIP prende i frame AX.25, ne ricava l'indirizzo AX.25 di destinazione e in base a questo determina a quale indirizzo IP inviarli, dopo averli incapsulati in datagrammi tcp/ip, che vengono mandati all'indirizzo di destinazione. Inoltre permette anche il percorso inverso, accettando datagrammi tcp/ip che contengono frame AX.25. Questi vengono estratti e trattati come se fossero pervenuti direttamente da una porta AX.25. Per distinguere i datagrammi che contengono frame AX.25, li si marca con un protocol id uguale a 4 (o 94 anche se questo è ora sconsigliato), come descritto dalla RFC-1226.

Il programma ax25ipd incluso nelle ax-25utils gestisce un'interfaccia KISS sulla quale si possono far transitare pacchetti AX.25 ed un'interfaccia tcp/ip. Viene configurato tramite il file di configurazione /etc/ax25/ax25ipd.conf.

22.4. Collegare NOS e Linux con un dispositivo pipe

Molti radioamatori utilizzano alcune versioni di NOS sotto Linux, poiché hanno a disposizione tutte le funzionalità a cui sono abituati; a molti di questi piacerebbe che il loro NOS potesse colloquiare col kernel di Linux in modo di poter mettere a disposizione le funzionalità del sistema operativo agli utenti che si collegano via radio con NOS.

Brandon S. Allbery, KF8NH, ha fornito queste informazioni, che consentono di interconnettere il NOS con Linux tramite il dispositivo pipe.

Poiché sia Linux che NOS supportano il protocollo slip, si possono connettere creando un link di questo tipo. È possibile realizzare il collegamento utilizzando due porte seriali della stessa macchina con un cavo loopback tra loro, ma questa realizzazione risulterebbe lenta e costosa. Linux, al contrario, fornisce una funzionalità tipica dei sistemi Unix chiamata 'pipe'. I pipe sono degli 'pseudo-dispositivi' che vengono visti dai programmi come normali dispositivi tty, ma che in realtà fungono da collegamento verso un altro pipe. Per usarli il programma chiamante deve attivare il pipe master e, successivamente, il programma chiamato deve fare lo stesso col pipe slave. Una volta aperte le due porte, i programmi possono comunicare tra loro semplicemente scrivendo caratteri sul dispositivo pipe, esattamente come se fossero normali terminali seriali.

Per usare questa funzionalità per connettere il kernel di Linux con una copia di NOS od altri programmi, occorre per prima cosa scegliere il pipe da usare. I pipe trovano nella directory /dev; le parti master del pipe sono chiamate ptyq[1-f], mentre quelle slave sono ttyq[1-f]. Si ricordi che vanno sempre in coppia, per cui se si sceglie /dev/ptyqf come parte master, occorre scegliere /dev/ttyqf come parte slave.

Una volta scelta una coppia di dispositivi pipe da usare, la parte master va allocata al kernel Linux, mentre la parte slave va assegnata a NOS, poiché il kernel si attiva per primo e il master deve essere aperto prima dello slave; occorre quindi allocare un indirizzo unico per NOS, se non si è già provveduto a farlo.

I pipe si configurano come se fossero dispositivi seriali, per cui per creare il collegamento slip dal kernel Linux, si possono usare i seguenti comandi:

# /sbin/slattach -s 38400 -p slip /dev/ptyqf & # /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 / mtu 1536 44.70.4.88 # /sbin/route add 44.70.248.67 sl0 # /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.70.248.67

In questo esempio al kernel Linux è stato assegnato l'indirizzo IP 44.70.4.88, mentre NOS usa l'indirizzo 44.70.248.67. Il comando route nell'ultima riga indica al kernel Linux di instradare, attraverso il collegamento slip creato dal comando slattach, tutti i datagrammi indirizzati verso amprnet. Normalmente questi comandi vanno messi nel file /etc/rc.d/rc.inet2 immediatamente dopo tutti gli altri comandi di configurazione della rete, in modo che il collegamento slip sia creato alla partenza del sistema. Nota: non c'è alcun vantaggio nell'uso del comando cslip al posto di slip, anzi, con cslip si avverte un calo di prestazioni poiché, essendo un collegamento virtuale, il tempo impiegato per comprimere gli header è superiore di quello che viene impiegato per trasmettere i datagrammi non compressi.

Per configurare la parte NOS dall'altra parte del collegamento si può usare la seguente configurazione:

# si può chiamare l'interfaccia come si vuole, in questo caso la si è # chiamata "linux" per comodità attach asy ttyqf - slip linux 1024 1024 38400 route addprivate 44.70.4.88 linux

Questi comandi creano una porta slip chiamata 'linux' attraverso la parte slave del pipe che lo collega al kernel di Linux, ed un comando di route per farla funzionare. Una volta fatto partire NOS, si deve essere in grado di eseguire ping e telnet da Linux a NOS e viceversa. Se ciò non si verificasse, controllare con attenzione soprattutto la corretta configurazione degli indirizzi e del pipe.

24.1. Packet Radio

Informazioni generali sul packet radio si possono trovare su questi siti:

• American Radio Relay League

• Radio Amateur Teleprinter Society

• Tucson Amateur Packet Radio Group

24.2. Documentazione sui protocolli

• AX.25, NET/ROM - Jonathon Naylor ha raccolto una serie di documenti riguardo i protocolli usati nel packet radio. Questa documentazione è stata raccolta nel file ax25-doc-1.0.tar.gz

24.3. Documentazione sull'hardware

• Informazioni sulla Scheda PI2 possono essere reperite presso l' Ottawa Packet Radio Group.

• Informazioni sull'hardware del Baycom si trovano sulla Web Page Baycom.

24.4. Software Linux per radioamatori

John Ackermann mantiene un sito web con informazioni sulla configurazione di AX.25 su Linux presso http://www.febo.com/linux-ax25/index.html.

L'Hamsoft Linux Ham Radio Applications and Utilities Database si propone di mantenere una lista completa di applicazioni per Linux per radioamatori. La si può trovare su http://radio.linux.org.au.