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.
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.
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.
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é :
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.
fixe le débit du port série.
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.
déclenche l'émission de messages à destination de syslog.
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
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
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
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
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.
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
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.
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]
# setcrystal -s 0x388 -i 10 -d 1
# 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).
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
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
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
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
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
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
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.
fournit deux type d'affichage : soit un écran de type oscilloscope, soit un visuel normal.
permet l'ajustement des niveaux audio de transmission et de réception.
sm0 :
# smdiag -i sm0 -e
sm0 :
# smmixer -i sm0
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
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.
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>
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>.
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.
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.
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
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.
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 :
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.
adresse du port de données pour le canal `A' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x300).
adresse du port de contrôle pour le canal `A' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x304).
adresse du port de données pour le canal `B' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x301).
adresse du port de contrôle pour le canal `B' du z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x305).
interruption (IRQ) utilisée par le SCC 8530. Un entier, 5 par exemple, est attendu.
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).
modèle de la munie du 8530 : <<====== ne manque-t-il pas un mot ?
carte SCC PA0HZP
carte Eagle
carte SCC PC100 DRSI
carte PRIMUS-PC (DG9BL)
carte (U)SCC BayCom
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).
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.
optionnel, donne l'adresse du registre spécial sur diverses cartes. Nul par défaut.
optionnel. Nul par défaut.
Quelques exemples de configuration des cartes les plus courantes :
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
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
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é.
en première position, spécifie le nom du périphérique
auquel le reste de la configuration s'applique (par exemple
/dev/scc0)
débit de l'interface en bits par seconde. Un nombre entier
est attendu (par exemple 1200)
origine de l'horloge de synchronisation des données. Les valeurs possibles sont :
fonctionnement normal monodirectionnel (half-duplex) ;
le modem dispose de sa propre horloge Rx/Tx ;
utilisation du diviseur bidirectionnel (si disponible).
type de codage des données. À choisir entre nrzi
et nrz
nombre de tampons de réception à allouer en mémoire. Un nombre entier est attendu (8 par exemple)
nombre de tampons d'émission à allouer en mémoire. Un nombre entier est attendu (8 par exemple )
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
délai d'attente de la transmission KISS. Un nombre entier de ms est attendu
paramètre persist (KISS). Argument de type entier
slot time (KISS). Argument de type entier en ms
the KISS transmit tail value. Argument entier en ms
indicateur de fonctionnement bidirectionnel (KISS), à
choisir entre 1 pour le bidirectionnel et 0 pour le
monodirectionnel
paramètre d'attente (KISS). Argument de type entier en ms
paramètre min (KISS). Argument de type entier en secondes
temps de keyup (?) maximal (KISS). Argument de type entier en secondes
délai d'attente sur inactivité (KISS). Argument de type entier en secondes
paramètre maxdef (KISS). Argument de type entier
paramètre group (KISS). Argument de type entier
valeur de txoff (KISS). Argument de type entier en ms
valeur de softdcd (KISS). Argument de type entier
indicateur slip (KISS). Argument de type entier
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
Afin de diagnostiquer les problèmes, sccstat affiche la configuration courante de n'importe quel périphérique SCC. Essayez :
# sccstat /dev/scc0
/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
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.
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
/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
nom affecté au port
identifiant AX.25
vitesse de communication avec le TNC
longueur de paquet maximale applicable au port pour les communications AX.25 en mode connecté
paramètre de fenêtre (K) AX.25. Il s'agit de la même
chose que le paramètre MAXFRAME de nombreux TNC.
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.
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
VK2XLZ via VK2SUT sur le
port AX.25 nommé radio.