AX25-HOWTO Version 1.3


Table des matières


 

11. Les pilotes de cartes Ottawa PI/PI2 et Gracilis PacketTwin

Les cartes Ottawa PI et Gracilis PacketTwin sont basées sur des Z8530 SCC pour des machines types IBM PC qui sont fréquement utilisées chez les opérateurs Radio Amateur dans le monde entier. La carte PI supporte un port à haute vitesse half duplex (un seul canal DMA), et un port à base vitesse half duplex (A base d'interruptions et à 9k6 bps). La PI2 est une nouvelle version de la carte qui supporte une platine modem radio et qui présente certaines améliorations matérielles. La carte PacketTwin supporte deux ports à haute vitesse et est capable de recevoir une platine modem.

Le pilote de la carte PI a été écrit par David Perry, <dp@hydra.carleton.edu> et celui de la PacketTwin par Craig Small VK2XLZ, <csmall@triode.apana.org.au>. Les deux pilotes sont livrés en standard à partir du noyau 1.3.xx.

Veuillez vous référer au chapitre consacré à l'AX.25 pour obtenir les détails relatifs au paramètrage des cartes PI et PacketTwin au sein du noyau.

Une fois que vous avez correctement configuré le pilote dans le noyau, alors redémarrez votre système. Vous devriez apercevoir à l'écran des messages relatifs aux cartes PI et PacketTwin au moment ou le noyau se charge. Les pilotes testent chacune des adresses d'entrée-sortie du port pour lequel la carte a été configuré et signalent leur présence ou leur absence. Jetez un coup d'oeil au fichier /proc/net/dev et vous devriez y voir des références aux unités appelées pi0a et pi0b ou pt0a et pt0b pour les cartes PI et PacketTwin.

Si les unites n'apparaissent pas alors reverifiez que vous avez correctement configuré et compilé votre noyau et que vous avez
effectivement démarré sur le nouveau noyau. Si cela ne marche toujours pas, alors votre carte PI ou PacketTwin n'a pas été détectée par le noyau au démarrage et il se peut que vous ayiez d'autres périphériques qui sont en conflit avec votre carte PI/PT et qui empêchent leur détection.

Si tout se passe correctement comme cela a été explicité au dessus, alors il vous faut maintenant configurer votre carte PI/PT avec une adresse AX.25 ainsi qu'une adresse IP. La configuration des cartes PI/PT est virtuellement identique à celle pratiquée sur n'importe quelle autre interface IP. Quelque chose ressemblant à ce qui suit devrait marcher sans problème chez vous:

# /usr/sbin/axparms -setcall pi0a VK2KTJ-2
# /sbin/ifconfig pi0a 44.136.8.5
# /sbin/ifconfig pi0a netmask 255.255.255.0
# /sbin/ifconfig pi0a broadcast 44.136.8.255
# /sbin/ifconfig pi0a arp mtu 256 up
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
# /sbin/route add default pi0a

Notez que pi0a fait référence au port 'a' de la première carte PI qui a été trouvée et que par conséquent pi0b fera référence au port 'b' sur la première carte PI. pt0a sera le premier port sur la première carte PacketTwin qui a été detectée.

Observez également l'utilisation de la commande axparms -setcall pour établir l'indicatif AX.25 sur le port.

Comme d'habitude, quand ceci a été fait, vous pouvez tester l'interface grâce aux commandes ping ou telnet pour être certain que cela marche.

Table des matières

12. Emulation KISS pour les cartes Z8530 SCC

Joerg Reuter, DL1BKE, jreuter@lykos.tng.oche.de a developpé un support générique pour les cartes basées sur le Z8530 SCC. Son pilote est suffisement configurable pour supporter un nombre important de type de cartes et présente une interface ressemblant à un TNC en mode KISS. Vous pouvez de cette manière le tester exactement comme s'il s'agissait d'un TNC en mode KISS.

Table des matières

12.1. Obtenir et construire la distribution des outils de configuration

Bien que le pilote soit inclu dans la distribution standard du noyau, Joerg distribue les versions les plus récentes de son pilote avec l'ensemble des outils de configuration dont vous allez également avoir besoin.

Vous pouvez obtenir la distribution des outils de configuration sur:

db0bm.automation.fh-aachen.de

/incoming/dl1bke/

ou:

insl1.etec.uni-karlsruhe.de

/pub/hamradio/linux/z8530/

ou:

ftp.ucsd.edu

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

Vous allez y trouver plusieurs versions, choisissez celle qui correspond le mieux au noyau que vous souhaitez utiliser.

z8530drv-2.4a.dl1bke.tar.gz 2.0.*
z8530drv-utils-3.0.tar.gz 2.1.6 ou plus récent

Les commandes suivantes étaient celles que j'utilisais pour compiler et installer la distribution du noyau 2.0.25:

# cd /usr/src
# gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
# cd z8530drv
# make clean
# make dep
# make module # Si vous voulez utiliser le pilote comme un module
# make for_kernel # Si vous voulez inclure le pilote dans le noyau.
# make install

Ceci terminé, vous devriez trois nouveaux programmes installés dans votre répertoire /sbin: gencfg, sccinit et sccstat. Ce sont ces programmes que vous allez utiliser pour configurer le pilote pour votre carte.

Vous allez également avoir un groupe de nouvelles unités créées dans votre /dev appele scc0 .. scc7. Ils seront utilisés plus tard exactement comme des unités 'KISS'.

Si vous choisissez de faire un 'make for_kernel', alors vous allez devoir recompiler votre noyau. Afin d'être sûr d'y incorporer le support du pilote z8530, soyez sûr de répondre 'Y' à la question 'Z8530 SCC kiss emulation driver for AX.25' durant la phase de configuration du noyau.

Si vous choisissez de faire un 'make module' alors le nouveau fichier scc.o devra être installé dans le bon répertoire /lib/modules et dans ce cas, il sera inutile de recompiler votre noyau. N'oubliez pas d'utiliser la commande insmod pour charger le module avant de l'utiliser et de le configurer.

Table des matières

12.2. Configurer le pilote pour votre carte

Le pilote z8530 SCC a été conçu pour être aussi flexible que possible de façon à ce qu'il puisse supporter autant de types de cartes que possible. Malheureusement cette souplesse a rendu la configuration plus compliquée.

Il y a une documentation plus élaborée dans la distribution et vous devriez la lire si vous avez le moindre problème. Cherchez particulièrement dans doc/scc_eng.doc ou doc/scc_ger.doc pour plus d'informations. J'ai paraphrasé les détails importants mais il y a beaucoup de petits détails que j'ai omis.

Le fichier principal de configuration est lu par le programme sccinit et il est appelé /etc/z8530drv.conf. Ce fichier est scindé en deux étapes principales: configuration des paramètres materiel et configuration des canaux. Une fois que vous avez configuré ce fichier, ajoutez simplement:

# sccinit

dans votre fichier rc qui configure votre réseau et le pilote va être initialisé grâce au contenu du fichier de configuration. Vous devez absolument faire ceci avant de tenter d'utiliser le pilote.

Table des matières

12.2.1. Configuration des paramètres matériels

Le premier chapitre est divisé en phrases, chaque phrase représente une puce 8530. Chaque phrase est une liste de mots clé avec des paramètres. Par défaut, vous pouvez spécifier jusqu'à quatre puces SCC dans le fichier. La directive #define MAXSCC 4 dans scc.c peut être augmentée si vous exprimez le besoin de gérer plus que quatre cartes.

Les mots clés et paramètres sont les suivants:

chip
le mot clé chip est utilisé pour séparer les phrases. Il ne prend pas en compte les éventuels paramètres présents.

data_a
ce mot clé est utilisé pour configurer l'adresse du port de donnée pour le canal 'A' du z8530. Le paramètre est un nombre hexadécimal, par exemple 0x300.

ctrl_a
ce mot clé est utilisé pour spécifier l'adresse du port de contrôle pour le canal 'A' du z8530. Le paramètre est un nombre hexadécimal, par exemple 0x304.

data_b
ce mot clé est utilisé pour spécifier l'adresse du port de donnée pour le canal 'B' du z8530. Le paramètre est un nombre hexadécimal, par exemple 0x301.

ctrl_b
ce mot clé est utilisé pour spécifier l'adresse du port de contrôle pour le canal 'B' du z8530. Le paramètre est un nombre hexadécimal, par exemple 0x305.

irq
ce mot clé est utilisé pour spécifier l'IRQ utilisée par le 8530 SCC décrit dans cette phrase. Le paramètre est un entier, par exemple 5.

pclock
ce mot clé est utilisé pour spécifier la fréquence d'horloge sur la broche PCLK du 8530. Le paramètre est une fréquence entière notée en Hz dont le défaut est 4915200 si le mot clé n'est pas fourni.

board
le type de platine supporte par le 8530 SCC. Le paramètre est une chaine de caractères. Les valeurs autorisées sont:

PA0HZP
la carte PA0HZP SCC

EAGLE
la carte Eagle

PC100
la carte DRSI PC100 SCC

PRIMUS
la carte PRIMUS-PC (DG9BL)

BAYCOM
la carte BayCom (U)SCC

escc
ce mot clé optionnel est utilisé pour permettre le support des puces SCC étendues (Extended SCC chips, ESCC) comme le 8580, 85180 ou le 85280. Le paramètre est une chaine de caractères avec 'yes' ou 'no' comme valeur possible. La valeur par défaut est 'no'.

vector
ce mot clé optionnel spécifie l'adresse du vecteur loquet (également connu comme "port intack") pour les cartes PA0HZP. Il ne peut y avoir qu'un seul vecteur loquet pour toutes les puces. Par défaut, cette valeur est à zéro.

special
ce mot clé optionnel spécifie l'adresse du registre de fonction spécial présent sur quelques cartes. Par défaut, il est à zéro.

option
ce mot clé est facultatif et par défaut à zéro.

Ci-dessous, quelques exemples de configuration pour les cartes les plus populaires:

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 avez déjà une configuration qui marche pour votre carte avec NOS, alors vous pouvez utiliser la commande gencfg pour convertir les commandes du pilote PE1CHL NOS en quelque chose de comprehensible par le fichier de configuration du pilote z8530.

Pour utiliser gencfg, invoquez le simplement avec les mêmes paramètres que vous utilisez avec le pilote PE1CHL dans NET/NOS. Par exemple:

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

va générer un squelette de configuration pour la carte OptoSCC.

Table des matières

12.2.2. Configuration des canaux

Le chapitre sur la configuration des canaux est l'endroit ou vous spécifiez tous les autres paramètres associés avec le port que vous configurez. Une fois encore le chapitre a été divisé en phrases. Une phrase représente un port logique, et par conséquent il doit y en avoir deux pour chacun des phrases de paramètre materiel puisque le 8530 SCC supporte deux ports.

Les mots clé et leur paramètres sont aussi écrits dans le fichier /etc/z8530drv.conf et doivent apparaitre aprés le chapitre des paramètres matériels.

L'agencement est trés important dans ce chapitre mais si vous vous en tenez à la séquence suggérée alors cela devrait marcher. Les mots clé et arguments sont les suivants:

device
ce mot clé doit être la premiere ligne de la définition du port, il spécifie le nom du fichier des unités spéciales qui s'appliquent au restant de la configuration, par exemple /dev/scc0

speed
ce mot clé spécifie la vitesse en bits par seconde de l'interface. Le paramètre est un entier: par exemple, 1200.

clock
ce mot clé spécifie l'origine de l'horloge pour les données. Les valeurs possibles sont:

dpll
opération normale en halfduplex.

external
le modem fournit sa propre horloge Rx/Tx

divider
utilise le diviseur fullduplex si installé.

mode
ce mot clé spécifie le type de codage de données à utiliser. Les paramètres autorisés sont: nrzi ou nr.

rxbuffers
ce mot clé spécifie le nombre de buffers en reception afin d'allouer la mémoire. Le paramètre est un entier, par exemple 8.

txbuffers
ce mot clé spécifie le nombre de buffers en émission afin d'allouer la mémoire. Le paramètre est un entier, par exemple 8.

bufsize
ce mot clé spécifie la taille des buffers de reception et d'émission. Le paramètre est en octet et il représente la longueur totale de la trame, il doit également prendre en compte les entêtes AX.25 et pas seulement la longueur du champ d'information. Ce mot clé est optionnel et est fixé par défaut a 384.

txdelay
la valeur du délai de transmission KISS, le paramètre est un entier en mS.

persist
la valeur de persistance KISS, le paramètre est un entier.

slot
la valeur du temps d'ouverture KISS, le paramètre est un entier en mS.

tail
la valeur de la queue de transmission KISS, le paramètre est un entier en mS.

fulldup
le drapeau de full duplex KISS, le paramètre est un entier.
1==Full Duplex, 0==Half Duplex.

wait
la valeur d'attente KISS, le paramètre est un entier en mS.

min
la valeur minute KISS, le paramètre est un entier en S.

maxkey
la valeur maximale keyup, le paramètre est un entier en S.

idle
la valeur du timer idle KISS, le paramètre est un entier en S.

maxdef
la valeur maxdef KISS, le paramètre est un entier.

group
la valeur de groupe, le paramètre est un entier.

txoff
la valeur txoff, le paramètre est un entier en mS.

softdcd
la valeur softdcd, le paramètre est un entier.

slip
le drapeau slip, le paramètre est un entier.

Table des matières

12.3. Utiliser le pilote

Pour utiliser le pilote, il suffit de considérer les unités /dev/scc* comme une simple unité série tty connectée sur le TNC en mode KISS. Par exemple, pour configurer les composantes réseau de façon à ce que la carte SCC fonctionne avec le noyau Linux, vous allez utiliser quelque chose comme:

# axattach -s 4800 /dev/scc0 VK2KTJ

Vous pouvez également utiliser NOS pour l'accrocher au noyau de la même manière. Par exemple, sous JNOS, tapez ceci:

attach asy scc0 0 ax25 scc0 256 256 4800

Table des matières

12.4. Les outils sccstat et sccparam

Pour vous aider dans la résolution des problèmes, vous pouvez utiliser le programme sccstat pour afficher la configuration courante de l'unité SCC. Essayez ceci:

# sccstat /dev/scc0

vous allez alors voir défiler une large quantité d'informations en rapport à la configuration et au status du port SCC /dev/ssc0. La commande sccparam vous autorise à changer et à modifier une configuration une fois que vous avez démarré votre système. Sa syntaxe est fort similaire à la commande param sous NOS. Par exemple, pour fixer le paramètre txtail d'une unité à 100 mS, vous utiliserez:

# sccparam /dev/scc0 txtail 0x8

Table des matières

 13. Configurer une interface pour un modem Baycom

Thomas Sailer, <sailer@ife.ee.ethz.ch>, malgré son intime conviction que cela ne marcherait jamais correctement, a développé un support Linux pour les modems Baycom. Son pilote supporte le port série Ser12, ainsi que les modems sur les ports parallèles, le Par96 et le modèle évolué Par97. D'autres informations complémentaires sur les modems peuvent être obtenues sur le site Web Baycom: <http://www.baycom.de>.

Lorsque le pilote marche, il se comporte exactement comme une interface KISS, donc considérez le comme n'importe quel pilote PI, PacketTwin ou SCC.

Table des matières

 13.1. Compiler le noyau

Le pilote n'est disponible que sous la forme d'un module, donc il faut que vous ayiez installé le support module dans votre noyau, et également selectionn" les options appropriées afin de supporter le pilote Baycom durant l'étape du make config lors de la compilation du noyau.

Les options significatives pour lesquelles vous devez repondre 'y' sont les suivantes:

Prompt for development and/or incomplete code/drivers [Y/n]
Radio network interfaces (CONFIG_NET_RADIO) [N/y/?]
BAYCOM ser12 and par96 kiss emulation driver for AX.25 (CONFIG_BAYCOM) [N/y/m/?]

Table des matières

 13.2. Compiler l'utilitaire setbaycom

Un utilitaire de configuration est disponible sur la home page de Thomas Sailer <http://www.ife.ee.ethz.ch/~sailer/ham/baycom.tar.gz>.

L'utilitaire setbaycom vous autorise à configurer plusieurs unités Baycom. Si vous projettez de le faire alors il vous faudra l'obtenir et l'installer.

Pour la compilation et l'installation, procédez de la façon suivante:

# cd /usr/src
# tar xvfz baycom.tar.gz
# cd baycom
# make
# make install

Table des matières

13.3. Créer les fichiers d'unités /dev

Le pilote Baycom utilise des fichiers spéciaux d'unités dans le répertoire /dev. Vous devez les créer manuellement. Les commandes suivantes devraient marcher correctement:

# mknod /dev/bc0 c 51 0
# mknod /dev/bc1 c 51 1
# mknod /dev/bc2 c 51 2
# mknod /dev/bc3 c 51 3

Vous les utiliserez plus tard. Si vous avez installé l'utilitaire setbaycom alors ceci sera fait pour vous.

Table des matières

13.4. Charger le module

Lorsque la compilation du noyau est terminée et une fois que vous avez installé le module baycom.o où vous les mettez d'habitude (Normalement, ils sont stockés dans /lib/modules/2.0.0/), vous pouvez démarrer le module. Celui-ci prend les paramètres de configuration depuis la commande en ligne insmod; vous devez donc le démarrer manuellement depuis un fichier rc, ou si vous utilisez le programme kerneld, vous devez le configurer avec les bons paramètres de telle manière à ce qu'ils soient bien transmis durant le chargement du module.

Si vous utilisez le kerneld, vous devriez ajouter la ligne suivante à votre fichier /etc/conf.modules:

alias char-major-51 baycom

Il y a quatre objets principaux à spécifier au moment du chargement du module, il s'agit de:

modem
le type de modem baycom que vous configurez.

1. modem de type Ser12.

2. modem de type Par96 ou Par97.

iobase
l'adresse d'entrée-sortie du port série ou parallèle que vous utiliserez.

0x3f8
COM1:

0x2f8
COM2:

0x378
LPT1:

0x278
LPT2:

irq
l'interruption (IRQ) que votre port utilisera.

4 COM1:

3 COM2:

7 LPT1:

5 LPT2:

options
quelques options spécifiques à baycom.

0 utilise un signal matériel DCD.

1 utilise un signal logiciel DCD.

Table des matières

13.5. Un petit piège à éviter

Parce que le pilote Baycom utilise les ports série et parallèle de vos machines, et parce qu'il s'agit d'un pilote à bas niveau, il est en concurrence avec les pilotes série et parallèle qui existent déjà dans le noyau. Il y a plusieurs façons de contourner ce problème. La première manière est d'être certain que vous chargez d'abord le module Baycom, de façon à ce qu'il prenne en premier les ressources matérielles dont il a besoin avant que les modules pilotant les ports série et parallèle ne se les accaparent. Avec le pilote série, vous disposez du luxe de le déconnecter au moyen de la commande setserial, ceci sera démontré dans les exemples. Si vous utilisez les modems branchés sur le port parallèle, méfiez vous des deux modules lp.o (Line Printer) et plip.o (Parallel Line IP).

Table des matières

13.6. Quelques exemples de configurations

Ces exemples sont pour les deux configurations les plus courantes.

Déconnectez le pilote série pour COM1: puis configurer le pilote Baycom pour un modem sur port série Ser12 sur COM1: avec l'option DCD enclenchée.

# setserial /dev/ttyS0 uart none
# insmod baycom modem=1 iobase=0x3f8 irq=4 options=1

Modem de type port parallèle Par96 sur LPT1 avec l'option DCD materielle:

# insmod baycom modem=2 iobase=0x378 irq=7 options=0

La première unité créée est /dev/bc0, la seconde est /dev/bc1, etc...

Table des matières

13.7. Configurer des unités multiples

Avec le programme insmod et ses paramètres, vous ne pouvez configurer qu'un seul modem Baycom. L'utilitaire setbaycom vous autorise à configurer plusieurs unités Baycom.

Les paramètres nécessaires sont identiques à ceux que vous fournissez au module exactement comme si vous ne configuriez qu'une seule unité. Par exemple, pour configurer les deux unités présentées ci-dessous, vous utiliserez les commandes suivantes:

# setbaycom -i /dev/bc0 -p ser12 0x3f8 4 1
# setbaycom -i /dev/bc1 -p par96 0x378 7 0

Table des matières

13.8. Utilisation des unités

Le pilote de l'unité lorsqu'il est chargé se comporte comme un pilote série tty attaché à un TNC en mode KISS. Ceci signifie que la configuration du logiciel AX.25 pour ce pilote est identique à la configuration du TNC en mode KISS présentée auparavant. Vous devez utiliser le programme axattach et ajouter le port à votre fichier /etc/ax25/axports. La seule différence est que vous utiliserez désormais /dev/bc0 au lieu de /dev/ttyS0.

Table des matières