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 è
/etc/ax25/axport e occorre che vi sia una voce per ognuna
delle porte attive.
Il device di rete è ciò che viene manipolato quando si usa il comando `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.
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.
Ogni device driver, quando viene lanciato, crea un device di rete.
Opzioni di compilazione del Kernel:
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Serial port KISS driver for AX.25
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 minicom o seyon.
Per creare un device KISS si usa il programma kissattach. Nella sua forma più semplice si può usare questo programma come segue:
# /usr/sbin/kissattach /dev/ttyS0 radio
# kissparms -p radio -t 100 -s 100 -r 25
Il comando kissattach crea in device di rete di tipo KISS. I
device di questo tipo hanno nome `ax[0-9]'. La prima volta che
si usa kissattach viene creato `ax0', la seconda `ax1'
e così via. Ogni device KISS ha associato una porta seriale.
Il comando kissparms permette di modificare i parametri di un device KISS
In particolare nell'ultimo esempio viene creato un device KISS usando
il device della porta seriale `/dev/ttyS0' e la voce nel
file /etc/ax25/axports con una porta chiamata `radio'
che viene configurata inoltre con un txdelay e uno slottime
di 100 millisecondi, nonchè con un valore di ppersist pari a 25
Per maggiori informazioni potete far riferimento alle pagine man
L'utility 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
prima di ogni configurazione della parte AX.25. I device sui
quali si effettua la configurazione AX.25 sono interfacce pseudo-TTY,
(/dev/ttyq*), 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 `/dev/ptyq*', mentre
quella slave è chiamata `/dev/ttyq*'. C'è una relazione uno
a uno tra master e slave, quindi, ad esempio, /dev/ptyq0 è
la parte master di una pipe che ha /dev/ttyq0 come slave.
Occorre aprire per prima la parte master di una pipe. mkiss
sfrutta questo meccanismo per dividere una singola porta seriale in
diversi device.
Esempio: nel caso di un TNC dual port connesso alla porta seriale
/dev/ttyS0 a 9600 bps, i comandi
# /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
# /usr/sbin/kissattach /dev/ttyq0 port1
# /usr/sbin/kissattach /dev/ttyq1 port2
creano due device pseudo-tty ognuna delle quali si comporta come un
TNC single port. A questo punto si può usare /dev/ttyq0 e
/dev/ttyq1 come se fossero dei normali device seriali con un
TNC connesso. Questo significa che si dovrà usare kissattach per
ognuna di essi, come descritto nell'esempio sopra per le porte AX.25
chiamate port1 e port2. Non si deve usare kissattach sulla porta
seriale vera poiché viene usata dal programma mkiss.
Il programma mkiss ha diversi argomenti opzionali che possono essere usati:
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
modifica la velocità della porta seriale.
abilita l'handshaking hardware sulla porta seriale; è disabilitata di default poiché quest'opzione non è supportata dalla maggior parte delle implementazioni KISS.
abilita il logging delle informazioni nel file syslog.
Opzioni di compilazione del Kernel:
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
Thomas Sailer, <sailer@ife.ee.ethz.ch>, 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
Ser12 e i modem paralleli Par96 e PicPar.
Maggiori informazioni sui modem possono essere reperite presso il
Baycom Web site.
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.
Il driver Baycom, alla configurazione, crea dei device di rete
chiamati bc0, bc1, bc2 ecc.
L'utility sethdlc permette di configurare i parametri del driver, cosa che può essere fatta anche nella linea di comando di insmod al caricamento del modulo di controllo del Baycom
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.
# setserial /dev/ttyS0 uart none
# insmod hdlcdrv
# insmod baycom mode="ser12*" iobase=0x3f8 irq=4
Installa un Baycom Parallelo su LPT1 usando il rilevamento DCD hardware.
# insmod hdlcdrv
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0
Questo modo di configurare il driver per Baycom in realtà non è molto consigliato, visto che l'utility sethdlc funziona senza problemi anche con un solo dispositivo connesso.
Le pagine man di 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
# insmod hdlcdrv
# insmod baycom
o che il kernel sia stato compilato col supporto Baycom al suo interno.
Configurazione del device driver bc0 come modem Baycom parallelo
su LPT1 con DCD software:
# sethdlc -p -i bc0 mode par96 io 0x378 irq 7
Configurazione del device driver bc1 come modem Baycom seriale
su COM1 :
# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
I parametri di accesso al canale AX.25 sono equivalenti ai parametri KISS ppersist, txdelay e slottime. La loro modifica si effettua ancora una volta col comando sethdlc .
Segue un esempio; per maggiori informazioni la pagina man relativa a sethdlc è il posto più indicato dove reperire le informazioni più dettagliate.
Configurazione del device bc0 con TxDelay di 200 mS, SlotTime di
100 mS, PPersist di 40 in modalità half duplex:
# sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
Si noti che i valori di temporizzazione sono in millisecondi.
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.
Il primo passo è quello di configurare il device con un nominativo AX.25. L'utility ifconfig può essere utile allo scopo.
# /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
assegna al device Baycom bc0 il nominativo AX.25 VK2KTJ-15.
In alternativa sarebbe possibile usare il comando axparms, ma
occorrerebbe sempre l'uso di ifconfig per attivare il
device.
# ifconfig bc0 up
# axparms -setcall bc0 vk2ktj-15
Il passo successivo è quello di creare una voce nel file
/etc/ax25/axports come si farebbe per ogni altro device. La
voce nel file 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.
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.
Opzioni di compilazione del Kernel:
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
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.
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 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.
Quando viene configurato, il driver SoundModem crea dei device di
rete chiamati:
sm0, sm1, sm2.
Nota: 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.
Il driver SoundModem non inizializza la scheda audio, per cui occorre utilizzare l'apposito programma `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:
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c
dma2]
Quindi, volendo configurare una SoundBlaster all'indirizzo base di i/o 0x388, irq 10 e dma 1 si userà:
# setcrystal -s 0x388 -i 10 -d 1
Mantre per una scheda WindowSoundSystem all'indirizzo base di i/o 0x534, irq 5 e dma 3 si userà:
# setcrystal -w 0x534 -i 5 -d 3
Il parametro [-f synthio] modifica l'indirizzo del
sintetizzatore, mentre [-c dma2] serve per settare il secondo
canale DMA per permettere operazioni in full duplex
Una volta configurata la scheda audio occorre configurare il driver, indicandogli l'indirizzo della scheda e che tipo di modem emulare.
L'utility 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 insmod quando si carica il modulo SoundModem.
L'esempio seguente configura la SoundBlaster nel modo già visto precedentemente ed in modo da emulare un modem a 1200 bps:
# insmod hdlcdrv
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
Non è in effetti il modo migliore per effettuare le modifiche dato che, come detto già precedentemente, l'utility sethdlc funziona senza particolari problemi con una o più device.
Le pagine man di 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:
# insmod hdlcdrv
# insmod soundmodem
o che il kernel sia stato compilato con incluso il driver.
Configurazione della scheda WindowsSoundSystem configurata come negli
esempi precedenti e settata in modo da emulare un modem G3RUH 9600
compatible come device sm0 usando la porta parallela
all'indirizzo 0x378 per pilotare il Push-To-Talk della radio.
# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
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 sm1 usando la porta seriale
all'indirizzo 0x2f8 per pilotare il Push-To-Talk della radio.
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio
0x2f8
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 sm1 usando la porta seriale
all'indirizzo 0x2f8 per pilotare il Push-To-Talk della radio.
# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio
0x2f8
I parametri di accesso al canale AX.25 sono equivalenti ai parametri KISS ppersist, txdelay e slottime. La loro modifica si effettua ancora una volta col comando sethdlc .
Seguono un paio di esempi; per maggiori informazioni la pagina man relativa a sethdlc è il posto più indicato dove reperire le informazioni più dettagliate.
Configurazione del device sm0 con TxDelay di 100 mS, SlotTime di
50 mS, PPersist di 120 in modalità full duplex:
# sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full
Si noti che i valori di temporizzazione sono in millisecondi.
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 smdiag e smmixer.
fornisce due tipi di visualizzazione del segnale in ingresso: come osilloscopio e con un diagramma ad occhio.
permette di effettuare l modifica del livello audio in ricezione ed in trasmissione.
Per lanciare l'utility smdiag per il device SoundModem sm0
in modalità 'diagramma ad occhio' si usa il comando:
# smdiag -i sm0 -e
Per lanciare l'utility smmixer per il device SoundModem sm0
si usa il comando:
# smmixer -i sm0
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.
Il primo passo è quello di configurare il device con un nominativo AX.25. l'utility ifconfig può essere utile allo scopo.
# /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
assegna al device SoundModem sm0 il nominativo AX.25
VK2KTJ-15. In alternativa sarebbe possibile usare il comando
axparms, ma occorrerebbe sempre l'uso di ifconfig per
attivare il device.
# ifconfig sm0 up
# axparms -setcall sm0 vk2ktj-15
Il passo successivo è quello di creare una voce nel file
/etc/ax25/axports come si farebbe per ogni altro device. La
voce nel file axports è associato col device di rete configurato
per il nominativo ad esso legato; verrà usata quella col nominativo
assegnato al device SoundModem.
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.
Opzione di compilazione del Kernel:
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Ottawa PI and PI/2 support for AX.25
Il device driver per schede PI crea dei device chiamati
`pi[0-9][ab]'. La prima scheda PI sarà indicata come `pi0',
la seconda `pi1', eccetera. Le lettere `a' e `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:
# /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
Questo comando configura ed attiva la prima porta della prima scheda
PI assegnandole il nominativo VK2KTJ-15. Per usare il
dispositivo, tutto ciò che serve a questo punto è di inserire una
voce nel file /etc/ax25/axports col medesimo
nominativo/ssid.
Il driver per la scheda PI è stato scritto da
David Perry, <dp@hydra.carleton.edu>
Opzioni di compilazione del Kernel:
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Gracilis PackeTwin support for AX.25
Il device driver per la scheda PacketTwin crea i device
`pt[0-9][ab]'; la prima scheda PacketTwin localizzata nel
calcolatore sarà indicata come `pt0', la seconda `pt1' e
così via, mentre`a' and `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:
# /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
Questo comando configura e attiva la prima porta della prima scheda
PacketTwin col nominativo VK2KTJ-15. Per usare il device, tutto
ciò che occorre fare è confiurare una voce nel proprio file
/etc/ax25/axports con il medesimo nominativo/ssid.
Il driver per schede PacketTwin è stato scritto da
Craig Small VK2XLZ, <csmall@triode.apana.org.au>.
Opzioni di compilazione del Kernel:
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Z8530 SCC KISS emulation driver for AX.25
Joerg Reuter, DL1BKE, 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.
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.
I programmi di configurazione possono essere scaricati dalla pagina web di Joerg
o da:
db0bm.automation.fh-aachen.de
/incoming/dl1bke/
o:
insl1.etec.uni-karlsruhe.de
/pub/hamradio/linux/z8530/
o:
ftp.ucsd.edu
/hamradio/packet/tcpip/linux
/hamradio/packet/tcpip/incoming/
Troverete diverse versioni; va scelta quella che maggiormente si adatta alla versione di Kernel che si intende usare.
z8530drv-2.4a.dl1bke.tar.gz 2.0.* z8530drv-utils-3.0.tar.gz 2.1.6 o superiore
I seguenti comandi mi hanno permesso di compilare ed installare il pacchetto per la versione 2.0.30 del kernel
# 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
Dopo aver completato quest'operazione dovreste avere tre nuovi
programmi installati nella vostra directory /sbin:
gencfg, sccinit e sccstat. Questi
permetteranno di configurare il driver per la scheda.
Verrà anche creato nella directory /dev un un gruppo di
device speciali chiamati scc0-scc7; questi saranno
trattati in dettaglio più avanti e saranno i device `KISS' da
utilizzare.
Se scegliete l'opzione 'make for_kernel' occorrre ricompilare
il kernel. Per far sì che venga incluso il supporto per il driver
z8530 occorre rispondere `Y' alla domanda `Z8530 SCC
kiss emulation driver for AX.25' che viene fatta dalla procedura
di configurazione del kernel, ossia quando si dà il comando `make
config'.
Se invece avete fatto 'make module', occorre che il nuovo file
scc.o sia messo nella directory /lib/modules, ma non
occorre ricompilare il kernel. Si ricordi di usare il comando
insmod per caricare il modulo prima di provare a configurarlo.
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.
Nel paccheto è fornita un'esauriente documentazione che va letta in
caso di difficoltà. In particolare, maggiori informazioni si possono
trovare in doc/scc_eng.doc or
doc/scc_ger.doc. 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.
Il file di configurazione principale è /etc/z8530drv.conf e
viene letto dal programma sccinit, 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
# sccinit
nel file rc 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.
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
#define MAXSCC 4 nel file scc.c può essere
aumentato se si desidera il supporto per un numero maggiore di chip.
Le parole chiave possibili e i relativi argomenti sono:
serve per separare le sottosezioni. Non usa argomenti.
specifica l'indirizzo della porta dati per il canale `A' dello z8530. L'argomento è un numero esadecimale, ad esempio 0x300
specifica l'indirizzo della porta di controllo per il canale `A' dello z8530. L'argomento è un numero esadecimale, ad esempio 0x304
specifica l'indirizzo della porta dati per il canale `B' dello z8530. L'argomento è un numero esadecimale, ad esempio 0x301
specifica l'indirizzo della porta di controllo per il canale `A' dello z8530. L'argomento è un numero esadecimale, ad esempio 0x305
specifica l'IRQ (l'interupt) usata dalla scheda SCC 8530 descritta in questa sottosezione. L'argomento è un intero, ad esempio 5
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.
specifica il tipo particolare di scheda SCC 8530. L'argomento è una stringa alfanumerica che può assumere i seguenti valori:
scheda PA0HZP SCC
Scheda Eagle
scheda DRSI PC100 SCC
scheda PRIMUS-PC (DG9BL)
scheda BayCom (U)SCC
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.
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
questa parola chiave è opzionale; specifica l'indirizzo del registro per funzioni speciali presente su diverse schede SCC. Il valore di default è 0
questa parola chiave è opzionale e il suo valore di default è 0 (sic, n.d.t.).
Seguono alcuni configurazioni d'esempio per le schede più comuni:
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
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
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
Se con NOS si ha già una configurazione funzionante per la vostra scheda, si può usare il comando gencfg per convertire i comandi del driver NOS di PE1CHL in una forma che possa andare bene nel file di configurazione del driver z8530.
Per usare gencfg basta invocare il comando con gli stesi parametri usati per il driver di PE1CHL in NET/NOS. Per esempio il comando:
# gencfg 2 0x150 4 2 0 1 0x168 9 4915200
genererà un abbozzo di configurazione per la scheda OptoSCC.
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.
Queste parole chiave sono scritte anche nel file
/etc/z8530drv.conf
e devono apparire dopo la sezione dei parametri hardware.
L'ordine in cui queste appaiono è molto importante, ma quello in cui sono presentate qui dovrebbe andare bene.
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 /dev/scc0
questa parola chiave specifica la velocità
dell'interfaccia in bit al secondo: ad esempio 1200
questa parola chiave specifica da dove recuperare il clock per i dati. I valori consentiti sono:
normali operazioni in half duplex
il modem fornisce il proprio clock per le operazioni di Rx/TX
usa il divider full duplex se installato.
questa parola chiave specifica il tipo di codifica da
adottare per la rappresentazione dei dati. I valori consentiti sono
nrzi or nrz
specifica il numero di buffer di ricezione per cui allocare memoria. L'argomento è un intero, ad esempio 8.
specifica il numero di buffer di trasmissione per cui allocare memoria. L'argomento è un intero, ad esempio 8.
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 è 384
rappresenta il parametro KISS di ritardo nella trasmissione; l'argomento è un intero ed esprime una grandezza in ms.
rappresenta il parametro KISS di persist e il suo argomento è un intero.
rappresenta il parametro KISS di tempo di slot; l'argomento è un intero ed esprime una grandezza in ms.
rappresenta il parametro KISS di tail; il suo argomento è un intero ed esprime una grandezza in ms.
rappresenta il flag KISS che indica se la
trasmissione è in full duplex; l'argomento è un intero e i valori
ammessi sono:
1==Full Duplex, 0==Half Duplex.
rappresenta il parametro KISS di tempo di wait; l'argomento è un intero ed esprime una grandezza in ms.
rappresenta il parametro KISS 'min'; l'argomento è un intero ed esprime una grandezza in secondi.
rappresenta il parametro KISS indicante il tempo massimo di keyup; l'argomento è un intero ed esprime una grandezza in secondi.
rappresenta il parametro KISS di tempo di idle; l'argomento è un intero ed esprime una grandezza in ms.
rappresenta il parametro KISS 'maxdef'; l'argomento è un intero.
rappresenta il parametro KISS di valore di gruppo; l'argomento è un intero.
rappresenta il parametro KISS di tempo di 'txoff'; l'argomento è un intero ed esprime una grandezza in ms.
rappresenta il parametro KISS 'softdcd'; l'argomento è un intero.
rappresenta il flag KISS 'slip'; l'argomento è un intero.
Per usare il driver basta semplicemente utilizzare i device
/dev/scc* 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:
# kissattach -s 4800 /dev/scc0 VK2KTJ
Si può anche usare NOS per effettuare la configurazione nello stesso modo. Da JNOS, per esmpio, si può fare:
attach asy scc0 0 ax25 scc0 256 256 4800
Per la diagnosi di eventuali problemi, si può usare il programma sccstat per mostrare la configurazione corrente di un device SCC. Per usarlo si può dare il comando:
# sccstat /dev/scc0
in questo modo verranno mostrati un sacco di informazioni sulla
configurazione e sul comportamento della porta SCC
/dev/scc0.
Il comando sccparam permette di cambiare la configurazione
dopo il boot del sistema. La sua sintassi è molto simile al comando
NOS param, quindi, ad esempio, per settare a 100 ms il
valore di txtail si puo fare:
# sccparam /dev/scc0 txtail 0x8
Opzioni di compilazione del Kernel:
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] BPQ Ethernet driver for AX.25
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.
I device di rete BPQ hanno nome `bpq[0-9]'. Il device
`bpq0' è associato com il device `eth0', `bpq1' con
`eth1' e così via.
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' Ethernet-HOWTO.
Per configurare il supporto BPQ occorre dotare di un nominativo AX.25 il device Ethernet col seguente comando:
# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
Ancora una volta si ricordi che il nominativo specificato deve essere
presente anche nel file /etc/ax25/axports che si intende
usare per questa porta.
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:
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
/etc/ax25/axports.
/etc/ax25/axports è un semplice file di testo, da creare con
un editor. Il suo formato è il seguente:
portname callsign baudrate paclen window description
dove:
è il nome che viene dato alla porta.
è il nominativo AX.25 che si vuole assegnare alla porta.
è la velocità con la quale si vuol far comunicare la porta col proprio TNC.
è la grandezza massima del pacchetto che si vuole che la porta usi per le trasmissioni AX.25.
è il parametro di finestra AX.25 (K), cioè il valore
di MAXFRAME di molti TNC.
è la descrizione della porta.
La mia è la seguente:
radio VK2KTJ-15 4800 256 2 4800bps 144.800
MHz
ether VK2KTJ-14 10000000 256 2 BPQ/ethernet
device
Si ricordi di usare un nominativo/ssid univoco per ogni porta AX.25 che si crea. Occorre creare, dunque, una voce per ogni 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.
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 axparms permette di effettuare questa operazione; le pagine man sono sempre la fonte migliore di informazioni su questo comando, ma un semplice esempio può essere:
# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
Questo comando indica che il percorso per VK2XLZ deve avvenire
tramite il digipeater VK2XLZ sulla porta AX.25 chiamata
radio.