---

6. Configuration d'un port AX.25

Chaque application AX.25 nécessite un fichier de configuration spécifique pour obtenir les paramètres des ports AX.25 définis sur votre système. Pour les ports AX.25, il s'agit du fichier /etc/ax25/axport. Chaque port dont vous souhaitez vous servir doit être répertorié dans ce fichier.

6.1 Création des périphériques AX.25

Le périphérique réseau correspond à ce qui apparaît lorsque vous entrez la commande `ifconfig'. Il s'agit de l'abstraction logicielle par le biais de laquelle le noyau Linux émet et reçoit des données réseau. Presque tous les périphériques réseau sont associés à une entité matérielle mais il y a certaines exceptions. Le périphérique réseau se rattache directement à un gestionnaire de périphérique.

Le code AX.25 de Linux inclut un grand nombre de gestionnaires de périphériques. Le pilote KISS est sûrement le plus courant mais on peut également citer les pilotes SCC, Baycom et modem-son.

Chacun de ces pilotes crée un périphérique lors de son invocation.

Création des périphériques KISS

Options de configuration du noyau :

General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Serial port KISS driver for AX.25

Le TNC KISS sur un port série constitue sûrement la configuration la plus courante. À vous de préconfigurer et de connecter le TNC à un port série. Un programme de communication tel minicom ou seyon vous permettra de configurer le TNC en kiss.

Servez-vous du programme kissattach pour créer les périphériques KISS. Par exemple :

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

Les périphériques KISS se retrouvent sous la dénomination `ax[0-9]'. Au premier appel de kissattach, `ax0' est créé ; au second, `ax1', etc ... Chaque périphérique KISS est associé à un port série.

kissparms permet de positionner divers paramètres sur un périphérique KISS.

De façon précise, l'exemple précédent créerait un périphérique KISS reposant sur le périphérique série `/dev/ttyS0' et le port `radio' du fichier /etc/ax25/axports. Il positionne ensuite txdelay et slottime à 100 ms et ppersist à 25.

Reportez vous aux pages de man pour davantage d'informations.

Configuration des TNC Dual Port

L'utilitaire mkiss inclus dans le paquetage ax25-utils permet l'emploi des modems d'un TNC à doubles ports. La configuration est simple. Elle consiste à prendre le contrôle du périphérique série connecté au TNC multiports et à le faire ressembler à une collection de périphériques chacun connecté à un TNC monoport. Vous devrez le faire avant toute autre configuration AX.25. Les périphériques que vous configurerez correspondent à des pseudo-TTY (/dev/ttyq*) et non aux ports série. Les pseudo-TTY mettent en place un équivalent de tuyau via lequel des programmes prévus pour dialoguer avec des périphériques de type tty peuvent communiquer. Chaque tuyau possède une extrémité maître (`/dev/ptyq*') et une esclave (`/dev/ttyq*'). Les extrémités sont en relation telles que si /dev/ptyq0 est l'extrémité maître d'un tuyau, alors /dev/ttyq0 est son extrémité esclave. Le côté maître doit être ouvert avant le côté esclave. mkiss divise un périphérique série grâce à ce mécanisme.

Par exemple, pour un TNC double-port connecté au port série /dev/ttyS0 en 9600 bps, les commandes suivantes créeront deux pseudo-tty qui se comporteront comme des ports séries munis de TNC usuels :

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

/dev/ttyq0 et /dev/ttyq1 se manipulent ensuite avec kissattach comme décrit précédemment dans l'exemple relatif à port1 et port2. N'utilisez pas directement kissattach sur le port série car mkiss y accède.

mkiss accepte de nombreux arguments optionnels. En voici un résumé :

-c

provoque l'ajout d'un octet de contrôle à chaque trame KISS. La plupart des mises en oeuvre de KISS ne le gèrent pas. La rom KISS G8BPG en est capable.

-s <speed>

fixe le débit du port série.

-h

active la négociation matérielle sur le port série (inactive par défaut). La plupart des mises en oeuvre KISS ne la gèrent pas.

-l

déclenche l'émission de messages à destination de syslog.

Création d'un périphérique Baycom

Options de compilation du noyau :

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

Malgré l'opinion suivant laquelle les modems Baycom ne fonctionneraient pas très bien sous Linux, Thomas Sailer(<sailer@ife.ee.ethz.ch>) en a développé le gestionnaire. Son pilote gère les ports série Ser12 et Par96 ainsi que les modems parallèles PicPar. Vous trouverez davantage d'informations concernant les modems à l'adresse : Baycom Web site.

La première étape consiste à déterminer les ports d'entrée/sortie et les adresses des ports série ou parallèle auxquels se connecte(nt) le(s) modem(s).

Les périphériques BayCom se retrouvent sous la dénomination bc0, bc1, bc2 etc...

L'utilitaire sethdlc permet de configurer le pilote avec les paramètres précédents. Si votre système n'est muni que d'un seul modem, vous pouvez également les passer en argument lors du chargement du module avec insmod.

Un exemple. Désactivation du gestionnaire du port série COM1: puis configuration du pilote BayCom pour un modem série Ser12 sur ce même port avec activation de l'option logicielle DCD :

# setserial /dev/ttyS0 uart none
# insmod hdlcdrv
# insmod baycom mode="ser12*" iobase=0x3f8 irq=4

Un modem parallèle de type Par96 sur le port LPT1: utilisant la détection DCD matérielle :

# insmod hdlcdrv
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0

Ce n'est pas la meilleure façon de faire. L'utilitaire sethdlc fonctionne également avec plusieurs périphériques.

La page de man d'sethdlc est très détaillée mais quelques exemples mettront en lumière les aspects les plus importants de la configuration. On suppose que le module BayCom a déjà été chargé avec :

# insmod hdlcdrv
# insmod baycom

Vous pouvez également avoir incorporé le gestionnaire en dur dans le noyau.

Configuration de bc0 pour un modem parallèle BayCom sur LPT1 avec détection DCD logicielle :

# sethdlc -p -i bc0 mode par96 io 0x378 irq 7

Configuration de bc1 pour un modem série sur COM1 :

# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4

Configuration des paramètres d'accès au canal AX.25

Ces paramètres équivalent à ppersist, txdelay et slottime pour KISS. Ici aussi, vous utiliserez sethdlc.

La page de man relative à sethdlc reste la source d'informations la plus complète mais un ou deux autres exemples ne feront pas de mal.

Configuration de bc0 avec TxDelay égal à 200 ms, SlotTime à 100 ms, PPersist à 40, en half duplex :

# sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half

Notez que les paramètres de durée sont donnés en millisecondes.

Configuration d'AX.25 avec le pilote BayCom

Le pilote BayCom crée des périphériques réseau standard dont la configuration pour AX.25 est voisine de celle liée à l'emploi des cartes PI ou PacketTwin.

Tout d'abord il faut donner un numéro d'identification AX.25 au périphérique. ifconfig le fait très bien :

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

La commande précédente affecte l'identité AX.25 VK2KTJ-15 au périphérique bc0. Vous disposez également de axparms mais vous aurez de toute façon besoin d'ifconfig pour activer le périphérique :

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

L'étape suivante consiste à ajouter une entrée dans le fichier /etc/ax25/axports comme vous le feriez pour tout autre périphérique. Les données du fichier axports étant associées aux périphériques réseau par l'intermédiaire du numéro d'identification, la ligne que vous rajouterez devra comprendre celui de votre BayCom.

La nouvelle interface AX.25 se comporte à présent comme les autres. Vous pouvez la configurer pour IP, la gérer via ax25d et l'utiliser pour NetRom ou Rose si bon vous semble.

Création d'un périphérique modem-son

Options de compilation du noyau :

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 a développé un nouveau pilote noyau qui traite une carte son comme un modem : connectez votre dispositif radio directement sur votre carte son pour émettre des paquets ! Thomas conseille au moins un 486DX2 à 66 MHz pour exploiter le logiciel ; tout le traitement numérique est effectué par le microprocesseur.

Actuellement, le pilote émule les modems AFSK à 1200 bps, HAPN à 4880 et FSK à 9600 (compatible avec G3RUH). Seules les cartes son compatibles SoundBlaster et WindowsSoundSystem sont supportées. Un soupçon d'électronique est nécessaire pour aider la carte son à alimenter le dispositif radio. Des informations sur ce sujet se trouvent sur la page suivante : Thomas's SoundModem PTT circuit web page. Les possibilités sont nombreuses : récupération à la sortie de la carte son, traitement sur les ports parallèle, série ou midi. Des exemples de schémas illustrent tout ces cas sur le site de Thomas.

Les périphériques modem-son se retrouvent sous la dénomination sm0, sm1, sm2, etc...

Remarque: le pilote SoundModem et le sous-système de gestion du son entrent en compétition sous Linux. Assurez-vous que le son est désactivé avant d'utiliser le pilote SoundModem. Vous pouvez bien sûr compiler les deux en tant que modules, les insérer et les ôter en fonction de vos besoins.

Configuration de la carte son

Le pilote SoundModem n'initialise pas la carte réseau. Le paquetage ax25-utils comprend l'utilitaire `setcrystal' pour le faire sur les cartes son à base de composants Crystal. Si vous avez un autre modèle de carte, servez-vous d'un autre logiciel pour l'initialiser. L'emploi de setcrystal est fort simple :

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

Par exemple, pour une carte SoundBlaster à l'adresse 0x388 employant l'interruption 10 et la canal DMA 1, vous entreriez :

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

Pour une carte WindowSoundSystem à l'adresse 0x534 employant l'interruption 5 et la canal DMA 3 :

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

Le paramètre [-f synthio] correspond à l'adresse du synthétiseur. Le paramètre [-c dma2] détermine le second canal DMA pour un fonctionnement simultané dans les deux sens (full-duplex).

Configuration des périphériques modem-son

Une fois la carte son configurée, vous devez spécifier au pilote où la trouver et quelle type de modem il lui faut émuler.

L'utilitaire sethdlc vous permet de passer ces paramètres. Si vous n'avez qu'une seule carte installée, vous pouvez les passer en arguments à l'insertion du module SoundModem.

Par exemple, avec une seule carte de type SoundBlaster configurée comme ci-dessus, émulant un modem 1200 bps :

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

Ce n'est pas la meilleure façon de faire. L'utilitaire sethdlc fonctionne également avec plusieurs périphériques.

La page de man d'sethdlc est très détaillée mais quelques exemples mettront ici encore en lumière les aspects les plus importants de la configuration. On suppose que le module modem-son a déjà été chargé avec :

# insmod hdlcdrv
# insmod soundmodem

Vous pouvez également avoir incorporé le gestionnaire en dur dans le noyau.

Configuration du pilote pour émuler un modem G3RUH 9600 sur le périphérique sm0 avec la carte WindowsSoundSystem précédente et le port parallèle en 0x378 pour alimenter l'émetteur :

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

Configuration du pilote pour émuler un modem HAPN 4800 sur le périphérique sm1 avec la carte SoundBlaster précédente et le port série en 0x2f8 pour alimenter l'émetteur :

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

Configuration du pilote pour émuler un modem AFS 1200 sur le périphérique sm1 avec la carte SoundBlaster précédente et le port série en 0x2f8 pour alimenter l'émetteur :

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

Configuration des paramètres d'accès au canal AX.25

Ces paramètres équivalent à ppersist, txdelay et slottime pour KISS. Ici aussi, vous utiliserez sethdlc.

La page de man relative à sethdlc reste la source d'informations la plus complète mais un ou deux autres exemples ne feront toujours pas de mal.

Configuration de sm0 avec TxDelay égal à 100 ms, SlotTime à 50 ms, PPersist à 128 en full duplex :

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

Notez que les paramètres de durée sont donnés en millisecondes.

Choix du volume et ajustement du pilote

Il est très important que les niveaux audio soient correctement ajustés pour qu'un modem-radio fonctionne correctement. Les modem-son n'échappent pas à la règle. Thomas a mis au point des utilitaires pour faciliter cette tâche : smdiag et smmixer.

smdiag

fournit deux type d'affichage : soit un écran de type oscilloscope, soit un visuel normal.

smmixer

permet l'ajustement des niveaux audio de transmission et de réception.

smdiag en mode 'visuel' avec un périphérique SoundModem en sm0 :

# smdiag -i sm0 -e

smmixer avec un périphérique SoundModem en sm0 :

# smmixer -i sm0

Configuration d'AX.25 avec le pilote SoundModem

Le pilote soundmodem crée des périphériques réseau standard dont la configuration pour AX.25 est voisine de celle liée à l'emploi des cartes PI ou PacketTwin.

Tout d'abord il faut donner un numéro d'identification AX.25 au périphérique. ifconfig le fait très bien :

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

La commande précédente affecte l'identité AX.25 VK2KTJ-15 au périphérique sm0. Vous disposez également de axparms mais vous aurez de toute façon besoin d'ifconfig pour activer le périphérique :

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

L'étape suivante consiste à ajouter une entrée dans le fichier /etc/ax25/axports comme vous le feriez pour tout autre périphérique. Les données du fichier axports étant associées aux périphériques réseau par l'intermédiaire du numéro d'identification, la ligne que vous rajouterez devra comprendre celui de votre modem-son.

La nouvelle interface AX.25 se comporte à présent comme les autres. Vous pouvez la configurer pour IP, la gérer via ax25d et l'utiliser pour NetRom ou Rose si bon vous semble.

Création d'un périphérique à base de carte PI

Options de compilation du noyau :

General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Ottawa PI and PI/2 support for AX.25

Les périphériques PI se retrouvent sous la dénomination `pi[0-9][ab]' où la première carte détectée se verra allouer `pi0', la seconde `pi1', etc... `a' et `b' se rapportent à la première et à la seconde interface physique des cartes PI. Si vous avez inclus le pilote de cartes PI dans votre noyau et que la détection s'est effectuée correctement, vous pouvez configurer le périphérique :

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

La commande précédente affecte l'identité AX.25 VK2KTJ-15 au premier port de la carte PI et l'active. Pour utiliser le périphérique, il vous reste à ajouter au fichier /etc/ax25/axports l'entrée correspondant à son identité AX.25.

Le gestionnaire de cartes PI a été écrit par : David Perry, <dp@hydra.carleton.edu>

Création d'un périphérique PacketTwin

Options de compilation du noyau :

General setup  --->
    [*] Networking support
Network device support  --->
    [*] Network device support
    ...
    [*] Radio network interfaces
    [*] Gracilis PackeTwin support for AX.25 

Les périphériques PacketTwin se retrouvent sous la dénomination `pt[0-9][ab]' où la première carte détectée se verra allouer `pt0', la seconde `pt1', etc. `a' et `b' se rapportent à la première et à la seconde interfaces physiques des cartes PacketTwin. Si vous avez inclus le pilote de cartes PI dans votre noyau et que la détection s'est effectuée correctement, vous pouvez configurer le périphérique :

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

La commande précédente affecte l'identité AX.25 VK2KTJ-15 au premier port de la carte PacketTwin et l'active. Pour utiliser le périphérique, il vous reste à ajouter au fichier /etc/ax25/axports l'entrée correspondant à son identité AX.25.

Le gestionnaire de cartes PacketTwin a été écrit par : Craig Small VK2XLZ, <csmall@triode.apana.org.au>.

Création d'un périphérique SCC générique

Options de compilation du noyau :

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 a écrit le module générique de gestion des cartes à base de SCC Z8530. Son pilote supporte une large gamme de cartes différentes et offre une interface similaire à un TNC KISS que vous pouvez traiter comme telle.

Récupération et compilation des outils de configuration

Bien que le pilote soit inclus dans les arborescences standard du noyau, Joerg accompagne le paquetage de configuration dont vous aurez besoin des versions les plus récentes.

Vous trouverez le paquetage des outils de configuration à une des adresses suivantes : Joerg's web page

db0bm.automation.fh-aachen.de

/incoming/dl1bke/

insl1.etec.uni-karlsruhe.de

/pub/hamradio/linux/z8530/

ftp.ucsd.edu

/hamradio/packet/tcpip/linux
/hamradio/packet/tcpip/incoming/

Différentes versions s'offrent à vous. Choisissez la plus adaptée à votre noyau :

z8530drv-2.4a.dl1bke.tar.gz   2.0.*
z8530drv-utils-3.0.tar.gz    2.1.6 et au delà 

Voici les commandes que j'ai employées lors de la compilation et de l'installation du paquetage pour mon noyau 2.0.30 :

# cd /usr/src
# gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
# cd z8530drv
# make clean
# make dep
# make module         # Si vous souhaitez modulariser le pilote
# make for_kernel     # Si vous préférez un pilote inclus dans le noyau
# make install

Au terme de ces opérations, trois nouveaux exécutables devraient s'être installés dans votre répertoire /sbin : gencfg, sccinit et sccstat. Ces programmes vont vous servir à configurer le pilote pour votre carte.

De nouveaux périphériques apparaîtront également dans votre répertoire /dev sous les noms scc0-scc7. Ils joueront plus tard le rôle de périphériques KISS que vous pourrez employer.

Si vous lancez 'make for_kernel', vous devrez également recompiler votre noyau. Afin que le pilote z8530 soit inclus, vérifiez que vous avez bien répondu `Y' à : `Z8530 SCC kiss emulation driver for AX.25' durant le `make config'.

Si vous avez choisi 'make module', le module scc.o sera installé dans le sous-répertoire adéquat de /lib/modules et il ne vous sera pas nécessaire de recompiler tout le noyau. N'oubliez pas d'exécuter un insmod afin de charger le module avant d'essayer de le configurer.

Configurer le pilote pour sa carte

La conception du pilote SCC z8530 vise une flexibilité maximale ainsi que la gestion du plus grand nombre de cartes possible. Le prix à payer se retrouve au niveau de la configuration.

Le paquetage comprend une documentation plus détaillée et vous aurez tout intérêt à vous y reporter si vous rencontrez le moindre problème. Intéressez-vous plus particulièrement à doc/scc_eng.doc et à doc/scc_ger.doc. J'ai repris les points les plus importants mais de nombreux détails sont passés sous silence.

Le fichier de configuration principal, lu par le programme sccinit, se trouve en /etc/z8530drv.conf. Il se divise en deux parties : configuration des paramètres matériels et configuration du canal. Une fois ce fichier au point, vous n'aurez plus qu'à ajouter :

# sccinit

au fichier rc chargé de la configuration du réseau et le périphérique sera initialisé conformément au contenu du fichier de configuration. Effectuez ces opérations avant d'utiliser le gestionnaire.

Configuration des paramètres matériels

La première partie se divise en strophes, chacune correspondant à un composant 8530. Une strophe comprend une liste de mots clefs et d'arguments. Le fichier peut décrire jusqu'à quatre composants SCC par défaut. Si vous avez besoin d'aller au-delà, modifiez la ligne #define MAXSCC 4 dans le fichier scc.c.

Liste des mots-clefs et des arguments :

chip

le terme chip sert à séparer les strophes. Il ne nécessite pas d'arguments et ceux-ci sont de toute façon ignorés.

data_a

adresse du port de données pour le canal `A' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x300).

ctrl_a

adresse du port de contrôle pour le canal `A' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x304).

data_b

adresse du port de données pour le canal `B' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x301).

ctrl_b

adresse du port de contrôle pour le canal `B' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x305).

irq

interruption (IRQ) utilisée par le SCC 8530. Un entier, 5 par exemple, est attendu.

pclock

fréquence du signal d'horloge sur la broche PCLK du 8530. L'argument est donné en Hz par un nombre entier (4915200 par défaut).

board

modèle de la munie du 8530 : <<====== ne manque-t-il pas un mot ?

PA0HZP

carte SCC PA0HZP

EAGLE

carte Eagle

PC100

carte SCC PC100 DRSI

PRIMUS

carte PRIMUS-PC (DG9BL)

BAYCOM

carte (U)SCC BayCom

escc

optionnel, active la gestion des cartes SCC étendues (ESCC) telles la 8580, la 85180 ou la 85280. L'argument est une chaîne de caractères qui peut prendre les valeurs `yes' ou `no' (`no' par défaut).

vector

optionnel, donne l'adresse du vecteur d'acquittement pour les cartes PA0HZP. Il est commun à l'ensemble des composants et prend par défaut la valeur nulle.

special

optionnel, donne l'adresse du registre spécial sur diverses cartes. Nul par défaut.

option

optionnel. Nul par défaut.

Quelques exemples de configuration des cartes les plus courantes :

BayCom USCC

chip    1
data_a  0x300
ctrl_a  0x304
data_b  0x301
ctrl_b  0x305
irq     5
board   BAYCOM
#
# SCC chip 2
#
chip    2
data_a  0x302
ctrl_a  0x306
data_b  0x303
ctrl_b  0x307
board   BAYCOM
    

PA0HZP SCC card

chip 1
data_a 0x153
data_b 0x151
ctrl_a 0x152
ctrl_b 0x150
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
#
#
#
chip 2
data_a 0x157
data_b 0x155
ctrl_a 0x156
ctrl_b 0x154
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
    

DRSI SCC card

chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
    

Si vous disposez déjà d'une configuration qui fonctionne avec votre carte sous NOS, la commande gencfg permet de convertir les commandes du pilote NOS PE1CHL en quelque chose d'utilisable pour le pilote z8530.

gencfg s'invoque simplement avec les mêmes paramètres que ceux employés pour le pilote PE1CHL avec NET/NOS. Par exemple, pour obtenir une ébauche de fichier de configuration pour une carte OptopSCC :

# gencfg 2 0x150 4 2 0 1 0x168 9 4915200

Configuration du canal

Vous préciserez tous les autres paramètres relatifs au port que vous configurez dans la section spécifique au canal. Cette section se divise également en strophes. Une strophe correspond à un port logique et il y aura donc deux strophes de canal pour une strophe de paramètres matériels puisque chaque SCC 8530 inclut deux ports.

Les mots-clefs et leurs arguments s'inscrivent également dans le fichier /etc/z8530drv.conf, à la suite de la section des paramètres matériels.

L'ordre est très important dans cette section mais tout devrait marcher même si vous vous écartez de celui proposé.

device

en première position, spécifie le nom du périphérique auquel le reste de la configuration s'applique (par exemple /dev/scc0)

speed

débit de l'interface en bits par seconde. Un nombre entier est attendu (par exemple 1200)

clock

origine de l'horloge de synchronisation des données. Les valeurs possibles sont :

dpll

fonctionnement normal monodirectionnel (half-duplex) ;

external

le modem dispose de sa propre horloge Rx/Tx ;

divider

utilisation du diviseur bidirectionnel (si disponible).

mode

type de codage des données. À choisir entre nrzi et nrz

rxbuffers

nombre de tampons de réception à allouer en mémoire. Un nombre entier est attendu (8 par exemple)

txbuffers

nombre de tampons d'émission à allouer en mémoire. Un nombre entier est attendu (8 par exemple )

bufsize

taille des tampons d'émission et de réception. La valeur est donnée en octets et correspond à la longueur totale d'une trame. Elle doit donc prendre en compte aussi bien les données que l'en-tête. Cet argument est optionnel et prend par défaut la valeur 384

txdelay

délai d'attente de la transmission KISS. Un nombre entier de ms est attendu

persist

paramètre persist (KISS). Argument de type entier

slot

slot time (KISS). Argument de type entier en ms

tail

the KISS transmit tail value. Argument entier en ms

fulldup

indicateur de fonctionnement bidirectionnel (KISS), à choisir entre 1 pour le bidirectionnel et 0 pour le monodirectionnel

wait

paramètre d'attente (KISS). Argument de type entier en ms

min

paramètre min (KISS). Argument de type entier en secondes

maxkey

temps de keyup (?) maximal (KISS). Argument de type entier en secondes

idle

délai d'attente sur inactivité (KISS). Argument de type entier en secondes

maxdef

paramètre maxdef (KISS). Argument de type entier

group

paramètre group (KISS). Argument de type entier

txoff

valeur de txoff (KISS). Argument de type entier en ms

softdcd

valeur de softdcd (KISS). Argument de type entier

slip

indicateur slip (KISS). Argument de type entier

Utilisation du pilote

Il suffit d'employer les périphériques /dev/scc* comme on le ferait avec n'importe quel tty série connecté à un TNC KISS. Par exemple, avec une carte SCC, vous exécuteriez quelque chose du style :

# kissattach -s 4800 /dev/scc0 VK2KTJ

NOS permet également d'attacher le périphérique de la même façon. Avec JNOS, vous entreriez une commande du style :

attach asy scc0 0 ax25 scc0 256 256 4800

Les outils sccstat et sccparam

Afin de diagnostiquer les problèmes, sccstat affiche la configuration courante de n'importe quel périphérique SCC. Essayez :

# sccstat /dev/scc0

Vous devriez récupérer une quantité impressionnante d'informations touchant à la configuration et à l'état du port SCC /dev/scc0.

sccparam sert à modifier la configuration après l'initialisation du noyau. La syntaxe est similaire à celle de la commande param de NOS. Pour positionner txtail à 100 ms sur un port :

# sccparam /dev/scc0 txtail 0x8

Création d'un périphérique BPQ

Options de configuration du noyau :

                                                              
General setup  --->                                                         
    [*] Networking support                                                  
Network device support  --->                                                    
    [*] Network device support                                              
    ...                                                                         
    [*] Radio network interfaces    
    [*] BPQ Ethernet driver for AX.25

Linux gère le BPQ compatible Ethernet. Vous pouvez ainsi dialoguer en AX.25 via un réseau Ethernet local et interconnecter votre poste Linux avec d'autres machines BPQ sur réseau local.

Les périphériques BPQ se retrouvent sous la dénomination `bpq[0-9]'. `bpq0' est associé à `eth0', `bpq1' à `eth1' etc.

La configuration est simple. Mettez d'abord en place un périphérique Ethernet standard. Pour cela, vous aurez pris soin d'inclure dans le noyau la gestion de votre adaptateur Ethernet. Pour plus de détails, reportez vous à : Ethernet-HOWTO.

Avant d'activer la gestion BPQ, le périphérique Ethernet doit s'être vu affecter un numéro d'identification AX.25. Par exemple :

# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up

Vérifiez bien que l'identifiant correspond à celui qui figure dans le fichier /etc/ax25/axports pour ce port.

Configuration d'un noeud BPQ pour le dialogue avec la couche AX.25 de Linux

Souvent, l'Ethernet BPQ repose sur des adresses de type multicast. Ce n'est pas le cas dans la mise en oeuvre sous Linux qui recourt aux adresses générales (broadcast) usuelles sur Ethernet. Le fichier NET.CFG du gestionnaire ODI BPQ doit donc être modifié pour ressembler à ce qui suit :

LINK SUPPORT

        MAX STACKS 1
        MAX BOARDS 1

LINK DRIVER E2000                    ; ou tout autre MLID adapté à votre carte

        INT 10                       ;
        PORT 300                     ; selon votre carte

        FRAME ETHERNET_II

        PROTOCOL BPQ 8FF ETHERNET_II ; requis pour BPQ - peut jouer sur PID

BPQPARAMS                            ; optionnel - requis seulement pour 
                                     ; modifier la cible par défaut 

        ETH_ADDR  FF:FF:FF:FF:FF:FF  ; adresse de la cible 

6.2 Mise au point du fichier /etc/ax25/axports

/etc/ax25/axports est un fichier texte standard que vous créerez avec n'importe quel éditeur. Son format est le suivant :

portname  callsign  baudrate  paclen  window  description

avec :

portname

nom affecté au port

callsign

identifiant AX.25

baudrate

vitesse de communication avec le TNC

paclen

longueur de paquet maximale applicable au port pour les communications AX.25 en mode connecté

window

paramètre de fenêtre (K) AX.25. Il s'agit de la même chose que le paramètre MAXFRAME de nombreux TNC.

description

champ de commentaire

Chez moi, le fichier ressemble à ça :

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

Rappelez-vous que vous devez affecter un numéro d'identification (ssid) unique à chaque port AX.25 que vous créez. Ajoutez une ligne pour chaque périphérique que vous emploierez ; cela concerne les ports KISS, BayCom, SCC, PI, PT et modem-son. Les entrées dans le fichier sont associées aux périphériques réseau par le biais de l'identificateur AX.25 : au moins une bonne raison de les prendre différents.

6.3 Routage AX.25

Vous pouvez décider de mettre en place des routes par défaut spécifiques à certains hôtes, par exemple pour des connexions AX.25 courantes ou des connexions IP. L'utilitaire axparms effectue cette tâche. Sa page de man en donne une description exhaustive. À titre d'exemple :

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

Cette commande établit une entrée pour VK2XLZ via VK2SUT sur le port AX.25 nommé radio.

---