<!doctype linuxdoc system>

<!-- This is the Linux AX25-HOWTO. It describes how to install and
configure
	AX.25 networking support for Linux. Any comments or feedback
	should
	be directed to the author terry@perf.no.itg.telstra.com.au
 -->

<article OPTS="italian">

<title>Linux AX25-HOWTO, Amateur Radio.
<author>Terry Dawson, VK2KTJ,
<tt>terry@perf.no.itg.telstra.com.au</tt>
<date>v1.5, 17 Ottobre 1997

<abstract>
Linux è forse l'unico sistema operativo al mondo che offra un
supporto nativo standard per il protocollo AX.25, utilizzato in tutto
il mondo dai radioamatori per il packet radio. Questo documento ha lo
scopo di spiegare come installare e configurare questo supporto. 
<p>
Traduzione di Nico Alberti IZ4APS@IK4MGV.PR.IEMR.ITA.EU
albertin@usa.net
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->


<sect>Note sulla traduzione italiana.

<p>

Ho affrontato il lavoro di traduzione di questo HOWTO principalmente
perché è la parte più interessante di documentazione sull'uso di
Linux in ambiente radioamatoriale, e quindi credo che sia la prima
fonte di informazioni tecniche per chi ne vuol sapere di più sulla
comunicazione radio digitale con questo sistema operativo. Tuttavia
nel documento vengono affrontati svariati problemi di configurazione
di schede e protocolli per alcuni dei quali non ho l'enorme
esperienza e capacità tecnica dell'autore (un eufemismo per dire che
ne so veramente poco :-) ). Pur avendo cercato di produrre il miglior
lavoro di traduzione possibile compatibilmente con le mie capacità,
è possibile che la traduzione di certi argomenti non sia chiara o che
addirittura non sia all'altezza della situazione. In questi casi vi
prego di farmi pervenire tutte le correzioni e i suggerimenti che
riterrete opportuni, in modo da rendere questo lavoro più completo
possibile.



Va inoltre notato che la grande mole dei dati forniti e il fatto che
questo documento sia relativamente recente fa sì che la  disposizione
degli argomenti non sia forse la migliore, rendendo più complessa la
comprensione dei concetti più impegnativi; l'autore, tuttavia, lavora
continuamente su nuove versioni di questo documento che risultano
sempre più complete ed esaurienti.






<sect>Introduzione.
<p>

Questo documento era originariamente un'appendice dell'HAM-HOWTO, ma
è diventato troppo grande per essere gestito in quel modo. AX.25
HOWTO descrive come installare e configurare il supporto nativo
AX.25, NetRom e Rose per Linux. Vengono descritte alcune tipiche
configurazioni che possono essere usate come modelli di partenza.

<p>

L'implementazione in Linux dei protocolli di rete per radioamatori è
molto flessibile, ma per coloro che non hanno particolare
familiarità con questo sistema operativo il processo di configurazione
può apparire complesso e laborioso; infatti occorre un po' di tempo
per capire tutto l'insieme. Configurare il proprio sistema può
apparire un'operazione molto difficile se non ci si è prima
documentati sul funzionamento di Linux in generale, del resto non si
può pretendere di passare a Linux da un altro sistema operativo senza
prima documentarsi su Linux stesso.


<sect1>Modifiche rispetto alla versione precedente.
<p>
<verb>
Aggiunte:
	la pagina Web di Joerg Reuters
	la sezione "Ulteriori Informazioni"
	la configurazione di ax25ipd.

Correzioni/Aggiornamenti:

	Modificati i pty con valori tali da evitare possibili conflitti.

	Aggiornate le versioni dei moduli e delle ax25-utils
	
Da Fare:
	Correggere la parte relativa alle schede SCC, perché
	probabilmente è sbagliata.

	Espandere la sezione dedicata alla programmazione.
</verb>


<sect1>Dove reperire nuove versioni di questo documento (in inglese).
<p>

La fonte migliore è da un archivio del Linux Documentation Project.
In particolare il Linux Documentation Project gestisce un server Web
nel quale è presente  

<url url="http://sunsite.unc.edu/LDP/HOWTO/AX25-HOWTO.html"
	name="l'AX25-HOWTO">. Questo documento è presente inoltre in vari
	formati presso <url
	url="ftp://sunsite.unc.edu/pub/Linux/docs/howto/"
	name="sunsite.unc.edu">.
<p>

Si può sempre contattare l'autore, ma dato che passa le nuove
versioni del documento direttamente al coordinatore del LDP, è
probabile che non sia in grado di darvi versioni più aggiornate di
quella presente nell'archivio.

<sect1>Documenti correlati.
<p>

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


Sono le seguenti (in inglese):

<url url="http://sunsite.unc.edu/LDP/HOWTO/HAM-HOWTO.html"
	name="The HAM-HOWTO">,

<url url="http://sunsite.unc.edu/LDP/HOWTO/NET-3-HOWTO.html"
	name="The NET-3-HOWTO">,

<url url="http://sunsite.unc.edu/LDP/HOWTO/Ethernet-HOWTO.html"
	name="The Ethernet-HOWTO">,

e:

<url url="http://sunsite.unc.edu/LDP/HOWTO/Firewall-HOWTO.html"
	name="The Firewall-HOWTO">
<p>

Informazioni più generali possono essere reperite in altri 
<url url="http://sunsite.unc.edu/LDP/HOWTO/" name="HOWTO Linux">

<sect>Linux e i protocolli per Packet Radio.
<p>
Il protocollo <em>AX.25</em> offre la possibilità di lavorare o meno
in modo connesso, ed è usato sia da solo in collegamenti punto-punto,
che per trasporto di altri protocolli come il TCP/IP e NetRom

<p>

La sua struttura è simile all'AX.25 level 2, con alcune estensioni
che lo rendono più adatto all'ambito radioamatoriale.
<p>

Il protocollo NetRom rappresenta un tentativo di realizzare un
protocollo di rete completo e usa AX.25 al livello più basso come
protocollo dati. Presenta un livello di rete che è una forma adattata
di AX.25 e offre il routing dinamico e l'alias dei nodi.

<p>

Il protocollo Rose fu concepito ed implementato da Tom Moulton W2VY
come un'implementazione del livello di pacchetto di AX.25 che viene
usato a sua volta a livello dati, funzionando anche a livello di
rete. L'indirizzamento in Rose è costituito da un numero a 10 cifre.
Le prime quattro rappresentano il Codice Identificativo dei Dati di
rete (Data Network Identification Code) (DNIC) come indicato dalla
Raccomandazione CCIT X.121 Appendice B. Maggiori informazioni sul
protocollo Rose si possono trovare sul 
<url url="http://www.rats.org/" name="RATS Web server">.
<p>

Alan Cox è stato lo sviluppatore del primo supporto AX.25 per il
kernel di Linux, che è stato successivamente preso in carico da
Jonathon Naylor <tt>&lt;g4klx@g4klx.demon.co.uk></tt> che ha aggiunto
anche il supporto per NetRom e Rose. Il supporto per il protocollo
DAMA è stato sviluppato da 
Joerg, DL1BKE, <tt/jreuter@poboxes.com/ mentre il supporto per il
Baycom e il SoundModem è stato aggiunto da Thomas Sailer,
<tt>&lt;sailer@ife.ee.ethz.ch></tt>. Il supporto e lo sviluppo delle
utility software per AX.25 è ora gestita da Terry Dawson, autore di
queste note.
<p>

Linux supporta i TNC (Terminal Node Controllers) in modo KISS,
l'Ottawa PI card, la Gracilis PacketTwin card  e le altre schede SCC
basate su Z8530 attraverso l'apposito driver, nonché il modem Baycom
seriale e parallelo. Il nuovo driver soundmodem di Thomas Sailer
permette l'utilizzo come modem della SoundBlaster e delle schede
sonore basate sul chipset crystal.
<p>

Il pacchetto User contiene un semplice PMS (Personal Message System),
un beacon, un programma a linea di comando per effettuare
connessioni, `listen' un esempio su come catturare tutti i pacchetti
AX.25 a livello di interfaccia e programmi per configurare il
protocollo NetRom. E' incluso anche un programma tipo server AX.25
per gestire ed instradare connessioni AX.25 e un demone NetRom che
svolge la maggior parte del lavoro di supporto per questo protocollo.

<sect1>Come tutto si combina assieme.
<p>

Quella di Linux è un'implementazione di AX.25 piuttosto nuova. Sebbene
somigli 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 altre implementazioni, ma il processo di configurazione è del
tutto diverso.
<p>

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.

<bf><em>Diagramma semplificato dei livelli dei protocolli di
rete</em></bf>
<tscreen><verb>
-----------------------------------------------
| AF_AX25 | AF_NETROM |  AF_INET    | AF_ROSE |
|=========|===========|=============|=========|
|         |           |             |         |
|         |           |    TCP/IP   |         |
|         |           ----------    |         |
|         |   NetRom           |    | Rose    |
|         -------------------------------------
|            AX.25                            |
-----------------------------------------------
</verb></tscreen>

Questo diagramma illustra con chiarezza come NetRom, Rose e TCP/IP
lavorino sopra l'AX.25, ma che ognuno di questi sia considerato come
un diverso protocollo a livello applicazione.

I nomi `<tt>AF&lowbar;</tt>' sono semplicemente quelli dati alla
`<em>Address Family</em>' di ognuno di questi, quando si scrivono
programmi che li utilizzano. Si noti l'implicita dipendenza dalla
configurazione della parte AX.25 presente in quelle di NetRom Rose o
del TCP/IP.


<p>
<bf><em>Moduli software presenti nell'implementazione di rete di
Linux</em></bf>
<verb>
------------------------------------------------------------------------------------
 Utente  | Programmi |   call   node    ||  Demoni  | ax25d  mheardd
         |           |   pms    mheard  ||          | inetd  netromd
------------------------------------------------------------------------------------
         | Socket    | open(), close(), listen(), read(), write(), connect()
         |           |
         |           |--------------------------------------------------------------
         |           |    AF&lowbar;AX25   |  AF&lowbar;NETROM  |  AF&lowbar;ROSE   |  AF_INET
         |--------------------------------------------------------------------------
Kernel   | Protocolli|    AX.25     |   NetRom    |     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 | Scheda PI2, Scheda PacketTwin, Scheda SCC, Porta Seriale, Scheda Ethernet
------------------------------------------------------------------------------------
-------
</verb>

Questo diagramma è un po' più esteso 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 relativi ai vari protocolli, i device di rete del
kernel e l'hardware.

Ogni cosa in questo diagramma dipende da ciò che è indicato sotto di
lui, quindi in generale le parti da configurare devono essere fatte
dal basso verso l'alto. Se, per esempio, si vuole far funzionare il
programma <em>call</em> occorre configurare l'hardware, poi
assicurarsi che il kernel abbia l'opportuno device driver, che sia
stata creata l'opportuno device di rete e che il kernel  includa il
protocollo desiderato che a sua volta possa essere utilizzato dal
programma <em>call</em>. La stesura di questo documento ricalca a
grandi linee quest'ordine.


<sect>I componenti software per AX.25/NetRom/Rose.
<p>

Il software per AX.25 è costituito da tre componenti: il kernel, gli
strumenti (tools) di configurazione di rete e i programmi di utilità.
<p>

Il kernel di Linux, dalla versione 2.0.0 in poi include i driver per
AX.25, NetRom, Z8530 SCC, schede PI e i driver PacketTwin. Questi
driver, nelle versioni 2.1.* del kernel sono stati significativamente
migliorati; sfortunatamente i kernel con questa versione contengono
codice non molto stabile e ciò non li rende adatti per un sistema che
non sia di test. Per ovviare a questo problema Jonathon Naylor ha
preparato un kit di aggiornamento in grado di garantire già sul
kernel 2.0.28 le caratteristiche dei kernel 2.1.*. Questo kit è molto
semplice da installare e permette di disporre di diversi
miglioramenti non presenti nel kernel standard, come ad esempio il
supporto per Rose.


<sect1>Dove reperire il kernel, i tools e i programmi di utilità.
<p>

<sect2>I sorgenti del kernel:
<p>
I sorgenti del kernel si possono trovare nel loro solito posto
presso:
<bf>ftp.kernel.org</bf>
<tscreen><verb>
/pub/linux/kernel/v2.0/linux-2.0.31.tar.gz
</verb></tscreen>

La versione corrente dell'aggiornamento per AX.25 è disponibile su:
<bf>ftp.pspt.fi</bf>
<tscreen<verb>
/pub/linux/ham/ax25/ax25-module-14e.tar.gz
</verb></tscreen>

<sect2>Gli strumenti (tools) di configurazione di rete:
<p>
L'ultima versione alfa degli strumenti standard di configurazione di
rete AX.25 e NetRom per Linux si trova presso:
<bf>ftp.inka.de</bf>
<tscreen><verb>
/pub/comp/Linux/networking/net-tools/net-tools-1.33.tar.gz
</verb></tscreen>

<p>
L'ultimo pacchetto ipfwadm si trova su:
<bf>ftp.xos.nl</bf>
<tscreen><verb>
/pub/linux/ipfwadm/
</verb></tscreen>

<sect2>Le AX25 utility:
<p>

Ci sono due diverse famiglie di AX25-utilities. Una è per i kernel
<tt>2.0.*</tt> e l'altra funziona sia per per i kernel <tt>2.1.*</tt>
che quelli <tt>2.0.*+moduleXX</tt>. Il numero di versione delle
ax25-utils  è quello del kernel più vecchio col quale queste
funzionano, quindi occorre usare quello adatto al vostro kernel.
Quelle che seguono sono combinazioni kernel-ax25-utils funzionanti.
<bf>bisogna</bf> usare una di queste, perché altre non funzioneranno
del tutto o in parte. 

<tscreen><verb>
Kernel Linux             AX25 Utility
----------------------   -------------------------
linux-2.0.29             ax25-utils-2.0.12c.tar.gz **
linux-2.0.28+module12    ax25-utils-2.1.22b.tar.gz **
linux-2.0.30+module14c   ax25-utils-2.1.42a.tar.gz
linux-2.0.31+module14d   ax25-utils-2.1.42a.tar.gz
linux-2.1.22 ++          ax25-utils-2.1.22b.tar.gz
linux-2.1.42 ++          ax25-utils-2.1.42a.tar.gz
</verb></tscreen>

<bf>Nota</bf>: la serie delle  <tt>ax25-utils-2.0.*</tt> (indicate
sopra con '<tt>**</tt>' ) è ora obsoleta e non più supportata. Questo
documento è relativo alle configurazioni indicate sopra. Dato che ci
sono delle differenze tra una versione e l'altra, la maggior parte
delle informazioni date in questo documento saranno relative
all'ultima versione dei programmi.


Le AX.25 utility si trovano su:
<url url="ftp://ftp.pspt.fi/pub/linux/ham/ax25/" name="ftp.pspt.fi">

o su:
<url url="ftp://sunsite.unc.edu/pub/Linux/apps/ham/"
name="sunsite.unc.edu">

<sect>Installazione del software per AX.25/NetRom/Rose.
<p>

Per installare correttamente il supporto per AX.25 sulla vostra
macchina Linux, occorre configurare ed installare un kernel
appropriato e poi installare le corrispondenti utility AX.25

<sect1>La compilazione del kernel.
<p>

Se avete già familiarità col processo di compilazione del Kernel
potete saltare questa sezione; state ben attenti, comunque a
selezionare le opzioni appropriate, che verranno trattate
diffusamente qua sotto.
<p>

Il posto usuale in cui si decomprime il sorgente kernel è la directory
<tt>/usr/src</tt>, nella quale viene creata una sottodirectory
<tt>linux</tt>. Per fare ciò occorre essere loggati come 
<tt>root</tt> ed eseguire una serie di comandi come questi:

<tscreen><verb>
# mv linux linux.old
# cd /usr/src
# tar xvfz linux-2.0.31.tar.gz
# tar xvfz /pub/net/ax25/ax25-module-14e.tar.gz 
# patch -p0 &etago;usr/src/ax25-module-14/ax25-2.0.31-2.1.47-2.diff
# cd linux
</verb></tscreen>

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: 


<tscreen><verb>
# make menuconfig
</verb></tscreen>

Oppure potete usare:

<tscreen><verb>
# make config
</verb></tscreen>

Descriverò 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).


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


<verb>
Code maturity level options  --->
    ...
    [*] Prompt for development and/or incomplete code/drivers
    ...
General setup  --->
    ...
    [*] Networking support
    ...
Networking options  --->
    ...
    [*] TCP/IP networking
    [?] IP: forwarding/gatewaying
    ...
    [?] IP: tunneling
    ...
    [?] IP: Allow large windows (not recommended if <16Mb of memory)
    ...
    [*] Amateur Radio AX.25 Level 2
    [?] Amateur Radio NET/ROM
    [?] Amateur Radio X.25 PLP (Rose)
    ...
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [?] BAYCOM ser12 and par96 driver for AX.25
    [?] Soundcard modem driver for AX.25
    [?] Soundmodem support for Soundblaster and compatible cards
    [?] Soundmodem support for WSS and Crystal cards
    [?] Soundmodem support for 1200 baud AFSK modulation
    [?] Soundmodem support for 4800 baud HAPN-1 modulation
    [?] Soundmodem support for 9600 baud FSK G3RUH modulation
    [?] Serial port KISS driver for AX.25
    [?] BPQ Ethernet driver for AX.25
    [?] Gracilis PackeTwin support for AX.25
    [?] Ottawa PI and PI/2 support for AX.25
    [?] Z8530 SCC KISS emulation driver for AX.25
    ...
</verb>

Le opzioni che ho indicato con `<tt/*/' sono quelle alle quali si
<bf/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.

<p>

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

<tscreen><verb>
# make dep
# make clean
# make zImage
</verb></tscreen>

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

<p>
<sect2>Una parola sui moduli del Kernel.
<p>

Suggerisco di <bf>non</bf> compilare alcun driver come modulo, poiché
così facendo non si guadagna in altro che in complessità. Molti hanno
incontrato problemi tentando di far funzionare le parti
modularizzate, non perché il software abbia dei problemi, ma perché
l'uso dei moduli rende più complessa la fase di installazione e
configurazione del sistema.
<p>

Se comunque avete scelto di compilare qualche componente come moduli,
occorre dare questi comandi:

<tscreen><verb>
# make modules
# make modules_install
</verb></tscreen>

per installare opportunamente i vostri moduli.
<p>

Occorrerà inoltre aggiungere/modificare le seguenti voci nel vostro
file <tt>/etc/conf.modules</tt> in modo che il programma <em/kerneld/
sappia come gestire i moduli in modo corretto.

<tscreen><verb>
alias net-pf-3     ax25
alias net-pf-6     netrom
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          netrom
alias pi0a         pi2
alias pt0a         pt
alias scc0         optoscc    (o uno degli altri drivers scc)
alias sm0          soundmodem
alias tunl0        newtunnel
alias char-major-4 serial
alias char-major-5 serial
alias char-major-6 lp
</verb></tscreen>

<sect2>Le novità dei kernel 2.0.*+ModuleXX o 2.1.* 

<p>

I kernel <tt/2.1.*/ presentano una versione migliorata di quasi tutti
i protocolli e drivers. I miglioramenti più significativi sono:
<descrip>
<tag>modularizzazione</tag> i protocolli e i driver sono stati
modularizzati in modo che li possiate aggiungere o togliere con
<em/insmod/ e <em/rmmod/. Questo riduce il fabbisogno di memoria del
kernel per moduli usati poco frequentemente e rende  più semplici lo
sviluppo e la ricerca di errori. Come detto, però, rende anche un po'
più complessa la configurazione.

<tag>Tutti i driver sono driver di rete</tag> tutti i device di rete
come Baycom, SCC, PI, Packettwin eccetera, si presentano come normali
interfacce di rete, come ad esempio il driver ethernet; non sono più
come dei TNC kiss. Un nuovo programma di  utilità chiamato
<em/net2kiss/ consente all'occorrenza di creare un'interfaccia kiss
per questi device

<tag>Correzione di bug</tag>Sono stati corretti molti problemi e
aggiunte nuove funzionalità, tra cui il protocollo Rose è una delle
più significative.

</descrip>

<sect1>I programmi di configurazione della rete (nettools).
<p>

Una volta compilato il kernel, occorre compilare i nuovi programmi di
configurazione della rete. Questi permettono di modificare la
configurazione dei device di rete e di aggiungere voci di
instradamento (route) alla tabella di instradamento (routing table).
<p>

La nuova versione alfa del pacchetto standard <tt>net-tools</tt>
include il supporto per AX.25 e NetRom. Io l'ho testato e sembra
funzionare correttamente.

<sect2>Un'aggiunta per correggere alcuni bug e avere il supporto per Rose.
<p>

Il pacchetto standard net-tools-1.33.tar.gz ha alcuni piccoli bachi
nel supporto dei protocolli AX.25 e NetRom. Ho dunque realizzato una
piccola correzione per risolverli e aggiungere nel contempo il
supporto per il protocollo Rose.
<p>

Potete scaricarla da:
<url
url="ftp://zone.pspt.fi/pub/linux/ham/ax25/net-tools-1.33.rose.tjd.di
ff.gz" name="zone.pspt.fi">.


<sect2>Come compilare la versione standard di net-tools.
<p>

Non dimenticate di leggere il file <tt>Release</tt> e di seguire le
istruzioni in esso contenute. I comandi per compilare sono:

<tscreen><verb>
# cd /usr/src
# tar xvfz net-tools-1.33.tar.gz
# zcat net-tools-1.33.rose.tjd.diff.gz | patch -p0
# cd net-tools-1.33
# make config
</verb></tscreen>

A questo punto vi verranno fatte una serie di domande per
effettuare la configurazione simili a quelle trovate nel kernel.
Assicuratevi di includere il supporto per tutti i protocolli che
volete usare. Se non sapete cosa rispondere ad una particolare
domanda, rispondete `Y'.

<p>

Alla fine della compilazione occorre fare:

<tscreen><verb>
# make install
</verb></tscreen>

per installare il programma correttamente


<p>

Se siete intenzionati ad usare funzioni di IP firewall, vi occorrono
i più recenti strumenti di amministrazione di firewall presenti nel
pacchetto 
<tt>ipfwadm</tt>. Questo tool sostituisce il vecchio <tt>ipfw</tt>
che non funziona coi nuovo kernel. 
<p>

Ho compilato <tt>ipfwadm</tt> coi seguenti comandi:
<tscreen><verb>
# cd /usr/src
# tar xvfz ipfwadm-2.0beta2.tar.gz
# cd ipfwadm-2.0beta2
# make install
# cp ipfwadm.8 /usr/man/man8
# cp ipfw.4 /usr/man/man4
</verb></tscreen>

<sect1>I programmi AX.25.
<p>

Una volta compilato in nuovo kernel e fatto il reboot con questo,
occorre compilare i programmi per l'utente. Per compilarli e
installarli occorre dare una sequenza di comandi simili a questi:

<tscreen><verb>
# cd /usr/src
# tar xvfz ax25-utils-2.1.42a.tar.gz
# cd ax25-utils-2.1.42a
# make config
# make
# make install
</verb></tscreen>

Questi file verranno installati come scelta predefinita sotto la
directory <tt>/usr</tt> nei direttori <tt/bin/, <tt/sbin/, <tt/etc/ e
<tt/man/.

<p>

Se sulla vostra macchina non sono mai state installati i programmi
per AX.25, dovete dare anche il comando:
<tscreen><verb>
# make installconf
</verb></tscreen>

per installare anche alcune configurazioni di esempio nella directory
<tt>/etc/ax25/</tt> su cui provare a mettere le mani.


<p>
Se durante la compilazione vi escono messaggi del tipo:
<verb>
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.)
</verb>

dovete controllare con la massima attenzione di avere il pacchetto
<em>ncurses</em> installato correttamente sul vostro sistema. Lo
script di configurazione cerca le ncurses nelle directory standard,
ma alcune installazioni le installano in modo non corretto per cui
non è in grado di trovarle.


<sect>Due parole prima di partire sui nominativi, indirizzi 
e simili.
<p>

Ogni porta AX.25 e NetRom sul vostro sistema deve avere un
nominativo/ssid associato ad essa. Queste sono configurate nei file
di configurazione che saranno descritti in dettaglio tra poco.
<p>

Alcune implementazioni AX.25 come NOS e BPQ permettono però, di
configurare lo stesso nominativo/ssid sulla stessa porta AX.25 e
NetRom, ma per ragioni tecniche un po' complesse, Linux non lo
consente; questo, alla fine, non è un grosso problema, come potrebbe
sembrare a prima vista.
<p>


Occorre dunque tenere a mente le seguenti cose, mentre si configura
il proprio sistema:

<p>
<enum>
<item>Ogni porta AX.25 e NetRom deve essere configurata con un
singolo nominativo/ssid

<item>Il TCP/IP usa il nominativo/ssid della porta usata per ricevere
o trasmettere dati, cioè quella configurata per l'interfaccia AX.25
al punto 1.

<item>Il NetRom usa il nominativo/ssid  specificato nel proprio file
di configurazione, ma esso viene usato solo quando si parla con un
altra stazione NetRom; questo <bf/non/ è il nominativo/ssid che
useranno gli utenti AX.25 che intendono usare il vostro `nodo'
NetRom. Ne parleremo più diffusamente tra un po'. 

<item>Il Rose usa di default il nominativo/ssid  delle porte AX.25,
eccetto il caso che il nominativo per Rose sia stato espressamente
settato col comando `<em/rsparms/'. In questo caso il Rose utilizzerà
il nominativo/ssid  scelto per tutte le porte.

<item>Altri programmi, come `<em/ax25d/' possono usare ogni
nominativo/ssid  per ascoltare, e ciò può essere duplicato su diverse
porte.

<item>Se si effettua un attenta operazione di routing, si può usare,
se si vuole, lo stesso indirizzo IP su tutte le porte.

</enum>

<sect1>Il significato di T1, T2, N2 eccetera.
<p>

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

<tscreen><verb>
-------------------------------------------------------------------
Linux  | TAPR TNC | Descrizione
-------------------------------------------------------------------
T1     | FRACK    | Tempo di attesa prima di ritrasmettere
       |          | un frame non confermato (senza acknowledge)
-------------------------------------------------------------------
T2     | RESPTIME | Tempo minimo di attesa di ricezione 
       |          | di un altro frame prima dell'invio 
       |          | della conferma.
-------------------------------------------------------------------
T3     | CHECK    | Periodo di attesa prima di inviare un segnale
       |          | che controlli se il collegamento è ancora attivo.
-------------------------------------------------------------------
N2     | RETRY    | Quante volte ritrasmettere un frame prima
       |          | di considerare interrotta la connessione.
-------------------------------------------------------------------
Idle   |          | Periodo di inattività della connessione
       |          | prima di essere interrotta.
-------------------------------------------------------------------
Window | MAXFRAME | Massimo numero di frame trasmessi senza
       |          | avere conferma di ricezione.
-------------------------------------------------------------------
</verb></tscreen>

<sect1>Parametri configurabili durante il funzionamento.
<p>
I kernel <tt/2.1.*/ e <tt/2.0.* +moduleXX/ hanno la nuova proprietà
di poter cambiare durante il funzionamento parametri che
precedentemente non era possibile modificare. Se si controlla
con attenzione la directory <tt>/proc/sys/net/</tt> si possono notare
diversi file con nomi che descrivono diversi parametri della
configurazione della rete. Ognuno dei file nella directory
<tt>/proc/sys/net/ax25/</tt> rappresenta una porta AX.25 configurata.
Il nome del file si riferisce al nome della porta.



La struttura dei file in <tt>/proc/sys/net/ax25/&lt;portname>/</tt> è
la seguente:
<verb>
Nome File             Significato           Valori             Default
ip_default_mode	      Modo IP di default    0=DG 1=VC                0
ax25_default_mode     Modo AX.25 di default 0=Normale 1=Esteso       0
backoff_type          Backoff               0=Lineare 1=Esponenziale 1
connect_mode          Modo Connesso         0=No 1=Sì                1
standard_window_size  Finestra Standard     1  <= N <= 7             2
extended_window_size  Finestra Estesa       1  <= N <= 63            32
t1_timeout            Valore di T1          1s <= N <= 30s           10s
t2_timeout            Valore di T2          1s <= N <= 20s           3s
t3_timeout            Valore di T3          0s <= N <= 3600s         300s
idle_timeout          Valore di Idle        0m <= N                  20m
maximum_retry_count   N2                    1  <= N <= 31            10
maximum_packet_length Lunghezza frame AX.25 1  <= N <= 512           256
</verb>

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.

<p>

La struttura dei file in <tt>/proc/sys/net/netrom/</tt> è la
seguente:
<verb>
Nome File                      Valori                  Default
default_path_quality                                   10
link_fails_count                                       2
network_ttl_initialiser                                16
obsolescence_count_initialiser                         6
routing_control                                        1
transport_acknowledge_delay                            50
transport_busy_delay                                   1800
transport_maximum_tries                                3
transport_requested_window_size                        4
transport_timeout                                      1200
</verb>

<p>

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

<verb>
Nome File                      Valori                  Default
acknowledge_hold_back_timeout                          50
call_request_timeout                                   2000
clear_request_timeout                                  1800
link_fail_timeout                                      1200
maximum_virtual_circuits                               50
reset_request_timeout                                  1800
restart_request_timeout                                1800
routing_control                                        1
window_size                                            3
</verb>

<p>

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:
<tscreen><verb>
# cat /proc/sys/net/rose/window_size 3
# echo 4 >/proc/sys/net/rose/window_size
# cat /proc/sys/net/rose/window_size 4
</verb></tscreen>

<sect>Configurazione di una porta AX.25.
<p>

Ogni applicazione che fa uso del protocollo AX.25 legge un file di
configurazione per sapere i parametri delle varie porte AX.25
attivate sulla macchina Linux. Il file in questione è
<tt>/etc/ax25/axport</tt> e occorre che vi sia una voce per ognuna
delle porte attive.

<sect1>Creazione del device di rete AX.25.
<p>

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

<p>

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

Ogni device driver, quando viene lanciato, crea un device di rete.

<sect2>Creazione di un device KISS<p>
<bf/Opzioni di compilazione del Kernel/:
<tscreen><verb>
General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Serial port KISS driver for AX.25
</verb></tscreen>

Probabilmente la configurazione più comune è quella con un TNC KISS
su una porta seriale. Visto che occorre partire col TNC in modo KISS,
dopo averlo connesso alla porta seriale, lo si può configurare con
programmi di comunicazione come <em>minicom</em> o <em>seyon</em>.



<p>

Per creare un device KISS si usa il programma <em/kissattach/. Nella
sua forma più semplice si può usare questo programma come segue:

<tscreen><verb>
# /usr/sbin/kissattach /dev/ttyS0 radio
# kissparms -p radio -t 100 -s 100 -r 25
</verb></tscreen>

Il comando <em/kissattach/ crea in device di rete di tipo KISS. I
device di questo tipo hanno nome `<tt/ax[0-9]/'. La prima volta che
si usa <em/kissattach/ viene creato `<tt/ax0/', la seconda `<tt/ax1/'
e così via. Ogni device KISS ha associato una porta seriale.

<p>

Il comando <em/kissparms/ permette di modificare i parametri di un
device KISS
<p>

In particolare nell'ultimo esempio viene creato un device KISS usando
il device della porta seriale `<tt>/dev/ttyS0</tt>' e la voce nel
file <tt>/etc/ax25/axports</tt> con una porta chiamata `<tt/radio/'
che viene configurata inoltre con un <em/txdelay/ e uno <em/slottime/
di 100 millisecondi, nonchè con un valore di <em/ppersist/ pari a 25 
<p>

Per maggiori informazioni potete far riferimento alle pagine <em/man/ 

<sect3>Configurazione di un TNC Dual Port
<p>

L'utility <em/mkiss/ inclusa in ax25-utils permette di usare entrambi
i modem di un TNC dual port. La configurazione è piuttosto semplice e
consiste nel prendere un singolo device seriale connesso ad un
singolo TNC multiporta e facendolo apparire come diversi device
connessi ognuno ad un TNC single port. Questa operazione va fatta
<bf/prima/ di ogni configurazione della parte AX.25. I device sui
quali si effettua la configurazione AX.25 sono interfacce pseudo-TTY,
(<tt>/dev/ttyq*</tt>), e non gli effettivi device seriali.

I device pseudo-TTY creano una specie di tunnel detto pipe attraverso il  quale
possono parlarsi i programmi che devono colloquiare con i device TTY.
Ogni pipe è composta da una parte master e da una parte slave. La
parte master è in genere chiamata `<tt>/dev/ptyq*</tt>', mentre
quella slave è chiamata `<tt>/dev/ttyq*</tt>'. C'è una relazione uno
a uno tra master e slave, quindi, ad esempio, <tt>/dev/ptyq0</tt> è
la parte master di una pipe che ha <tt>/dev/ttyq0</tt> come slave.
Occorre aprire per prima la parte master di una pipe. <em/mkiss/
sfrutta questo meccanismo per dividere una singola porta seriale in
diversi device.


<p>

Esempio: nel caso di un TNC dual port connesso alla porta seriale
<tt>/dev/ttyS0</tt> a 9600 bps, i comandi

<tscreen><verb>
# /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
# /usr/sbin/kissattach /dev/ttyq0 port1
# /usr/sbin/kissattach /dev/ttyq1 port2
</verb></tscreen>

creano due device pseudo-tty ognuna delle quali si comporta come un
TNC single port. A questo punto si può usare <tt>/dev/ttyq0</tt> e
<tt>/dev/ttyq1</tt> come se fossero dei normali device seriali con un
TNC connesso. Questo significa che si dovrà usare <em/kissattach/ per
ognuna di essi, come descritto nell'esempio sopra per le porte AX.25
chiamate port1 e port2. Non si deve usare <em/kissattach/ sulla porta
seriale vera poiché viene usata dal programma <em/mkiss/.

<p>

Il programma <em/mkiss/ ha diversi argomenti opzionali che possono
essere usati:
<descrip>
<tag>-c</tag>aggiunge un byte di checksum per ogni frame KISS; la
maggior parte delle implementazioni non supporta questa opzione, che è
invece presente in quella di G8BPG
<tag>-s &lt;velocità&gt;</tag>modifica la velocità della porta
seriale.
<tag>-h</tag>abilita l'handshaking hardware sulla porta seriale; è
disabilitata di default poiché quest'opzione non è supportata dalla
maggior parte delle implementazioni KISS.
<tag>-l</tag>abilita il logging delle informazioni nel file
<em/syslog/.
</descrip>

<sect2>Creazione di un device Baycom.
<p>
<bf/Opzioni di compilazione del Kernel/:
<tscreen><verb>
Code maturity level options  --->
    [*] Prompt for development and/or incomplete code/drivers
General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] BAYCOM ser12 and par96 driver for AX.25
</verb></tscreen>

Thomas Sailer, <tt>&lt;sailer@ife.ee.ethz.ch></tt>, a dispetto del
luogo comune che non funzioni bene(?), ha sviluppato il supporto
Linux per i modem Baycom. Il suo driver supporta il modem seriale
<tt>Ser12</tt> e i modem paralleli <tt>Par96</tt> e <tt>PicPar</tt>.
Maggiori informazioni sui modem possono essere reperite presso il
<url url="http://www.baycom.de/" name="Baycom Web site">.

<p>

Il primo passo da compiere è quello di determinare gli indirizzi di
I/O della porta seriale o parallela alla quale è connesso il Baycom.
Una volta fatto, si possono usare queste informazioni per configurare
il driver.

<p>

Il driver Baycom, alla configurazione, crea dei device di rete
chiamati <tt/bc0/, <tt/bc1/, <tt/bc2/ ecc.
<p>

L'utility <em/sethdlc/ permette di configurare i parametri del
driver, cosa che può essere fatta anche nella linea di comando di
<em/insmod/ al caricamento del modulo di controllo del Baycom
<p>

Segue una piccola configurazione di esempio che:

Disabilita il driver seriale per COM1 (per evitare conflitti, visto
che accede alla stessa porta fisica del Baycom) e configura il driver
Ser12 per un Baycom connesso a COM1 con il rilevamento software di
portante (DCD) attivato.
<tscreen><verb>
# setserial /dev/ttyS0 uart none
# insmod hdlcdrv
# insmod baycom mode="ser12*" iobase=0x3f8 irq=4
</verb></tscreen>

Installa un Baycom Parallelo su LPT1 usando il rilevamento DCD
hardware.

<tscreen><verb>
# insmod hdlcdrv
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0
</verb></tscreen>

Questo modo di configurare il driver per Baycom in realtà non è molto
consigliato, visto che l'utility <em/sethdlc/ funziona senza problemi
anche con un solo dispositivo connesso.

<p>

Le pagine <em/man/ di <em/sethdlc/ contengono tutti i dettagli
relativi a questo comando, tuttavia si forniscono un paio di esempi
per illustrare gli aspetti più importanti di questo tipo di
configurazione. Gli esempi presuppongono che sia già stato caricato
il modulo per il supporto del Baycom coi comandi
<tscreen><verb>
# insmod hdlcdrv
# insmod baycom
</verb></tscreen>

o che il kernel sia stato compilato col supporto Baycom al suo
interno.
<p>

Configurazione del device driver <tt/bc0/ come modem Baycom parallelo
su LPT1 con DCD software:
<tscreen><verb>
# sethdlc -p -i bc0 mode par96 io 0x378 irq 7
</verb></tscreen>


Configurazione del device driver <tt/bc1/ come modem Baycom seriale
su COM1 :
<tscreen><verb>
# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
</verb></tscreen>

<sect2>Configurazione dei parametri dei accesso al canale AX.25.
<p>

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 <em/sethdlc/ .
<p>

Segue un esempio; per maggiori informazioni la pagina man relativa a
<em/sethdlc/ è il posto  più indicato dove reperire le informazioni
più dettagliate.
<p>

Configurazione del device <tt/bc0/ con TxDelay di 200 mS, SlotTime di
100 mS, PPersist di 40 in modalità half duplex:

<tscreen><verb>
# sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
</verb></tscreen>

Si noti che i valori di temporizzazione sono in millisecondi.

<sect3>Configurazione del Kernel AX.25 per l'uso con un modem Baycom
<p>

Il driver Baycom crea dei device 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.
<p>

Il primo passo è quello di configurare il device con un nominativo
AX.25. L'utility <em/ifconfig/ può essere utile allo scopo.
<tscreen><verb>
# /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
</verb></tscreen>

assegna al device Baycom <tt/bc0/ il nominativo AX.25 <tt/VK2KTJ-15/.
In alternativa sarebbe possibile usare il comando <em/axparms/, ma
occorrerebbe sempre l'uso di <em/ifconfig/ per attivare il
device.
<tscreen><verb>
# ifconfig bc0 up
# axparms -setcall bc0 vk2ktj-15
</verb></tscreen>
<p>

Il passo successivo è quello di creare una voce nel file
<tt>/etc/ax25/axports</tt> come si farebbe per ogni altro device. La
voce nel file <tt/axports/ è associata col device di rete configurato
per il nominativo ad esso legato. La voce nel file axports che ha il
nominativo con il qual si è configurato il devide BayCom è quella che
verrà usata per riferirlo.
<p>

A questo punto si userà il nuovo device AX.25 come ogni altro; lo si
potrà configurare per l'uso col TCP/IP, aggiungerlo ad ax25d e usarci
sopra NetRom e Rose a proprio piacimento.

<sect2>Creazione di un device SoundModem.
<p>
<bf/Opzioni di compilazione del Kernel/:
<tscreen><verb>
Code maturity level options  --->
    [*] Prompt for development and/or incomplete code/drivers
General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Soundcard modem driver for AX.25
    [?] Soundmodem support for Soundblaster and compatible cards
    [?] Soundmodem support for WSS and Crystal cards
    [?] Soundmodem support for 1200 baud AFSK modulation
    [?] Soundmodem support for 4800 baud HAPN-1 modulation
    [?] Soundmodem support for 9600 baud FSK G3RUH modulation
</verb></tscreen>

Thomas Sailer ha sviluppato un nuovo driver per il kernel che
permette l'uso come modem della scheda audio che, 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 è compiuta
dalla CPU del calcolatore.

<p>

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.
Questo sistema richiede un circuito addizionale, per poter far
pilotare dalla scheda audio il PTT della radio; per sapere come
realizzarlo si può andare alla  
<url
url="http://www.ife.ee.ethz.ch/~sailer/pcf/ptt&lowbar;circ/ptt.html"
	name="Thomas's SoundModem PTT circuit web page">. Sono possibili
	diverse opzioni che spaziano dal recuperare l'uscita audio della
	scheda, usare l'uscita di una porta parallela o di una porta
	midi. Esempi di circuito sono sul sito di Thomas Sailer.

<p>

Quando viene configurato, il driver SoundModem crea dei device di
rete chiamati:
<tt/sm0/, <tt/sm1/, <tt/sm2/.
<p>
<bf>Nota</bf>: il driver SoundModem usa le stesse risorse de driver
sonoro di Linux, per cui se si vuole usare il modem, occorre
accertarsi che il driver sonoro non sia installato.  Si puo
naturalmente compilare entrambi i driver come moduli in modo da
inserirli e rimuoverli a piacimento.


<sect3>Configurazione della scheda audio.
<p>

Il driver SoundModem non inizializza la scheda audio, per cui occorre
utilizzare l'apposito programma `<em/setcrystal/' presente nelle
ax25-utils che può essere usato con schede basate sul chipset Crystal
(con altre schede occorrerà usare altri programmi per inizializarle).

La sua sintassi è piuttosto semplice: 
<tscreen><verb>
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c
dma2]
</verb></tscreen>

Quindi, volendo configurare una SoundBlaster all'indirizzo base di
i/o 0x388, irq 10 e dma 1 si userà:
<tscreen><verb>
# setcrystal -s 0x388 -i 10 -d 1
</verb></tscreen>

Mantre per una scheda WindowSoundSystem all'indirizzo base di i/o
0x534, irq 5 e dma 3 si userà:

<tscreen><verb>
# setcrystal -w 0x534 -i 5 -d 3
</verb></tscreen>

Il parametro <tt/[-f synthio]/ modifica l'indirizzo del
sintetizzatore, mentre <tt/[-c dma2]/ serve per settare il secondo
canale DMA per permettere operazioni in full duplex 


<sect3>Configurazione del driver SoundModem.
<p>

Una volta configurata la scheda audio occorre configurare il driver,
indicandogli l'indirizzo della scheda e che tipo di modem emulare.
<p>

L'utility <em/sethdlc/ permette di configurare il driver con questi
parametri o, se si ha solo una scheda audio installata, si può
specificarne i parametri dalla linea di comando di <em/insmod/ quando
si carica il modulo SoundModem.
<p>

L'esempio seguente configura la SoundBlaster nel modo già visto
precedentemente ed in modo da emulare un modem a 1200 bps:
<tscreen><verb>
# insmod hdlcdrv
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
</verb></tscreen>

Non è in effetti il modo migliore per effettuare le modifiche dato
che, come detto già precedentemente, l'utility <em/sethdlc/ funziona
senza particolari problemi con una o più device.
<p>

Le pagine <em/man/ di <em/sethdlc/ contengono tutti i dettagli
relativi a questo comando, tuttavia si forniscono un paio di esempi
per illustrare gli aspetti più importanti di questo tipo di
configurazione. Gli esempi presuppongono che sia già stato caricato
il modulo SoundModem coi comandi:

<tscreen><verb>
# insmod hdlcdrv
# insmod soundmodem
</verb></tscreen>

o che il kernel sia stato compilato con incluso il driver.
<p>

Configurazione della scheda WindowsSoundSystem configurata come negli
esempi precedenti e settata in modo da emulare un modem G3RUH 9600
compatible come device <tt/sm0/ usando la porta parallela
all'indirizzo 0x378 per pilotare il Push-To-Talk della radio.
<tscreen><verb>
# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
</verb></tscreen>

Configurazione del driver per supportare la SoundBlaster configurata
come negli esempi precedenti e settata in modo da emulare un modem
4800 bps HAPN come device <tt/sm1/ usando la porta seriale
all'indirizzo 0x2f8 per pilotare il Push-To-Talk della radio.

<tscreen><verb>
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio
0x2f8
</verb></tscreen>

Configurazione del driver per supportare la SoundBlaster configurata
come negli esempi precedenti e settata in modo da emulare un modem
1200 bps AFSK come device <tt/sm1/ usando la porta seriale
all'indirizzo 0x2f8 per pilotare il Push-To-Talk della radio.

<tscreen><verb>
# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio
0x2f8
</verb></tscreen>
<sect3>Configurazione dei parametri dei accesso al canale canale AX.25.

<p>

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 <em/sethdlc/ .

<p>

Seguono un paio di esempi; per maggiori informazioni la pagina man
relativa a <em/sethdlc/ è il posto  più indicato dove reperire le
informazioni più dettagliate.

<p>

Configurazione del device <tt/sm0/ con TxDelay di 100 mS, SlotTime di
50 mS, PPersist di 120 in modalità full duplex:

<tscreen><verb>

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

</verb></tscreen>

Si noti che i valori di temporizzazione sono in millisecondi.

<sect3>Messa a punto del driver e del livello audio.
<p>

Per ogni modem radio è molto importante che i livelli audio siano
settati correttamente e il SoundModem non fa eccezione. Thomas Sailer
ha per questo scritto alcne utility che facilitano questo compito,
chiamate <em/smdiag/ e <em/smmixer/.
<p>
<descrip>
<tag><em/smdiag/</tag>fornisce due tipi di visualizzazione del
segnale in ingresso: come osilloscopio e con un diagramma ad occhio.

<tag><em/smmixer/</tag>permette di effettuare l modifica del livello
audio in ricezione ed in trasmissione.

</descrip>

Per lanciare l'utility <em/smdiag/ per il device SoundModem <tt/sm0/
in modalità 'diagramma ad occhio' si usa il comando:
<tscreen><verb>
# smdiag -i sm0 -e
</verb></tscreen>


Per lanciare l'utility <em/smmixer/ per il device SoundModem <tt/sm0/
si usa il comando:

<tscreen><verb>
# smmixer -i sm0
</verb></tscreen>


<sect3>Configurazione del Kernel AX.25 per l'uso con SoundModem

<p>

Il driver Baycom crea dei device 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.

<p>

Il primo passo è quello di configurare il device con un nominativo
AX.25. l'utility <em/ifconfig/ può essere utile allo scopo.

<tscreen><verb>

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

</verb></tscreen>

assegna al device SoundModem <tt/sm0/ il nominativo AX.25
<tt/VK2KTJ-15/. In alternativa sarebbe possibile usare il comando
<em/axparms/, ma occorrerebbe sempre l'uso di <em/ifconfig/ per
attivare il device.

<tscreen><verb>

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

</verb></tscreen>

<p>

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

<p>

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


<sect2>Creazione di un device per scheda PI.
<p>
<bf/Opzione di compilazione del Kernel/:
<tscreen><verb>
General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Ottawa PI and PI/2 support for AX.25
</verb></tscreen>


Il device driver per schede PI crea dei device chiamati
`<tt/pi[0-9][ab]/'. La prima scheda PI sarà indicata come `<tt/pi0/',
la seconda  `<tt/pi1/', eccetera. Le lettere `<tt/a/' e `<tt/b/' si
riferiscono rispettivamente alla prima e alla seconda interfaccia
fisica delle schede PI. Se si è compilato il Kernel in modo da
includere il driver per la scheda e questa è stata riconosciuta dal
sistema in modo esatto, si può usare il seguente comando per
configurare il device di rete:

<tscreen><verb>
# /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
</verb></tscreen>

Questo comando configura ed attiva la prima porta della prima scheda
PI assegnandole il nominativo <tt/VK2KTJ-15/. Per usare il
dispositivo, tutto ciò che serve a questo punto è di inserire una
voce nel file <tt>/etc/ax25/axports</tt> col medesimo
nominativo/ssid.

<p>
Il driver per la scheda PI è stato scritto da
<tt>David Perry, &lt;dp@hydra.carleton.edu></tt>

<sect2>Creazione di un device PacketTwin.
<p>
<bf/Opzioni di compilazione del Kernel/:
<tscreen><verb>
General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Gracilis PackeTwin support for AX.25 
</verb></tscreen>

Il device driver per la scheda PacketTwin crea i device
`<tt/pt[0-9][ab]/'; la prima scheda PacketTwin localizzata nel
calcolatore sarà indicata come `<tt/pt0/', la seconda `<tt/pt1/' e
così via, mentre`<tt/a/' and `<tt/b/' fanno riferimento alla prima e
alla seconda interfaccia fisica della scheda PacketTwin. Una volta
compilato il kernel con incluso il driver per la scheda PacketTwin,
se quest'ultima è stata correttamente riconosciuta, si possono usare
i seguenti comandi per configurare i device di rete:

<tscreen><verb>
# /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
</verb></tscreen>


Questo comando configura e attiva la prima porta della prima scheda
PacketTwin col nominativo <tt/VK2KTJ-15/. Per usare il device, tutto
ciò che occorre fare è confiurare una voce nel proprio file
<tt>/etc/ax25/axports</tt> con il medesimo nominativo/ssid.

<p>

Il driver per schede PacketTwin è stato scritto da
<tt>Craig Small VK2XLZ, &lt;csmall@triode.apana.org.au></tt>.

<sect2>Creazione di un generico device SCC.
<p>
<bf/Opzioni di compilazione del Kernel/:
<tscreen><verb>
General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Z8530 SCC KISS emulation driver for AX.25
</verb></tscreen>

Joerg Reuter, DL1BKE, <tt/jreuter@poboxes.com/ ha sviluppato il
supporto generico per le schede basate sullo Z8530 SCC. Il suo driver
permette il supporto di diversi tipi di queste schede e offre una
modalità di utilizzo simile a quella di un TNC KISS.


<sect3>Reperire e compilare i programmi di configurazione.
<p>

Sebbene il driver sia incluso nella distribuzione standard del
Kernel, Joerg Reuter distribuisce versioni più recenti del suo driver
assieme ad una collezione di programmi che ne aiutano la
configurazione.

<p>

I programmi di configurazione possono essere scaricati dalla 
<url name="pagina web di Joerg" url="http://www.rat.de/jr/">

o da:

<bf>db0bm.automation.fh-aachen.de</bf>
<tscreen><verb>
/incoming/dl1bke/
</verb></tscreen>

o:

<bf>insl1.etec.uni-karlsruhe.de</bf>
<tscreen><verb>
/pub/hamradio/linux/z8530/
</verb></tscreen>

o:

<bf>ftp.ucsd.edu</bf>
<tscreen><verb>
/hamradio/packet/tcpip/linux
/hamradio/packet/tcpip/incoming/
</verb></tscreen>

<p>

Troverete diverse versioni; va scelta quella che maggiormente si
adatta alla versione di Kernel che si intende usare.

<verb>
z8530drv-2.4a.dl1bke.tar.gz   2.0.*
z8530drv-utils-3.0.tar.gz    2.1.6 o superiore
</verb>

<p>

I seguenti comandi mi hanno permesso di compilare ed installare il
pacchetto per la versione 2.0.30 del kernel
<tscreen><verb>
# cd /usr/src
# gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
# cd z8530drv
# make clean
# make dep
# make module         # Se volete avere il driver compilato come modulo
# make for_kernel     # Se volete avere il driver incluso nel kernel
# make install
</verb></tscreen>
<p>

Dopo aver completato quest'operazione dovreste avere tre nuovi
programmi installati nella vostra directory <tt>/sbin</tt>:
<em>gencfg</em>, <em>sccinit</em> e <em>sccstat</em>. Questi
permetteranno di configurare il driver per la scheda.
<p>

Verrà anche creato nella directory <tt>/dev</tt> un un gruppo di
device speciali chiamati <tt>scc0</tt>-<tt>scc7</tt>; questi saranno
trattati in dettaglio più avanti e saranno i device `KISS' da
utilizzare.
<p>

Se scegliete l'opzione 'make for&lowbar;kernel' occorrre ricompilare
il kernel. Per far sì che venga incluso il supporto per il driver
z8530 occorre rispondere `<tt>Y</tt>' alla domanda `<tt>Z8530 SCC
kiss emulation driver for AX.25</tt>' che viene fatta dalla procedura
di configurazione del kernel, ossia quando si dà il comando `<tt>make
config</tt>'.
<p>

Se invece avete fatto 'make module', occorre che il nuovo file
<tt/scc.o/ sia messo nella directory <tt>/lib/modules</tt>, ma non
occorre ricompilare il kernel. Si ricordi di usare il comando
<em/insmod/ per caricare il modulo prima di provare a configurarlo.

<sect3>Configurazione del driver per la propria scheda.
<p>

Il driver per scheda SCC z8530 è stato concepito per garantire la
massima flessibilità e di supportare il maggior numero di schede.
Questa flessibilità porta però come conseguenza una configurazione
piuttosto impegnativa.
<p>

Nel paccheto è fornita un'esauriente documentazione che va letta in
caso di difficoltà. In particolare, maggiori informazioni si possono
trovare in <tt>doc/scc&lowbar;eng.doc</tt> or
<tt>doc/scc&lowbar;ger.doc</tt>. In questo documento vengono ripresi
i concetti fondamentali, ma si invita a consultare i file indicati
nel caso si richieda un livello di dettaglio maggiore.
<p>

Il file di configurazione principale è <tt>/etc/z8530drv.conf</tt> e
viene letto dal programma <em>sccinit</em>, Questo file  è diviso in
due parti: configurazione dei parametri hardware e configurazione del
canale. Una volta adattato opportunamente questo file alle vostre
esigenze, basta aggiungere 

<tscreen><verb>
# sccinit
</verb></tscreen>


nel file <tt>rc</tt> che configura la rete, e il driver sarà
inizializzato nel modo indicato dal file di configurazione. Questa
operazione va fatta prima di provare ad usare il driver,
naturalmente.


<sect4>Configurazione dei parametri hardware.
<p>

La prima sezione è divisa in due sottoparti, ognuna delle quali
rappresenta la configurazione per un chip 8530 ed è costituita da una
lista di parole chiave con valori associati. In questo file si
possono specificare fino a quattro chip SCC di default. Il valore
<tt>#define MAXSCC 4</tt> nel file <tt>scc.c</tt> può essere
aumentato se si desidera il supporto per un numero maggiore di chip.
<p>

Le parole chiave possibili e i relativi argomenti sono:

<descrip>
<tag>chip</tag> serve per separare le sottosezioni. Non usa
argomenti.

<tag>data&lowbar;a</tag>specifica l'indirizzo della porta dati per il
canale `A' dello z8530. L'argomento è un numero esadecimale, ad
esempio 0x300

<tag>ctrl&lowbar;a</tag>specifica l'indirizzo della porta di
controllo per il canale `A' dello z8530. L'argomento è un numero
esadecimale, ad esempio 0x304

<tag>data&lowbar;b</tag>specifica l'indirizzo della porta dati per il
canale `B' dello z8530. L'argomento è un numero esadecimale, ad
esempio 0x301

<tag>ctrl&lowbar;b</tag>specifica l'indirizzo della porta di
controllo per il canale `A' dello z8530. L'argomento è un numero
esadecimale, ad esempio 0x305
<tag>irq</tag>specifica l'IRQ (l'interupt) usata dalla scheda SCC
8530 descritta in questa sottosezione. L'argomento è un intero, ad
esempio 5

<tag>pclock</tag>specifica la frequenza del clock al pin PCLK
dell'8530. L'argomento è un intero che indica la frequenza in Hz, ed
è fissato di default a 4915200 se si omette questa parola chiave.

<tag>board</tag>specifica il tipo particolare di scheda SCC 8530.
L'argomento è una stringa alfanumerica che può assumere i seguenti
valori:

<descrip>
<tag>PA0HZP</tag>scheda PA0HZP SCC
<tag>EAGLE</tag>Scheda Eagle
<tag>PC100</tag>scheda DRSI PC100 SCC
<tag>PRIMUS</tag>scheda PRIMUS-PC (DG9BL)
<tag>BAYCOM</tag>scheda BayCom (U)SCC
</descrip>
<tag>escc</tag>questa parola chiave è opzionale; viene usata per
abilitare il supporto per i chip Extended SCC (ESCC) come l'8580,
85180 o 85280. L'argomento è una stringa di caratteri i cui unici
valori ammessi sono `yes' oppure `no', che è il valore didefault.

<tag>vector</tag>questa parola chiave è opzionale; specifica
l'indirizzo del `vector latch' (conosciuto pure come "intack port")
per le schede PA0HZP. Ci può essere solo un vector latch per tutti i
chip e il valore di default è 0

<tag>special</tag>questa parola chiave è opzionale; specifica
l'indirizzo del registro per funzioni speciali presente su diverse
schede SCC. Il valore di default è 0

<tag>option</tag>questa parola chiave è opzionale e il suo valore di
default è 0 (sic, n.d.t.).
</descrip>


Seguono alcuni configurazioni d'esempio per le schede più comuni:

<descrip>
<tag>BayCom USCC</tag><tscreen><verb>
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
</verb></tscreen>
<tag>Scheda PA0HZP SCC</tag><tscreen><verb>
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
</verb></tscreen>
<tag>Scheda DRSI SCC</tag><tscreen><verb>
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
</verb></tscreen>
</descrip>

Se con NOS si ha già una configurazione funzionante per la vostra
scheda, si può usare il comando <em>gencfg</em> per convertire i
comandi del driver NOS di PE1CHL in una forma che possa andare bene
nel file di configurazione del driver z8530.

<p>

Per usare <em>gencfg</em> basta invocare il comando con gli stesi
parametri usati per il driver di PE1CHL in NET/NOS. Per esempio il
comando:
<tscreen><verb>
# gencfg 2 0x150 4 2 0 1 0x168 9 4915200
</verb></tscreen>

genererà un abbozzo di configurazione per la scheda OptoSCC.

<sect3>Configurazione del canale
<p>

La sezione di configurazione del canale è quella nella quale si
specificano tutte gli altri parametri associati con la porta che si
sta configurando. Anche questa è divisa in due sottosezioni che
rappresentano ciascuna una porta logica, quindi , visto che ogni
scheda SCC 8530 ne supporta due, saranno presenti due sottosezioni
per ogni sottosezione nella parte dei parametri hardware.
<p>

Queste parole chiave sono scritte anche nel file
<tt>/etc/z8530drv.conf</tt>

e devono apparire <bf>dopo</bf> la sezione dei parametri hardware.
<p>

L'ordine in cui queste appaiono è molto importante, ma quello in cui
sono presentate qui dovrebbe andare bene.
<descrip>
<tag>device</tag>questa parola chiave deve apparire all'inizio della
definizione della porta e specifica il nome del device file speciale
al quale si applica il resto dei parametri di configurazione; ad
esempio <tt>/dev/scc0</tt>

<tag>speed</tag>questa parola chiave specifica la velocità
dell'interfaccia in bit al secondo: ad esempio <tt>1200</tt>

<tag>clock</tag>questa parola chiave specifica da dove recuperare il
clock per i dati. I valori consentiti sono:

	<descrip>
	<tag>dpll</tag>normali operazioni in half duplex
	<tag>external</tag>il modem fornisce il proprio clock per le
	operazioni di Rx/TX

	<tag>divider</tag>usa il divider full duplex se installato.
	</descrip>
<tag>mode</tag>questa parola chiave specifica il tipo di codifica da
adottare per la rappresentazione dei dati. I valori consentiti sono
<tt>nrzi</tt> or <tt>nrz</tt>

<tag>rxbuffers</tag>specifica il numero di buffer di ricezione per
cui allocare memoria. L'argomento è un intero, ad esempio 8.
<tag>txbuffers</tag>specifica il numero di buffer di trasmissione per
cui allocare memoria. L'argomento è un intero, ad esempio 8.

<tag>bufsize</tag>specifica la dimensione dei buffer di ricezione e
trasmissione. L'argomento è in byte e rappresenta la lunghezza totale
del frame, compreso l'header AX.25 (non solo la parte dati). Questa
parola chiave è opzionale e il suo valore di default è <tt>384</tt>

<tag>txdelay</tag>rappresenta il parametro KISS di ritardo nella
trasmissione; l'argomento è un intero ed esprime una grandezza in ms.
<tag>persist</tag>rappresenta il parametro KISS di persist e il suo
argomento è un intero.
<tag>slot</tag>rappresenta il parametro KISS di tempo di slot;
l'argomento è un intero ed esprime una grandezza in ms.
<tag>tail</tag>rappresenta il parametro KISS di tail; il suo
argomento è un intero ed esprime una grandezza in ms.
<tag>fulldup</tag>rappresenta il flag KISS che indica se la
trasmissione è in full duplex; l'argomento è un intero e i valori
ammessi sono:
<tt>1</tt>==Full Duplex, <tt>0</tt>==Half Duplex.
<tag>wait</tag>rappresenta il parametro KISS di tempo di wait;
l'argomento è un intero ed esprime una grandezza in ms.
<tag>min</tag>rappresenta il parametro KISS 'min'; l'argomento è un
intero ed esprime una grandezza in secondi.
<tag>maxkey</tag>rappresenta il parametro KISS indicante il tempo
massimo di keyup; l'argomento è un intero ed esprime una grandezza in
secondi.
<tag>idle</tag>rappresenta il parametro KISS di tempo di idle;
l'argomento è un intero ed esprime una grandezza in ms.
<tag>maxdef</tag>rappresenta il parametro KISS 'maxdef'; l'argomento
è un intero.
<tag>group</tag>rappresenta il parametro KISS di valore di gruppo;
l'argomento è un intero.
<tag>txoff</tag>rappresenta il parametro KISS di tempo di 'txoff';
l'argomento è un intero ed esprime una grandezza in ms.
<tag>softdcd</tag>rappresenta il parametro KISS 'softdcd';
l'argomento è un intero.
<tag>slip</tag>rappresenta il flag KISS 'slip'; l'argomento è un
intero.
</descrip>

<sect3>Uso del driver.
<p>
Per usare il driver basta semplicemente utilizzare i device
<tt>/dev/scc*</tt> come se si avesse un device seriale tty con un TNC
KISS connesso ad esso. Per esempio, per configurare la parte di
networking del kernel di Linux per l'uso di una scheda SCC, si può
fare in questo modo:
<tscreen><verb>
# kissattach -s 4800 /dev/scc0 VK2KTJ
</verb></tscreen>

Si può anche usare NOS per effettuare la configurazione nello stesso
modo. Da JNOS, per esmpio, si può fare:

<tscreen><verb>
attach asy scc0 0 ax25 scc0 256 256 4800
</verb></tscreen>

<sect3><em>sccstat</em> e <em>sccparam</em>.
<p>
Per la diagnosi di eventuali problemi, si può usare il programma
<em>sccstat</em> per mostrare la configurazione corrente di un device
SCC. Per usarlo si può dare il comando:

<tscreen><verb>
# sccstat /dev/scc0
</verb></tscreen>

in questo modo verranno mostrati un sacco di informazioni sulla
configurazione e sul comportamento della porta SCC
<tt>/dev/scc0</tt>.

<p>
Il comando <em>sccparam</em> permette di cambiare  la configurazione
dopo il boot del sistema. La sua sintassi è molto simile al comando
NOS <tt>param</tt>, quindi, ad esempio, per settare a 100 ms il
valore di <tt>txtail</tt> si puo fare:

<tscreen><verb>
# sccparam /dev/scc0 txtail 0x8
</verb></tscreen>

<sect2>Creazione di un device ethernet BPQ.
<p>
<bf/Opzioni di compilazione del Kernel/:                                                
<tscreen><verb>                                                                 
General setup  --->                                                         
    [*] Networking support                                                  
Network device support  --->                                                    
    [*] Network device support                                              
    ...                                                                         
    [*] Radio network interfaces    
    [*] BPQ Ethernet driver for AX.25
</verb></tscreen>                                                            

Linux supporta compatibilità Ethernet BPQ. Questo permette di
trasportare il protocollo AX.25 su una LAN Ethernet e di connettere
sulla rete locale la macchina Linux con altre macchine BPQ.

<p>
I device di rete BPQ hanno nome `<tt/bpq[0-9]/'. Il device
`<tt/bpq0/' è associato com il device `<tt/eth0/', `<tt/bpq1/' con
`<tt/eth1/' e così via.
<p>
La configurazione è abbastanza semplice. Prima di tutto occorre che
il proprio kernel sia stato compilato per supportare la scheda
Ethernet da utilizzare e che si sia già verificato il corretto
funzionamento di quest'ultima con Linux. Per maggiori informazioni si
può fare riferimento all'<url url="Ethernet-HOWTO.html"
name="Ethernet-HOWTO">.
<p>
Per configurare il supporto BPQ occorre dotare di un nominativo AX.25
il device Ethernet col seguente comando:

<tscreen><verb>
# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
</verb></tscreen>

Ancora una volta si ricordi che il nominativo specificato deve essere
presente anche nel file <tt>/etc/ax25/axports</tt> che si intende
usare per questa porta.

<sect2>Configurazione del nodo BPQ per il colloqio con il supporto AX.25 di Linux.
<p>
A differenza dell'implementazione standard di BPQ Ethernet che usa
normalmente un indirizzamento multicast, in Linux si adotta il
normale indirizzamento broadcast; il file NET.CFG per il driver BPQ
ODI dovrebbe perciò essere modificato per assomigliare a questo:

<tscreen><verb>
LINK SUPPORT

        MAX STACKS 1
        MAX BOARDS 1

LINK DRIVER E2000                    ; o altre MLID che si adattino
                                     ; alla vostra scheda

        INT 10                       ;
        PORT 300                     ; per adattarsi alla vostra
        scheda

        FRAME ETHERNET_II

        PROTOCOL BPQ 8FF ETHERNET_II ; richiesto per BPQ - può
        cambiare
        PID

BPQPARAMS                            ; opzionale - richiesto solo se
                                     ; non si vuole usare l'indirizzo 
                                     ; di default

        ETH_ADDR  FF:FF:FF:FF:FF:FF  ; indirizzo di default
</verb></tscreen>

<sect1>Creazione del file <tt>/etc/ax25/axports</tt>.
<p>
<tt>/etc/ax25/axports</tt> è un semplice file di testo, da creare con
un editor. Il suo formato è il seguente:

<tscreen><verb>
portname  callsign  baudrate  paclen  window  description
</verb></tscreen>

dove:

<descrip>
<tag>portname</tag>è il nome che viene dato alla porta.
<tag>callsign</tag>è il nominativo AX.25 che si vuole assegnare alla
porta.
<tag>baudrate</tag>è la velocità con la quale si vuol far comunicare
la porta col proprio TNC.
<tag>paclen</tag>è la grandezza massima del pacchetto che si vuole
che la porta usi per le trasmissioni AX.25.
<tag>window</tag>è il parametro di finestra AX.25 (K), cioè il valore
di <tt>MAXFRAME</tt> di molti TNC.
<tag>description</tag>è la descrizione della porta.
</descrip>

La mia è la seguente:

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

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

<sect1>Configurazione del routing AX.25.
<p>
E' possibile configurare i digipeater da utilizzare per raggiungere
un host specifico, operazione che risulta utile sia per le operazioni
AX.25 che basate su IP.
Il comando <em/axparms/ permette di effettuare questa operazione; le
pagine <em/man/ sono sempre la fonte migliore di informazioni su
questo comando, ma un semplice esempio può essere:

<tscreen><verb>
# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
</verb></tscreen>

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

<sect>Configurazione di un'interfaccia AX.25 per TCP/IP.
<p>
E' molto semplice configurare una porta AX.25 per il trasporto del
TCP/IP. Se si ha un'interfaccia KISS ci sono due metodi per
configurare un indirizzo IP. Il comando <em>kissattach</em> possiede
un opzione che permette di configurarlo; ma il metodo più
convenzionale che usa il comando <em/ifconfig/ funzionerà per tutti i
tipi d'interfaccia.
<p>
Quindi, modificando l'esempio fatto per il KISS:
<tscreen><verb>
# /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0
# /sbin/route add default ax0
</verb></tscreen>

si crea un'interfaccia AX.25 con un indirizzo IP <tt>44.136.8.5</tt>
e una MTU di <tt>512</tt> byte. Comunque occorre sempre usare
<em>ifconfig</em> per configurare, se necessario, gli altri
parametri. 
<p>
Se si hanno altri tipi di interfaccia occorre usare sempre
<em>ifconfig</em> per configurare l'indirizzo IP, i dettagli di
netmask per la porta e aggiungere un percorso (route) attraverso la
porta stessa, così come si fa per ogni altra interfaccia TCP/IP.
L'esempio che segue è riferito ad un device per una scheda PI, ma
funziona altrettanto bene per ogni altro device di rete AX.25:

<tscreen><verb>
# /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up
# /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
# /sbin/route add default pi0a
</verb></tscreen>

I comandi visti sopra sono tipici delle configurazioni a cui sono
abituati gli utenti di NOS o dei suoi derivati, o di ogni altro
software TCP/IP. Si noti che il percorso tipico (default route) può
non essere richiesto nella propria configurazione, se ci sono altri
device configurati.
<p>
Per testare il tutto, si provi un ping o un telnet verso un host
locale.

<tscreen><verb>
# ping -i 5 44.136.8.58
</verb></tscreen>

Si noti l'uso dell'argomento `<tt>-i 5</tt>' per <em>ping</em> per
mandare gli impulsi ogni 5 secondi, invece che ogni secondo come
scelta predefinita.

<sect>Configurazione di una porta NetRom.
<p>
Il protocollo NetRom usa e si appoggia alle porte AX.25 create in
precedenza; per configurarlo su un'interfaccia AX.25 occorre
modificare due file: uno descrive l'interfaccia NetRom, e l'altro
quali porte AX.25 verranno usate per trasportare questo protocollo.
Si possono configurare più porte NetRom, ognuna col proprio
nominativo e alias, usando la stessa procedura.

<sect1>Configurazione di <tt>/etc/ax25/nrports</tt>
<p>
Il primo file è <tt>/etc/ax25/nrports</tt>. Questo file descrive le
porte NetRom pressapoco come <tt>/etc/ax25/axports</tt> descrive le
porte AX.25. Ogni device NetRom che si vuole creare deve essere
descritto all'interno di <tt>/etc/ax25/nrports</tt>. Normalmente una
macchina Linux avrà configurato un unico device NetRom che usa un
certo numero delle porte AX.25 definite, ma in alcune situazioni,
come ad esempio nei BBS, si potrebbero volere diversi alias NetRom.
<p>
Questo file è formattato nel seguente modo:

<tscreen><verb>
name callsign  alias  paclen   description
</verb></tscreen>

Dove:
<descrip>
<tag>name</tag>è il nome con cui si fa riferimento alla porta.
<tag>callsign</tag>è il nominativo che verrà usato dal traffico
NetRom di questa porta. Nota: questa <bf/non/ è quell'indirizzo al
quale si connettono gli utenti per avere un accesso di tipo
<bf/node/. (Il programma node è descritto più avanti). Questo
nominativo/ssid dovrebbe essere unico e non dovrebbe apparire in
alcun altro punto dei file  <tt>/etc/ax25/axports</tt> o
<tt>/etc/ax25/nrports</tt>
<tag>alias</tag>è l'alias NetRom assegnato a questa porta.
<tag>paclen</tag>è la grandezza massima dei frame netRom trasmessi
dalla porta.
<tag>description</tag>è una descrizione libera della porta.
</descrip>

Un tipico esempio potrebbe essere il seguente:

<tscreen><verb>
netrom  VK2KTJ-9        LINUX   236     Linux Switch Port
</verb></tscreen>

In questo modo viene creata una porta NetRom, conosciuta dal resto
della rete NetRom come `<tt/LINUX:VK2KTJ-9/'.
<p>
Questo programma viene usato da programmi come <em/call/

<sect1>Configurazione di <tt>/etc/ax25/nrbroadcast</tt>
<p>
Questo file può contenere diverse voci; una per ogni porta AX.25
attraverso la quale si vuol far passare traffico NetRom ed è
formattato nel seguente modo:

<tscreen><verb>
axport min_obs def_qual worst_qual verbose
</verb></tscreen>

Dove:
<descrip>
<tag>axport</tag>è il nome dela porta ricavato dal file
<tt>/etc/ax25/axports</tt>. Se per una porta non è presente una voce
in <tt>/etc/ax25/nrbroadcasts</tt> significa che da questa non
transiterà traffico NetRom.
<tag>min&lowbar;obs</tag>è il valore minimo di obsolescenza per la
porta.
<tag>def&lowbar;qual</tag>è il valore di default della qualità per la
porta.
<tag>worst&lowbar;qual</tag>è il peggior valore di qualità consentito
per la porta; ogni route al di sotto di questo livello sarà ignorata.
<tag>verbose</tag>è un flag che indica se da questa porta avvengono
broadcast del routing NetRom completi, o solo di avvertimento per il
nodo stesso.
</descrip>

Un esempio può essere il seguente:

<tscreen><verb>
radio    1       200      100         1
</verb></tscreen>

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

<tscreen><verb>
# nrattach netrom
</verb></tscreen>

Questo comando inizializzerà il device NetRom (<tt>nr0</tt>) chiamato
<tt>netrom</tt> e configurato nel modo definito dai parametri del file
<tt>/etc/ax25/nrports</tt>.

<sect1>Lancio del demone NetRom
<p>
Il kernel di Linux gestisce tutto il protocollo NetRom, ad eccezione
di alcune funzioni. Il demone NetRom gestisce le tavole di
indirizzamento (routing tables) e genera la trasmissione del routing
NetRom. Il demone NetRom viene lanciato dal comando:

<tscreen><verb>
# /usr/sbin/netromd -i
</verb></tscreen>

A questo punto il file <tt>/proc/net/nr&lowbar;neigh</tt> dovrebbe
cominciare a riempirsi di informazioni relative ai nodi NetRom
adiacenti.
<p>
Si ricordi di mettere il comando <tt>/usr/sbin/netromd</tt> nei
propri file <em>rc</em>, in modo che il demone venga lanciato ogni
volta che si fa ripartire il sistema.

<sect1>Configurazione del routing NetRom.                                  
<p>
Volendo configurare degli instradamenti NetRom statici per degli host
specifici si può usare il comando <em/nrparms/; ancora una volta si
rimanda alle pagine <em/man/ relative, non prima di dare un esempio
che puo essere il seguente:
<tscreen><verb>
# /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9
</verb></tscreen>

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

<p>
Si possono creare manualmente voci per nuovi host vicini usando
sempre il comando <em/nrparms/. Ad esempio:

<tscreen><verb>
# /usr/sbin/nrparms -routes radio VK2SUT-9 + 120
</verb></tscreen>

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

<sect>Configurazione di un interfaccia NetRom per TCP/IP.
<p>
Il processo di configurazione di un interfaccia NetRom per TCP/IP è
quasi del tutto identica a quella di un interfaccia AX.25 per TCP/IP.
<p>
Anche in questo caso occorre specificare indirizzo ip e mtu nella
linea di comando di <em>nrattach</em>, o usare i comandi
<em>ifconfig</em> e <em>route</em>, ma occorre aggiungere manualmente
le voci <em>arp</em> per gli host verso i quali si vuole creare una
route, poiché non c'è nessun meccanismo che permetta alla propria
macchina di sapere quale indirizzo NetRom usare per raggiungere un
particolare host IP.
<p>
Per questo, per creare un device <tt>nr0</tt> con indirizzo IP
<tt>44.136.8.5</tt>, mtu di <tt>512</tt> e configurata nel modo
descritto nel file <tt>/etc/ax25/nrports</tt> per la porta NetRom
chiamata <tt>netrom</tt>, si userà il comando:

<tscreen><verb>
# /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
# route add 44.136.8.5 nr0
</verb></tscreen>

oppure una cosa simile alla seguente sequenza di comandi:

<tscreen><verb>
# /usr/sbin/nrattach netrom
# ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom VK2KTJ-9
# route add 44.136.8.5 nr0
</verb></tscreen>

Per ogni host IP che si voglia ragiungere via NetRom occorre dunque
indicare route e arp. Per raggiungere un host con indirizzo IP
<tt>44.136.80.4</tt> all'indirizzo NetRom <tt>BBS:VK3BBS</tt> tramite
un nodo NetRom con nominativo <tt>VK2SUT-0</tt> si useranno i
seguenti comandi:

<tscreen><verb>
# route add 44.136.80.4 nr0
# arp -t netrom -s 44.136.80.4 vk2sut-0
# nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0
</verb></tscreen>

Gli argomenti di <em>nrparms</em> `<tt>120</tt>' e `<tt>6</tt>' sono
rispettivamente i valori NetRom di <em>qualità</em> e
<em>obsolescence count</em> per la route.

<sect>Configurazione di una porta Rose.
<p>
Il protocollo packet Rose è simile al livello tre delle specifiche
X.25. Il suo supporto nel kernel di Linux è una versione
<bf/modificata/ dell'<url url="http://fpac.lmi.ecp.fr/f1oat/f1oat.html"
name="Implementazione Rose FPAC">.
<p>
Il Rose usa le porte AX.25 che sono presenti nel sistema e si
appoggia a questo protocollo.
Per configurare il Rose occorre creare un file di configurazione che
descrive le porte Rose che si vogliono creare; per ogni porta la
procedura è la stessa.

<sect1>Configurazione di <tt>/etc/ax25/rsports</tt>                        
<p>
Il file nel quale si configurano le interfacce Rose è
<tt>/etc/ax25/rsports</tt>. In esso vengono descritte le porte Rose
più o meno nello stesso modo in cui il file
<tt>/etc/ax25/axports</tt>descrive le porte AX.25.
<p>
Questo file è formattato nel seguente modo:

<tscreen><verb>
name  addresss  description
</verb></tscreen>

dove:
<descrip>
<tag>name</tag>è il nome con il quale ci si riferisce alla porta
<tag>address</tag>è l'indirizzo Rose a dieci cifre che si vuole
assegnare alla porta.
<tag>description</tag>è una descrizione libera della porta.
</descrip>

Un esempio potrebbe essere il seguente:

<tscreen><verb>
rose  5050294760  Porta Rose
</verb></tscreen>

Si noti che, a meno di specificare diversamente, il Rose usa il
nominativo/ssid di default configurato su ogni porta AX.25.
<p>
Per configurare un nominativo/ssid da far usare al Rose su ogni
porta, si usa il comando <em/rsparms/ come segue:

<tscreen><verb>
# /usr/sbin/rsprams -call VK2KTJ-10
</verb></tscreen>

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

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

<tscreen><verb>
# rsattach rose
</verb></tscreen>

Questo comando inizializza il device Rose (<tt/rose0/) configurato
nel modo descritto nel file <tt>/etc/ax25/rsports</tt> per la porta
chiamata `<tt/rose/'.

<sect1>Configurazione del routing Rose
<p>
Attualmente il protocollo Rose supporta solo l'instradamento statico.
L'utiliity <em/rsparms/ permette di configurare la tabella di routing
Rose per Linux.
<p>
Ad esempio:
<tscreen><verb>
# rsparms -nodes add 5050295502 radio vk2xlz
</verb></tscreen>
aggiunge una route al nodo Rose <tt/5050295502/ attraverso una porta
AX.25 chiamata `<tt/radio/' nel file <tt>/etc/ax25/axports</tt>, per
un host col nominativo <tt/VK2XLZ/.
<p>
Le route possono essere specificate con una mask per includere
diverse destinazioni in un unica voce. La sintassi è la seguente:
<tscreen><verb>
# rsparms -nodes add 5050295502/4 radio vk2xlz
</verb></tscreen>
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 <tt/5050/. Una forma alternativa per questo comando è:
<tscreen><verb>
# rsparms -nodes add 5050/4 radio vk2xlz
</verb></tscreen>
che è probabilmente il modo più chiaro.

<sect>Effettuazione di chiamate AX.25/NetRom/Rose.
<p>
Una volta configurate le interfacce AX.25, NetRom e Rose, si è in
grado di effettuare chiamate di prova.
<p>
Nelle AX25 Utilities è incluso un programma chiamato `<em/call/' che
è un programma di terminale per AX.25, NetRom e Rose.
<p>
Una semplice chiamata AX.25 sarà del tipo
<tscreen><verb>
/usr/bin/call radio VK2DAY via VK2SUT
</verb></tscreen>

Una semplice chiamata NetRom ad un nodo con alias <tt/SUNBBS/ sarà
fatta con;
<tscreen><verb>
/usr/bin/call netrom SUNBBS
</verb></tscreen>

Una seplice chiamata Rose verso <tt/HEARD/ al nodo <tt/5050882960/
sarà fatta nel seguente modo:
<tscreen><verb>
/usr/bin/call rose HEARD 5050882960
</verb></tscreen>

Nota: occorre specificare a <em>call</em> su quale porta si vuole
effettuare la chiamata, poiché lo stesso nodo di destinazione
potrebbe essere raggiungible su ogni porta configurata.
<p>

<em>call</em> è un programma di terminale a linea di comando per
effettuare chiamate AX.25. Riconosce linee che iniziano con
`<tt>~</tt>' come comandi.
Il comando `<tt>~.</tt>' terminerà la connessione.
<p>
Si faccia riferimento alle pagine man relative in <tt>/usr/man</tt>
per maggiori informazioni.

<sect>Configurare Linux per accettare connessioni Packet.
<p>
Linux è un sistema operativo molto potente è offre un elevato grado
di flessibilità nella sua configurazione. Questa flessibilità porta
come effetto collaterale una relativa complicatezza nell'operazione
di configurazione. Quando si configura una macchina Linux per
accettare connessioni AX.25, NetRom o Rose occorre farsi diverse
domande. La più importante è "cosa voglio che gli utenti vedano
quando mi connetto?". Molti hanno sviluppato belle applicazioncine che
possono offrire servizi agli utenti che si connettono; alcune sono
semplici come il programma <em/pms/, altre più complesse come
<em/node/ (entrambi presenti nelle AX25 utilities). Alternativamente
si potrebbe dare agli utenti un account e un nome di login, oppure
potreste aver scritto un vostro programma, come un database
customizzato, o un gioco al quale volete che gli utenti si
connettano. Qualunque soluzione scegliate, dovete informare il
software AX.25 su quale programma lanciare quando accetta connessioni
AX.25.
<p>
Il demone <em/ax25d/ è simile a <em/inetd/ che viene comunemente
usato per accettare connessioni TCP/IP su macchine unix. Il compito
di <em/ax25d/ è quello di raccogliere e gestire i tentativi di
connesisone AX.25. Quando ne sente uno controlla un file di
configurazione per stabilire quale programma lanciare e connetterlo
al chiamante. Poiché <em/ax25d/ è lo strumento standard per accettare
connessioni AX.25, NetRom e Rose, verrà descritto come configurarlo.

<sect1>Creazione del file <tt>/etc/ax25/ax25d.conf</tt>.
<p>
Questo è il file di configurazione per <em>ax25d</em>
<p>
Ad una prima occhiata può apparire un po' criptico, ma presto si nota
come in pratica sia molto semplice, evitando una piccola trappola.
<p>
Il formato generale del file <tt>ax25d.conf</tt> è il seguente:

<tscreen><verb>
# 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>
<argomenti>
<peer2>    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name>
<argomenti>
parameters window T1 T2 T3 idle N2 <mode>
<peer3>    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name>
<argomenti>
   ...
default    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name>
<argomenti>
</verb></tscreen>

Dove:
<descrip>
<tag>#</tag>all'inizio di una riga indica che questa è un commento e
dev'essere ignorata da <em>ax25d</em>.
<tag>&lt;nome&lowbar;porta&gt;</tag>è il nome della porta AX.25,
NetRom o Rose come specificato nei file <tt>/etc/ax25/axports</tt>,
<tt>/etc/ax25/nrports</tt> o <tt>/etc/ax25/rsports</tt>. Il
nome della porta è circondato da parentesi quadre `<tt/[]/' se è una
porta AX.25, acute `<tt/&lt;&gt;/' se NetRom, o graffe `<tt/{}/' se
Rose.
Esiste una forma alternativa per questo campo, che consiste nel far
precedere il nome della porta da `<tt>nominativo/ssid via</tt>' per
indicare che si vogliono accettare chiamate al nominativo/ssid
attraverso quest'interfaccia. L'esempio dovrebbe rendere più chiaro il
tutto.
<tag>&lt;peer&gt;</tag>è il nominativo del nodo a cui si applica
questa particolare configurazione. Se non si specifica un ssid,
questa configurazione sarà applicata a tutti i ssid del nominativo.
<tag>window</tag>è il parametro AX.25 "Window" (K) conosciuto anche
come MAXFRAME che si applica in questa configurazione.
<tag>T1</tag>è il valore di tempo di ritrasmissione del frame (T1)
espresso in mezzi secondi.
<tag>T2</tag>è il tempo, espresso in secondi, che il software AX.25
attende per un altro frame in ingresso, prima di mandare una
risposta.
<tag>T3</tag>è il tempo di inattività espressa in secondi, prima che
il software AX.25 interrompa la sessione.
<tag>idle</tag>è il valore di idle espresso in secondi.
<tag>N2</tag>è il numero di ritrasmissioni consecutive che possono
essre fatte prima di interrompere la connessione.
<tag>&lt;mode&gt;</tag>fornisce un meccanismo per stabilire alcuni
tipi di permessi. I modi sono abilitati o disabilitati fornendo una
combinazione di caratteri, ognuna rappresentante un permesso. I
caratteri possono essere scritti sia in maiuscolo che in minuscolo,
in un unico blocco, senza spazi.
<descrip>
<tag>u/U</tag>UTMP                   - Attualmente non supportato.
<tag>v/V</tag>Validate call          - Attualmente non supportato.
<tag>q/Q</tag>Quiet                  - Non viene fatto il log della
connessione
<tag>n/N</tag>check NetRom Neighbour - Attualmente non supportato.
<tag>d/D</tag>Disallow Digipeaters   - La connessione dev'essere
diretta, non effettuata tramite digipeater.
<tag>l/L</tag>Lockout                - Non permette la connessione.
<tag>*/0</tag>marker                 - Mette un marker, non vengono
settati i modi.
</descrip>
<tag>&lt;uid&gt;</tag>è l'identificativo col quale deve deve essere
lanciato il programma che supporta la connessione.
<tag>&lt;cmd&gt;</tag>è il path completo del comando da lanciare,
senza specificare argomenti.
<tag>&lt;cmd-name&gt;</tag>è il testo che deve apparire in un
<em>ps</em> come nome del comando lanciato (normalmente è lo stesso
valore di &lt;cmd&gt;, però senza path.
<tag>&lt;arguments&gt;</tag>sono gli argomenti da passare a
&lt;cmd&gt; quando viene lanciato. Possono essere passate utili
informazioni con i seguenti token:
<descrip>
<tag>&percnt;d</tag>Nome della porta sulla quale si è ricevuta la
connessione.
<tag>&percnt;U</tag>Nominativo AX.25 del chiamante senza ssid e
scritto in maiuscolo.
<tag>&percnt;u</tag>Nominativo AX.25 del chiamante senza ssid e
scritto in minuscolo.
<tag>&percnt;S</tag>Nominativo AX.25 del chiamante con ssid e scritto
in maiuscolo.
<tag>&percnt;s</tag>Nominativo AX.25 del chiamante con ssid e scritto
in minuscolo.
<tag>&percnt;P</tag>Nominativo AX.25 del nodo dal quale è venuta la
chiamata, senza ssid e in maiuscolo.
<tag>&percnt;p</tag>Nominativo AX.25 del nodo dal quale è venuta la
chiamata, senza ssid e in minuscolo.
<tag>&percnt;R</tag>Nominativo AX.25 del nodo dal quale è venuta la
chiamata, con ssid e in maiuscolo.
<tag>&percnt;r</tag>Nominativo AX.25 del nodo dal quale è venuta la
chiamata, con ssid e in minuscolo.
</descrip>
</descrip>

Occorre una sezione nel formato visto sopra per ogni interfaccia
AX.25, NetRom o Rose dalla quale si vogliano accettare connessioni.
<p>
Nel paragrafo ci sono due tipi speciali di linee, uno inizia con la
stringa `<tt>parameters</tt>' è l'altro con la stringa
`<tt>default</tt>' (c'è differenza). Queste servono per funzioni
speciali.
<p>
Lo scopo delle linee `<tt>default</tt>' dovrebbe essere ovvio; queste
regolano il comportamento di quelle connessioni  per le quali non
sono specificate regole. In assenza di una regola di
`<tt>default</tt>', ogni connessione che non è riconducibile ad una
regola definita, sarà rifiutata e il chiamante disconnesso senza
alcun messaggio.
<p>
La linea `<tt>parameters</tt>' 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 `<tt>parameters</tt>'
è quella che definisce questi valori. Lo stesso 
software del kernel ha alcuni valori di default che posono essere
usati se non li si specifica con la linea `<tt>parameters</tt>'
La trappola è che questi valori di default si applicano <bf>solo</bf>
alle regole <bf>sotto</bf> la linea `<tt>parameters</tt>'. Si possono
avere diverse linee `<tt>parameters</tt>' in modo da creare gruppi di
configurazioni di default. E' importante notare che
`<tt>parameters</tt>' non permette di settare i valori dei campi
`<tt/uid/' o `<tt/command/'.

<sect1>Un semplice esempio di file <tt>ax25d.conf</tt>.
<p>
Ok, a questo punto si impone un esempio chiarificatore:

<tscreen><verb>
# ax25d.conf di VK2KTJ - 03/02/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

<netrom>
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
</verb></tscreen>

Questo esempio dice che chiunque voglia connettersi col nominativo
`<tt/VK2KTJ-0/' ascoltato sulla porta AX.25 chiamata `<tt/radio/'
sottostarà alle seguenti regole:
<p>
Chiunque abbia il nominativo col valore `NOCALL' non viene fatto
entrare; si noti l'uso del modo `L'.
<p>
La linea <tt/parameters/ modifica due parametri rispetto a quelli di
default del kernel (Window e T1) e verrà lanciato il programma
<em>/usr/sbin/axspawn</em> per loro. Ogni copia di
<em>/usr/sbin/axspawn</em> lanciata in questo modo apparirà come
<em/axspawn/ in una lista <em/ps/. Le due linee successive danno le
regole per due stazioni che riceveranno questi permessi.
<p>
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 <em/pms/ sia lanciato con un argomento che indica
che funziona su una connessione AX.25, e che il nominativo
utilizzato per rispondere è <tt/VK2KTJ/. (Si veda il paragrafo
`Configurazione del PMS' per maggiori dettagli).
<p>
La configurazione successiva accetta connessioni a <tt/VK2KTJ-1/
tramite la porta <tt/radio/ e lancia il programma <em/node/ per
chiunque.
<p>
Poi c'è una configurazione NetRom (si noti l'uso delle parentesi
acute "< >"). Questa è più semplice: stabilisce che chiunque si
connetta alla porta dal nome `<tt/netrom/' farà partire il programma
<em/node/, a meno che non abbia nominativo `<tt/NOCALL/', nel qual
caso viene disconnesso.
<p>
Le ultime due configurazioni sono per le connessioni Rose; la prima
per chi chiama `<tt/vk2ktj-0/', l'altra per chi chiama
`<tt/VK2KTJ-1/' all'indirizzo di nodo Rose della macchina. Queste
funzionano esattamente allo stesso modo; si noti l'uso delle parentei
graffe per caratterizzarle come porte Rose.
<p>
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 <em/man/ di <tt/ax25d.conf/. Un esempio
più dettagliato è incluso, invece, nelle <tt>ax25-utils</tt>.

<sect1>Lanciare <em>ax25d</em>
<p>
Una volta approntati i due file di configurazione, si può lanciare
<em>ax25d</em> col comando;

<tscreen><verb>
# /usr/sbin/ax25d
</verb></tscreen>

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 <tt>ax25d</tt> nei propri file
<em>rc</em>, in modo che venga lanciato ogni volta che la macchina
viene fatta ripartire.

<sect>Configurazione del programma <em>node.</em>
<p>
<em>node</em> è stato sviluppato da Tomi Manninen
<tt>&lt;tomi.manninen@hut.fi></tt> e si basa sul programma PMS.
Rende disponibili le funzionalità di nodo in modo piuttosto completo e
flessibile, permettendo agli utenti, una volta connessi, di fare
connessioni in uscita di tipo Telnet, AX.25, NetRom e Rose, nonchè di
ottenere informazioni con Finger, Nodes, Heard eccetera. Si può inoltre
configurare il nodo in modo da far eseguire qualunque comando Linux
in modo piuttosto semplice.
<p>
Node viene normalmente lanciato dal programma <em>ax25d</em>, per
quanto possa essere eseguito anche da linea di comando oppure lanciato
dal programma TCP/IP <em>inetd</em> per permettere agli utenti di fare
telnet sulla vostra macchina.

<sect1>Creazione del file <tt>/etc/ax25/node.conf</tt>.
<p>
Il file <tt>node.conf</tt> è dove viene scritta la configurazione
principale del nodo. E' un semplice file di testo ed è formattato nel
seguente modo:

<tscreen><verb>
# /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 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 netrom

# Identificazione del nodo.
# Questo apparirà al prompt del nodo.
NodeId		LINUX:VK2KTJ-9

# Porta NetRom
# Questo è il nome della porta NetRom che verrà usata per
# le connessioni NetRom in uscita dal nodo.
NrPort		netrom

# 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
</verb></tscreen>

<sect1>Creazione del file <tt>/etc/ax25/node.perms</tt>
<p>
<em>node</em> 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 <tt>node.perms</tt> 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.
<p>
<descrip>
<tag>utente</tag>
Il primo campo rappresenta il nominativo o l'utente al quale devono
applicarsi i permessi. Ogni ssid viene ignorato, quindi basta mettere
il nominativo semplice.
<tag>metodo</tag>
Vengono concessi permessi anche ai protocolli o ai metodi di accesso.
Per esempio si può permettere l'uso dell'opzione (C)onnect agli
utenti connessi via AX.25 o NetRom, ma impedirlo agli altri. Il
secondo campo perciò, permette di selezionare a quale metodo di
accesso deve applicarsi la regola di accesso.
I metodi di accesso sono i seguenti:
<tscreen><verb>
metodo	descriztione
------	-----------------------------------------------------------
ampr	L'utente è connesso via telnet da un indirizzo amprnet (44.0.0.0)
ax25	L'utente è connesso tramite AX.25
host	L'utente ha lanciato node dalla linea di comando
inet	L'utente è connesso via telnet da un indirizzo non-locale e non-amprnet
local	L'utente è connesso via telnet da un host 'locale'
netrom	L'utente è connesso tramite NetRom
rose	L'utente è connesso tramite rose
*		L'utente è connesso in un modo qualunque.
</verb></tscreen>
<tag>porta</tag>
Volendo è possibile controllare i permessi per gli utenti AX.25 porta
per porta; questo permette di determinare cosa gli utenti sono in
grado di fare a seconda della porta alla quale sono connessi. Se si
sfrutta questa funzionalità (che funziona solo per le connessioni
AX.25), il terzo campo contiene il nome della porta.
<tag>password</tag>
Si può opzionalmente configurare il nodo in modo che chieda una
password alla connessione. Questo può essere utile per proteggere
utenti con un livello di accesso particolarmente elevato; in questo
campo, se presente, è contenuto il valore della password che
dev'essere fornita.
<tag>permessi</tag>
Il campo permessi è l'ultimo per ciascuna voce nel file. Il valore
che contiene è a campi di bit (ogni opzione è rappresentata da un bit
più o meno settato a seconda che venga più o meno concesso il
permesso per essa). La lista delle opzioni che possono essere
controllate, e del relativo valore in bit è il seguente:

<tscreen><verb>
valore	descrizione
-----	-------------------------------------------------
 1	Login consentito.
 2	(C)onnessione AX25 consentita.
 4	(C)onnessione NetRom consentita.
 8	(T)elnet verso host locali consentiti.
 16	(T)elnet verso host amprnet (44.0.0.0) consentiti.
 32	(T)elnet verso host non-locali e non-amprnet consentiti.
 64	(C)onnessione AX25 consentita anche su porte occultate.
 128	(C)onnessione Rose consentita.
</verb></tscreen>
Per stabilire una regola particolare, occorre sommare i valori dei
singoli permessi che si vuole dare e mettere il numero risultante nel
quinto campo.
</descrip>
<p>
Un file <tt>nodes.perms</tt> potrebbe essere il seguente:

<tscreen><verb>
# /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, NetRom, Local, Host e AMPR possono fare (C)onnect
# e (T)elnet a host locali e ampr, ma non ad altri indirizzi IP.
*	ax25	*	*	159
*	netrom	*	*	159
*	local	*	*	159
*	host	*	*	159
*	ampr	*	*	159
</verb></tscreen>

<sect1>Configurazione di <em>node</em> per funzionare da <em>ax25d</em>
<p>
Il programma <em>node</em> viene lanciato di solito dal programma
<em>ax25d</em>. Per fare questo occorre aggiungere delle particolari
regole al file <tt>/etc/ax25/ax25d.conf</tt>. Nella configurazione
che adotto, voglio permettere agli utenti di scegliere se connettersi
a <em>node</em> o ad altri servizi. <em>ax25d</em> consente di fare
questo attraverso l'intelligente creazione di alias delle porte. Ad
esempio, data la configurazione di <em>ax25d</em> presentata sopra,
si vuole configurare <em>node</em> in modo che venga lanciato per
tutti gli utenti che si connettono a <tt>VK2KTJ-1</tt>. Per fare
questo si aggiunge questo al file <tt>/etc/ax25/ax25d.conf</tt>:
<tscreen><verb>
[vk2ktj-1 via radio]
default    *     *    *   *   *   0    root /usr/sbin/node node
</verb></tscreen>
Questo dice che il kernel di Linux risponderà ad ogni richiesta di
connessione al nominativo `<tt/VK2KTJ-1/' sulla porta chiamata
`<tt/radio/' lanciando il programma <em>node</em>

<sect1>Configurazione di <em>node</em> per funzionare da <em>inetd</em>
<p>
Se si vuole che i propri utenti siano in grado di fare telnet su una
porta della macchina e avere accesso a <em>node</em>, lo si può fare
piuttosto facilmente. La prima cosa da decidere e a quale porta gli
utenti si devono connettere.
<p>
Occorre modificare due file.<p>
In <tt>/etc/services</tt> occorre aggiungere:
<tscreen><verb>
node	3694/tcp	#OH2BNS's node software
</verb></tscreen>
a in <tt>/etc/inetd.conf</tt> va aggiunto:
<tscreen><verb>
node	stream	tcp	nowait	root	/usr/sbin/node node
</verb></tscreen>
Una volta fatto questo, facendo ripartire il programma
<em>inetd</em>, ogni utente connesso via telnet alla porta 3694 della
macchina riceverà la richiesta di login, l'eventuale richiesta di
password e sarà connesso a <em>node</em>.

<sect>Configurazione di <em>axspawn</em>
<p>
Il programma <em/axspawn/ permette alle stazioni connesse via AX.25
di loggarsi sulla macchina Linux. Può essere lanciato da <em/ax25d/
in modo simile a quanto visto per <em/node/. Per permettere ad un
utente l'accesso alla propria macchina occorre aggiungere una linea
simile alla seguente nel proprio file <tt>/etc/ax25/ax25d.conf</tt>:
<tscreen><verb>
default * * * * * 1 root /usr/sbin/axspawn axspawn %u
</verb></tscreen>
Se la line finisce con un carattere <tt/+/, l'utente che si connette
deve battere invio prima che gli venga concesso il login. Di default
la scelta è di non attendere input dall'utente.

Ogni singola configurazione host che segue queste righe lancia
<em/axspawn/ alla connessione del corrispondente. Alla partenza,
<em/axspawn/ controlla che la linea di comando che gli viene passata
corrisponda ad un nominativo valido, toglie lo ssid e infine
controlla il file <tt>/etc/passwd</tt> per vedere se quell'utente ha
un account configurato sulla macchina. Se esiste e la password è
<tt/""/ (null) o <tt/+/, l'utente è subito fatto entrare; se esiste
una password da fornire, viene invitato a digitarla. Se non esiste
un'account corrispondente all'utente in <tt>/etc/passwd</tt>, si può
configurare <em/axspawn/ affinchè ne crei automaticamente uno.

<sect1>Creazione del file <tt>/etc/ax25/axspawn.conf</tt>
<p>
E' possibile modificare il comportamento di <em/axspawn/ agendo sul
file di configurazione <tt>/etc/ax25/axspawn.conf</tt> che è
formattato nel seguente modo:
<tscreen><verb>
# /etc/ax25/axspawn.conf
#
# permette la creazione automatica di account utente
create    yes
#
# uso di utente guest (ospite) se sopra si è scelto "no" o se tutto
# fallisce. Disabilita con "no"
guest     no
#
# nome o group id degli utenti creati automaticamente
group     ax25
#
# primo user id da usare
first_uid 2001
#
# user id massimo
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
</verb></tscreen>

Gli otto parametri di configurazione di <em/axspawn/ hanno il
seguente significato:

<descrip>
<tag>#</tag>indica una linea di commento
<tag>create</tag>se questo campo è settato a <tt>yes</tt>,
<em>axspawn</em> tenterà di creare automaticamente un account per
ogni utente che si connetta e non sia già presente nel file
<tt>/etc/passwd</tt>
<tag>guest</tag>questo campo indica il nome dell'account che sarà
usato per gli utenti che non hanno un account se <em>create</em> è
settato a <tt>no</tt> e che di solito è <tt>ax25</tt> o
<tt>guest</tt>.
<tag>group</tag>questo campo indica il nome del gruppo per gli
account deli utenti che sono creati automaticamente se non sono
presenti nel file <tt>/etc/passwd</tt>
<tag>first&lowbar;uid</tag>è il numero del primo userid che sarà
utilizzato per la creazione automatica degli utenti.
<tag>max&lowbar;uid</tag>è il valore massimo dell'userid che verrà
usato nella creazione di nuovi utenti.
<tag>home</tag>è la home directory dei nuovi utenti.
<tag>shell</tag>è la login shell usata dai nuovi utenti.
<tag>associate</tag>indica se le connessioni AX.25 in uscita fatte
dagli utenti collegati devono essere fatte usando il loro nominativo
o quello della macchina.
</descrip>

<sect>Configurazione di <em>pms</em>
<p>
Il programma <em>pms</em> è l'implementazione di un semplice
programma di messaggistica. Sviluppato in origine da Alan Cox, è
stato successivamente ampliato da Dave Brown
<tt>&lt;dcb@vectorbd.com></tt>. Allo stadio attuale è ancora molto
semplice, visto che supporta solo l'invio di messaggi solo al gestore
del sistema e di ricavare alcune informazioni sul sistema, ma Dave è
al lavoro per espandere le sue funzionalità e renderlo più utile.
<p>
Una volta che il programma è stato compilato ed installato occorre
creare un paio di semplici file per far sì che gli utenti abbiano
alcune informazioni sul sistema e modificare le voci opportune nel
file <tt/ax25d.conf/, in modo che,alla connessione, agli utenti si
presenti il PMS.
<p>

<sect1>Creazione del file <tt>/etc/ax25/pms.motd</tt>.
<p>
Il file <tt>/etc/ax25/pms.motd</tt> contiene il `messaggio del
giorno' che verrà inviato a chi si connette dopo lo header usuale del
BBS.

<sect1>Creazione del file <tt>/etc/ax25/pms.info</tt>.
<p>
Anche <tt>/etc/ax25/pms.info</tt> è 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 <tt>Info</tt> dal prompt <tt>PMS></tt>.

<sect1>Associazione di nominativi AX.25 con gli utenti di sistema.
<p>
Quando un utente connesso manda posta ad un nominativo AX.25,
<em>pms</em> si aspetta che questo sia mappato o associato con un
reale utente creato sulla vostra macchina. Questo è descritto in una
sezione a parte.

<sect1>Aggiunta di PMS in <tt>/etc/ax25/ax25d.conf</tt>
<p>
L'aggiunta di <em>pms</em> al proprio file <tt>ax25d.conf</tt> è
un'operazione molto semplice, tuttavia c'è una piccola cosa da tenere
in considerazione. Dave ha aggiunto la possibilità di fornire al
programma pms attraverso la linea di comando la possibilità di
gestire in diversi modi la fine di una linea di testo. AX.25 e
NetRom, per convenzione, si aspettano che la fine della linea di
testo sia indicata dal comando di ritorno a capo e dall'avanzamento
di linea (<em>carriage return, linefeed</em>), mentre nei sistemi
Unix standard si usa solo il comando di nuova linea
(<em>newline</em>). 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:

<tscreen><verb>
default  1  10 5 100 5   0    root  /usr/sbin/pms pms -a -o vk2ktj
</verb></tscreen>

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

<sect1>Test del PMS.
<p>
Per testare il PMS, si può dare il seguente comando dal prompt della
shell:
<verb>
# /usr/sbin/pms -u vk2ktj -o vk2ktj
</verb>
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 è
<tt>vk2ktj</tt>. In questo modo ci si trova nella stessa situazione
di un utente remoto che si connette.
<p>
In aggiunta a questo si può provare a far connettere altri nodi alla
propria macchina in modo da controllare che le impostazioni in
<tt>ax25d.conf</tt> siano correttie.

<sect>Configurazione dei programmi <em>user&lowbar;call</em>.
<p>
I programmi `<em/user&lowbar;call/' sono in realtà:
<em/ax25&lowbar;call/,`<em/rose&lowbar;call/' e
<em/netrom&lowbar;call/. Sono molto semplici e sono concepiti per
essere chiamati da <em/ax25d/ per automatizzare le connessioni a host
remoti, anche se nulla vieta di usarli in script della shell o con
altri demoni come il programma <em/node/.
<p>
A causa della loro semplicità, non trattano in alcun modo i dati che
gestiscono, quindi ad esempio il problema della fine-linea deve
essere gestito dall'utente.
<p>
Iniziamo con un esempio su come si possano impiegare. Immaginiamo di
avere una piccola rete a casa composta da una macchina Linux che
funziona come gateway radio  e da un'altra macchina, diciamo un nodo
BPQ connesso via ethernet.
<p>
Normalmente, se si vuole che gli utenti che si connettono via radio
possano raggiungere il nodo BPQ, occorre che la prima macchina funga
da digipeater, oppure che gli utenti possano connettersi al nodo
Linux e poi connettersi all'altra macchina da lì.
Il programma <em/ax25&lowbar;call/ può semplificare quest'operazione
se viene chiamato dal programma <em/ax25d/.
<p>
Supponiamo che il nodo BPQ abbia il nominativo <tt/VK2KTJ-9/ e che la
macchina Linux abbia la porta AX.25/ethernet chiamata `<tt/bpq/';
immaginiamo anche che questa abbia una porta radio chiamata
`<tt/radio/'.
<p>
Una voce nel file <tt>/etc/ax25/ax25d.conf</tt> del tipo:
<tscreen><verb>
[VK2KTJ-1 via radio]
default    * * * *   *   *  *
		root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9
</verb></tscreen>
abilita gli utenti alla connessione diretta a `<tt/VK2KTJ-1/' che
sarebbe in realtà il demone <em/ax25d/, che li connette
automaticamente a  `<tt/VK2KTJ-9/' attraverso l'interfaccia
`<tt/bpq/' con una connessione AX.25
<p>
C'è tutta una serie di altre possibili configurazioni che si possono
provare. Le utility `<em/netrom&lowbar;call/' e
`<em/rose&lowbar;call/' funzionano in modo simile. Un amatore ha usato
questa utility per rendere più semplici le connessioni ad una BBS
remota. Poiché Normalmente gli utenti dovrebbero inserire una lunga
stringa di connessione per fare la chiamata, ha creato una voce che fa
apparire la BBS come se attraverso di essa di fosse in una rete locale
dove <em/ax25d/ fa da proxy per la connessione alla macchina remota.

<sect>Configurazione dei comandi di uplink e downlink di Rose
<p>
Se l'implementazione ROM di Rose è familiare, non sarà difficile
orientarsi tra i metodi coi quali gli utenti AX.25 effettuano
chiamate su una rete Rose. Se un nodo Rose ha il nominativo
<tt/VK2KTJ-5/ e l'utente AX.25 vuole connettersi a <tt/VK5XXX/ al
nodo Rose <tt/5050882960/, deve dare il comando:

<tscreen><verb>
c vk5xxx v vk2ktj-5 5050 882960
</verb></tscreen>

Sul nodo remoto, <tt/VK5XXX/ vedrà una connessione in entrata dal
nominativo locale dell'utente AX.25 propagata dal nominativo del nodo
Rose remoto.
<p>
L'implementazione Rose di Linux non supporta questa funzionalità nel
kernel, tuttavia vi sono due programmi che svolgono questa funzione,
che sono <em/rsuplnk/ e <em/rsdwnlnk/.

<sect1>Configurazione del downlink Rose
<p>
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.
<tt>/etc/ax25/ax25d.conf</tt>. 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
<tt/NODE-0/ o <tt/HEARD-0/, e di passare le altre chiamate al comando
<em/rsdwnlink/, assumendo che siano utenti AX.25.
Una tipica configurazione può dunque essre:

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

con questa configurazione, ogni connessione al nodo Linux con un
nominativo di destinazione che non sia specificato esplicitamente,
sarà convertita in una connessione AX.25 dalla porta chiamata
<tt/4800/ usando come digipeater <tt/VK2KTJ-5/.

<p>
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
<tt>/etc/ax25/ax25d.conf</tt> che assume un aspetto simile a questo:

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

Si noti la speciale sintassi per il nominativo locale. il carattere
`<tt/*/' indica che l'applicazione dovrebbe essere invocata se il
nominativo è presente nel percorso digipeater di una connessione.
<p>
Questa configurazione permette ad un utente AX.25 di effettuare
connessioni Rose usando l'esempio presentato nell'introduzione. Ogni
connessione che tenti di usare <tt/VK2KTJ-5/ come digipeater sulla
porta AX.25 chiamata <tt/4800/ sarà gestita dal comando <em/rsuplnk/

<sect>Associare nominativi AX.25 con utenti Linux.
<p>
Ci sono diverse situazioni in cui è desiderabile associare un
nominativo con un account utente di Linux, ad esempio quando diversi
radioamatori condividono la stessa machina Linux e vogliono usare il
proprio nominativo per effettuare chiamate, oppure quando utenti del
PMS vogliono fare un talk con un particolare utente della macchina.
<p>
Il software AX.25 permette di gestire l'associazione tra utenti e
nominativi (se n'è già parlato nella sezione dedicata al PMS). Questa
associazione viene fatta tramite il comando <em>axparms</em>. Ad
esempio:
<tscreen><verb>
# axparms -assoc vk2ktj terry
</verb></tscreen>
associa il nominativo AX.25 <tt>vk2ktj</tt> con l'utente
<tt>terry</tt> della macchina Linux. In questo modo la posta di
<tt>vk2ktj</tt> del PMS sarà inviata all'account Linux
<tt>terry</tt>.
<p>
Si rammenti di mettere queste associazioni nel proprio file
<em>rc</em>, in modo che siano disponibili ad ogni reboot.
<p>
<bf/Nota/ non bisogna associare un nominativo con l'accont di
<tt/root/, in quanto ciò potrebbe interferire con la configurazione
di altri programmi.

<sect>I file in <tt>/proc</tt>.
<p>
La directory <tt>/proc</tt> presenta diversi file che sono in
relazione con il kernel AX.25 e NetRom. Questi sono di solito
utilizzati dalle utility AX25, ma essendo scritti in forma leggibile,
può essere interessante dar loro un'occhiata. Il formato che viene
usato è facilmente comprensibile, quindi non è neccessario andare
molto in dettaglio per la loro descrizione.

<descrip>
<tag>/proc/net/arp</tag>contiene le lista delle mappatture ARP (Address
Resolution Protocol)di indirizzi IP in indirizzi di protocollo a
livello MAC. Questi possono essere AX.25, ethernet o qualche altro
protocollo a livello MAC.
<tag>/proc/net/ax25</tag> contiene una lista dei socket AX.25 aperti.
Questi possono essere in attesa di una connessione oppure sessioni
attive.
<tag>/proc/net/ax25&lowbar;bpqether</tag>contiene le mappature dei
nominativi di tipo AX.25 su ethernet BPQ.
<tag>/proc/net/ax25&lowbar;calls</tag>contiene le mappature degli
userid Linux nei confronti dei nominativi configurate dal comando
<em/axparms -assoc/.
<tag>/proc/net/ax25&lowbar;route</tag> contiene informazioni per i
percorsi AX.25 da effettuare tramite digipeater.
<tag>/proc/net/nr</tag>contiene una lista di socket NetRom aperti.
Questi possono essere in attesa di una connessione, oppure
collegamenti attivi.
<tag>/proc/net/nr&lowbar;neigh</tag>contiene informazioni riguardo i
nodi NetRom vicini (NetRom neighbours) conosciuti dal programma.
<tag>/proc/net/nr&lowbar;nodes</tag>contiene informazioni riguardo i
nodi NetRom conosciuti dal programma.
<tag>/proc/net/rose</tag>contiene una lista di socket Rose aperti.
Questi possono essere in attesa di una connessione, oppure
collegamenti attivi.
<tag>/proc/net/rose&lowbar;nodes</tag>contiene informazioni riguardo
percorsi ai nodi Rose vicini (Rose Neighbours).
<tag>/proc/net/rose&lowbar;neigh</tag>contiene una lista di nodi Rose
vicini (Rose Neighbours).
<tag>/proc/net/rose&lowbar;routes</tag>contiene una lista di tutte le
connessioni Rose stabilite.
</descrip>

<sect>Programmazione di rete per AX.25, NetRom e Rose.
<p>
Il vantaggio più grande nell'usare un'implementazione dei protocolli
packet per radioamatori è probabilmente la facilità con cui si
possono sviluppare applicazioni e programmi che li sfruttino.
<p>
Sebbene la programmazione di applicativi di rete in Unix vada al di
là degli scopi di questo documento, si descriveranno gli elementi
essenziali per utilizzare i protocolli AX.25, NetRom e Rose
all'interno dei vostri programmi.
<p>
<sect1>Le famiglie degli indirizzi.
<p>
La programmazione di rete per AX.25, NetRom e Rose è, in Linux,
piuttosto simile a quella per TCP/IP, visto che la differenza
maggiore sta nelle diverse famiglie di indirizzi.
<p>
I nomi delle famiglie degli indirizzi per AX.25, NetRom e Rose sono
rispettivamente <tt/AF&lowbar;AX25/,
<tt/AF&lowbar;NETROM/ e <tt/AF&lowbar;ROSE/.

<sect1>I file header.
<p>
Occorre sempre includere i file header `<tt/ax25.h/', nonchè
`<tt/netrom.h/' o `<tt/rose.h/' se avete a che fare con questi
protocolli. Le impostazioni iniziali saranno simili alle seguenti:
<p>
Per AX.25:
<tscreen><verb>
#include <ax25.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_AX25
</verb></tscreen>

Per NetRom:
<tscreen><verb>
#include <ax25.h>
#include <netrom.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_NETROM;
</verb></tscreen>

Per Rose:
<tscreen><verb>
#include <ax25.h>
#include <rose.h>
int s, addrlen = sizeof(struct sockaddr_rose);
struct sockaddr_rose sockaddr;
sockaddr.srose_family = AF_ROSE;
</verb></tscreen>

<sect1>Trattamento dei nominativi ed esempi.
<p>
Nella libreria <tt>lib/ax25.a</tt> delle AX.25-utilities vi sono
routine che effettuano la conversione e il trattamento dei
nominativi, anche se naturalmente potete scriverne di vostre.
<p>
Le utility <em/user&lowbar;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.
<p>
Gli esempi sono semplici a sufficienza da non creare confusione. In
caso di dubbi è buona cosa rivolgerli alla mailing list
<tt/linux-hams/, dove senz'altro ci sarà qualcuno che vi darà una
mano.

<sect>Alcune semplici configurazioni.
<p>
Vengono ora presentati esempi delle configurazioni più tipiche.
Devono essere prese come spunto, visto che ci sono tanti modi di
configurare reti, quanto il numero di reti stesso, ma possono
comunque essere d'ispirazione.

<sect1>Piccola LAN Ethernet con macchina Linux che fa da router verso una LAN radio.
<p>
Molti hanno delle piccole reti locali a casa e vogliono connettere le
macchine di quella rete alla rete radio. Questa è 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
numeratore IP per la vostra zona vi assisterà in questo 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:

<tscreen><verb>
                                          .      .   .    .    . .
  ---                                .
   | 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
   |               |         |    .
   |               |         |     .
   |               \_________/       .
  ---                                     .      .   .    .    . .
</verb></tscreen>
<tscreen><verb>
#!/bin/sh
# /etc/rc.net
# Questa configurazione rende disponibile una porta KISS AX.25
# e un device 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 "    Netrom: "
nrattach -i 44.136.8.5 netrom

echo "  Routing:"
/sbin/route add default gw 44.136.8.68 window 1024 sl0
echo "    default route."
echo done.

# end
</verb></tscreen>

<tt>/etc/ax25/axports</tt>
<tscreen><verb>
# nome  nominativo     velocità paclen  window  descrizione
4800    VK2KTJ-0        4800    256     2       144.800 MHz
</verb></tscreen>

<tt>/etc/ax25/nrports</tt>
<tscreen><verb>
# name  nominativo      alias   paclen  descrizione
netrom  VK2KTJ-9        LINUX   235     Linux Switch Port
</verb></tscreen>

<tt>/etc/ax25/nrbroadcast</tt>
<tscreen><verb>
# ax25_name     min_obs def_qual        worst_qual      verbose
4800            1       120             10              1
</verb></tscreen>

<itemize>
<item>Occorre che IP&lowbar;FORWARDING sia abilitato nel vostro
kernel.
<item>Quando necessario fare riferimento ai file di configurazione
AX.25 presentati nelle sezioni precedenti.
<item>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 <tt>44.136.8.97</tt>
<item><tt>44.136.8.68</tt> è il mio gateway locale di incapsulamento
IPIP, e per questo vi punto la mia route di default.
<item>Ogni macchina sulla mia rete Ethernet ha una route:
<tscreen><verb>
route add -net 44.0.0.0 netmask 255.0.0.0 \
	gw 44.136.8.97 window 512 mss 512 eth0
</verb></tscreen>
L'uso dei parametri <em>mss</em> e <em>window</em> permette di
ottimizzare le connessioni sia dal lato radio che da quallo Ethernet.
<item>Sulla macchina router vengono fatti girare smail, http, ftp ed
altri demoni in modo che questi servizi vengano resi disponibili ad
entrambe le reti.
<item>La macchina che funge da router è un piccolo 386DX20 con un
disco fisso da 20Mb ed una installazione di Linux minimale.
</itemize>

<sect1>Configurazione del gateway di incapsulamento IPIP.
<p>
Linux oggi è utilizzato spessissimo per i gateway di incapsulamento
TCP/IP in tutto il mondo. Il driver per il tunnelling supporta route
di incapsulamento multiple rendendo obsoleto il vecchio demone
<em>ipip</em>.
Una configurazione tipica è la seguente:

<tscreen><verb>
                                          .      .   .    .    . .
  ---                                .
   | 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
   |               |         |    .
   |               |         |     .
   |               \_________/       .
  ---                                     .      .   .    .    . .
</verb></tscreen>

I file di configurazione che si usano sono:

<tscreen><verb>
# /etc/rc.net
# Questa è una semplice configurazione che rende disponibile una
# porta radio KISS AX.25, un device Ethernet e sfrutta il tunnel
# driver del kernel per effettuare l'incapsulamento/deincapsulamento
# IPIP
#
echo "/etc/rc.net"
echo "  Configurazione:"
#
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.
</verb></tscreen>

e:

<tscreen><verb>
# /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
   ...
   ...
   ...
</verb></tscreen>

<tt>/etc/ax25/axports</tt>
<tscreen><verb>
# nome  nominativo     velocità paclen  window  descrizione
4800    VK2KTJ-0        4800    256     2       144.800 MHz
</verb></tscreen>

Alcuni punti su cui soffermarsi:

<itemize>
<item> Il nuovo tunnel driver usa il campo <em>gw</em> nella tabella
di routing al posto del parametro <em>pointopoint</em> per
specificare l'indirizzo del gateway IPIP remoto. Questo è il motivo
per cui ora sono supportate route multiple per ciascun'interfaccia.
<item>Si <bf>possono</bf> configurare due device di rete con lo
stesso indirizzo. In quest'esempio sia <tt>sl0</tt> che
<tt>tunl0</tt> 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.
<item>I comandi di routing usati per generare le route incapsulate
possono essere generate da una versione modificata dello script
<em>munge</em> che viene riportato più sotto. I comandi di routing
vengono scritti in un file separato e letto usando il comando
<em>bash</em> <tt>source/etc/ipip.routes</tt> (supponendo di aver
chiamato <tt>/etc/ipip.routes</tt> il file in questione). Il file
deve essere nel formato delle route di NOS.
<item>Si noti l'uso dell'argomento <em>window</em> nel comando
<em>route</em>. Settando opportunamente questo parametro si
migliorano le prestazioni del collegamento radio.
</itemize>

<p>
Ecco il nuovo script tunnel-munge:

<tscreen><verb>
#!/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 "# default the rest of amprnet via 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 "# fine"
</verb></tscreen>

<sect1>Configurazione del gateway di incapsulamento AXIP
<p>
Molti gateway radioamatoriali per Internet incapsulano l'AX.25,
NetRom 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.
<p>
Un geteway 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.
<p>
Il programma <em/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 <tt>/etc/ax25/ax25ipd.conf</tt>.

<sect2>Opzioni di configurazione di AXIP.
<p>
Il programma <em/ax25ipd/ possiede due modi principali di
funzionamento: il modo "digipeater" e il modo "tnc". Nel modo "tnc" il
demone viene considerato come un tnc KISS, gli si passano frames KISS
incapsulati in modo che li trasmetta, mentre nel modo "digipeater" si
comporta, appunto, come un digipeater AX.25. Tra questi due modi vi
sono delle sottili differenze.
<p>
Nel file di configurazione si stabiliscono le "route" o le
corrispondenze tra i nominativi AX.25 e gli indirizzi IP degli host
ai quali si vogliono mandare i pacchetti AX.25. Ogni route possiede
delle opzioni che verranno spegate più avanti.
<p>
Altre opzioni che vengono configurate sono:
<list>
<item>la tty che il demone <em/ax25ipd/ apre e la sua velocità (di
solito è un'estremità di una pipe)
<item>che nominativo usare in modo "digipeater"
<item>l'intervallo di emissione e il testo trasmesso dal beacon.
<item>se si vuole incapsulare i frame AX.25 in datagrammi IP oppure
UDP/IP. Quasi tutti i gateway AXIP usano l'IP encapsulation, ma
alcuni sono dietro a firewall che non permettono il passaggio a
datagrammi col protocol id dell'AXIP, costringendoli ad usare UDP/IP.
Quale che sia la scelta, deve essere uguale a quella dell'host TCP/IP
dall'altra parte del collegamento.
</list>

<sect2>Un tipico esempio di <tt>/etc/ax25/ax25ipd.conf</tt>.
<p>
<tscreen><verb>
#
# file di configurazioen ax25ipd per la stazione floyd.vk5xxx.ampr.org
#
# Selezione del tipo di trasporto. 'ip' permette la compatibilità
# con la maggior parte dei gateway
#
socket ip
#
# Indicazione del tipo di modalità (digi or tnc)
#
mode tnc
#
# Se si è scelta la modalità digi, occorre definire un nominativo.
# Se si è in modo tnc, il nominativo è attualmente opzionale, ma ciò
# può cambiare in future (2 nominativi se si usano due porte kiss)
#
#mycall vk5xxx-4
#mycall2 vk5xxx-5
#
# In modalità digi si può indicare un alias. (2 se si usano due porte
# kiss)
#
#myalias svwdns
#myalias2 svwdn2
#
# Si manda l'identificativo ogni 540 secondi ...
#
#beacon after 540
#btext ax25ip -- tncmode rob/vk5xxx -- Gateway sperimentale AXIP
#
# Porta seriale, o pipe connessa a kissattach in questo caso.
#
device /dev/ttyq0
#
# Velocità del device
#
speed 9600
#
# loglevel 0 - nessun output
# loglevel 1 - solo informazioni di configurazione
# loglevel 2 - principali eventi ed errori
# loglevel 3 - principali eventi ed errori, nonchè la traccia dei
#              frame AX.25
# loglevel 4 - tutti gli eventi
# log 0 per il momento, con syslog ancora non fuziona ....
#
loglevel 2
#
# Se siamo in modalità digi, ci dev'essere un vero tnc, 
# quindi uso param per settare i suoi parametri ....
#
#param 1 20
#
# Definizione degli indirizzi di broadcast. Ognuno degli indirizzi
# indicati sarà inoltrato ad ogni route in grado di effettuare il 
# broadcast.
broadcast QST-0 NODES-0
#
# definizione delle route ax.25
# il formato è route (nominativo/carattere jolly) (ip dell'host di
# destinazione) Se il ssid è zero la regola si applica a tutti i ssid.
#
# route <destcall> <destaddr> [flags]
#
# I flag validi sono
#         b  - permette il transito dei broadcast attraverso questa
#              route
#         d  - indica che questa è la route di default
#
route vk2sut-0 44.136.8.68 b
route vk5xxx 44.136.188.221 b
route vk2abc 44.1.1.1
#
#
</verb></tscreen>

<sect2>Uso di <em/ax25ipd/
<p>
<descrip>
<tag>Occorre creare le voci opportune nel file
<tt>/etc/ax25/axports</tt>:

<tscreen><verb>
# /etc/ax25/axports
#
axip	VK2KTJ-13	9600	256	AXIP port
#
</verb></tscreen>

<tag>Va usato il comando <em/kissattach/ per creare la porta da
utilizzare:</tag>
<tscreen><verb>
/usr/sbin/kissattach /dev/ptyq0 axip
</verb></tscreen>

<tag>Si lancia il programma <em/ax25ipd/:</tag>
<tscreen><verb>
/usr/sbin/ax25ipd &
</verb></tscreen>

<tag>Per testare il link AXIP link:</tag>
<tscreen><verb>
call axip vk5xxx
</verb></tscreen>
</descrip>

<sect2>Alcune note riguardo le route e i loro flag
<p>
Col comando "<tt/route/" si specifica dove si vuole inoltrare i
propri pacchetti incapsulati. Quando il demone <em/ax25ipd/ riceve un
pacchetto dalla sua interfaccia, confronta il nominativo di
destinazione con tutti quelli presenti nella tabella di routing. Se
lo trova, il pacchetto AX.25 viene incapsulato in un datagramma IP e
poi trasmesso all'indirizzo IP indicato.
<p>
Ci sono due flag che si possono aggiungere ad ogni comando di route
nel file <tt/ax25ipd.conf/:
<descrip>
<tag>b</tag>il traffico che ha come destinazione gli indirizzi
definiti dalla parola chiave "<tt/broadcast/" devono essere trasmessi
attraverso questa route.
<tag>d</tag>ogni pacchetto il cui indirizzo non compare in alcuna
route deve essere trasmessa attraverso questa route.
</descrip>
<p>
Il flag di broadcast è molto utile, poiché permette di inviare
informazioni destinate a tutte le stazioni, a molte destinazioni
AXIP. Normalmente le route AXIP sono di tipo punto-punto ed incapaci
di gestire pacchetti di tipo 'broadcast'.

<sect1>Collegare NOS e Linux con un pipe device.
<p>
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.
<p>
Brandon S. Allbery, KF8NH, ha fornito queste informazioni, che
consentono di interconnettere il NOS con Linux tramite il device
pipe.
<p>
Poiché sia Linux che NOS supportano il protocollo slip, è possibile
connettere i due creando un link di tipo slip. E' possibile
realizzare questo collegamento realizzando in collegamento tra due
porte seriali della stessa macchina collegate in loopback con un
cavo, ma questa realizzazione risulterebbe lenta e costosa. Linux, al
contrario, fornisce una funzionalità tipica dei sistemi Unix
chiamata 'pipe'. I pipe sono degli 'pseudo-device' che sono visti dai
programmi come normali device tty, ma che in realtà fungono da
collegamento verso un altro pipe. Per usare i pipe il programma
chiamante deve attivare il pipe <bf>master</bf> e, successivamente,
il programma chiamato deve fare lo stesso col pipe <bf>slave</bf>.
Una volta aperte le due porte, i programmi possono comunicare tra
loro semplicemente scrivendo caratteri sul device pipe, esattamente
come se fossero normali terminali seriali.
<p>
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 <tt>/dev</tt>; le
parti master del pipe sono chiamate <tt>ptyq[1-f]</tt>, mentre quelle
slave sono <tt>ttyq[1-f]</tt>. Si ricordi che vanno sempre in coppia,
per cui se si sceglie <tt>/dev/ptyqf</tt> come parte master, occorre
scegliere <tt>/dev/ttyqf</tt> come parte slave.
<p>
Una volta scelta una coppia di device pipe da usare, la parte master
va allocata al kernel Linux, mentre la parte slave va assegnata a
NOS; occorre quindi allocare un indirizzo unico per NOS, se non si è
già provveduto a farlo.
<p>
I pipe si configurano come se fossero device seriali, per cui per
creare il collegamento slip dal kernel Linux, si possono usare i
seguenti comandi:
<p>
<tscreen><verb>
# /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
</verb></tscreen>
<p>
In questo esempio al kernel Linux è stato assegnato l'indirizzo IP 
<tt>44.70.4.88</tt>, mentre NOS usa l'indirizzo
<tt>44.70.248.67</tt>.
Il comando <em>route</em> nell'ultima riga indica al kernel Linux di
instradare, attraverso il collegamento slip creato dal comando
<em>slattach</em>, tutti i datagrammi indirizzati verso amprnet.
Normalmente questi comandi vanno messi nel file
<tt>/etc/rc.d/rc.inet2</tt> 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 <em>cslip</em> al
posto di <em>slip</em>, 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.
<p>
Per configurare la parte NOS dall'altra parte del collegamento si può
usare la seguente configurazione:
<p>
<tscreen><verb>
# 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
</verb></tscreen>
<p>
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.


<sect>Dove trovare maggiori informazioni su.... ?
<p>
Poiché questo documento suppone che si abbia già maturato una certa
esperienza col packet radio, nel caso fosse necessario ho raccolto un
elenco di altre fonti di informazione che possono risultare utili.
<p>

<sect1>Packet Radio
<p>
Informazioni generali sul packet radio si possono trovare su questi
siti:
<list>
<item><url name="American Radio Relay League"
url="http://www.arrl.org/">,
<item><url name="Radio Amateur Teleprinter Society"
url="http://www.rats.org/">
<item><url name="Tucson Amateur Packet Radio Group"
url="http://www.tapr.org/">
</list>
<p>

<sect1>Documentazione sui protocolli
<p>
<list>
<item>AX.25, NetRom - Jonathon Naylor ha raccolto una serie di
documenti riguardo i protocolli usati nel packet radio. Questa
documentazione è stata raccolta nel file
<url name="ax25-doc-1.0.tar.gz"
	url="ftp://ftp.pspt.fi/pub/ham/linux/ax25/ax25-doc-1.0.tar.gz"
</list>
<p>

<sect1>Documentazione sull'hardware
<p>
<list>
<item>Informazioni sulla <bf>scheda PI2</bf> possono essere reperite
presso l'
<url name="Ottawa Packet Radio Group"
url="http://hydra.carleton.ca/">.
<item>Informazioni sull'hardware del <bf>Baycom</bf> si trovano alla
<url name="Baycom Web Page" url="http://www.baycom.de/">.
</list>

<sect>Discussioni riguardo i radioamatori e Linux.
<p>
Si possono trovare diversi luoghi di discussione riguardanti i
radioamatori e Linux, come ad esempio i newsgroup
<tt>comp.os.linux.*</tt>, o la mailing list <tt>HAMS</tt> presso
<tt>vger.rutgers.edu</tt> (il luogo di discussione principale per
l'uso del TCP/IP tra i radioamatori), oppure anche il canale
<tt>#linpeople</tt> della rete irc <tt>linuxnet</tt>.

Per iscriversi alla mailing list <bf>linux-hams</bf> occorre mandare
un messaggio a:
<tscreen><verb>
Majordomo@vger.rutgers.edu
</verb></tscreen>
con la riga:
<tscreen><verb>
subscribe linux-hams 
</verb></tscreen>
nel corpo del messaggio. Il titolo del messaggio stesso viene
ignorato. 
<p>I messaggi della mailing list <bf>linux-hams</bf> sono archiviati
presso: 

<url url="http://zone.pspt.fi/archive/linux-hams/"
	name="zone.pspt.fi">
e
<url url="http://zone.oh7rba.ampr.org/archive/linux-hams/"
	name="zone.oh7rba.ampr.org">.
Siete invitati a controllare questi archivi prima di mandare quesiti
alla mailing list, poiché a molte domande è già stata data
un'esauriente risposta.
<p>
Per iscriversi al <tt>tcp-group</tt> mandare una mail a:
<tscreen><verb>
listserver@ucsd.edu
</verb></tscreen>
con la riga:
<tscreen><verb>
subscribe tcp-group
</verb></tscreen>
nel testo del messaggio.

<bf>Nota:</bf> Ricordate che il <tt>tcp-group</tt> serve
principalmente per la discussione sull'uso di protocolli avanzati,
come il tcp/ip in campo radioamatoriale. <em>Le domande
esclusivamente su Linux non devono essere formulate in
quest'area.</em>


<sect>Riconoscimenti.
<p>
Le seguenti persone (qui elencate senza un particolare ordine) hanno
contribuito in un modo o nell'altro (magari anche senza saperlo) alla
stesura di questo documento: Jonathon Naylor, Thomas Sailer, Joerg
Reuter, Ron Atkinson, Alan Cox, Craig Small, John Tanner, Brandon
Allbery, Hans Alblas, Klaus Kudielka, Carl Makin.

<sect>Copyright.
<p>
AX25-HOWTO, informazioni sull'installazione e la configurazione di
alcuni dei più importanti pacchetti software per il supporto AX.25
sotto Linux. Copyright (c) 1996 Terry Dawson. Traduzione italiana di
Nico Alberti

Questo programma è free software; la distribuzione e l'utilizzo di
questo documento sono vincolati dai termini indicati nella versione 2
(o da qualunque versione successiva) della GNU General Public License
pubblicata dalla Free Software Foundation.

Questo documento viene distribuito con l'intento di essere utile, ma
SENZA ALCUNA GARANZIA, compreso quella implicita di FUNZIONALITA' o
di UTILITA' PER UN PARTICOLARE UTILIZZO. Vedere la GNU General Public
License per ulteriori dettagli.

Assieme a questo documento dovreste aver ricevuto una copia della GNU
General Public License; se ciò non fosse vi preghiamo di scrivere
alla 

Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA.

The AX25-HOWTO, information on how to install and configure some of
the more
important packages providing AX25 support for Linux.
Copyright (c) 1996 Terry Dawson.

This program is free software; you can redistribute it and/or modify
it under
the terms of the GNU General Public License as published by the Free
Software
Foundation; either version 2 of the License, or (at your option) any
later
version.

This program is distributed in the hope that it will be useful, but
WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
details.

You should have received a copy of the GNU General Public License
along with
this program; if not, write to the:

Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA.
</article>



