<!doctype linuxdoc system>
<!-- Linux AX.25-HOWTO. Description de l'installation et de la configuration
du support réseau AX.25 sous Linux. Pour tout commentaire ou retour
d'expérience, contactez l'auteur à terry@perf.no.itg.telstra.com.au.
-->
<article>
<title> Linux AX.25-HOWTO, Amateur Radio.
<author>Terry Dawson, VK2KTJ, <tt>terry@perf.no.itg.telstra.com.au</tt>,
traduit par François Romieu, <url url="romieu@ensta.fr">
<date>v1.5, 17 Octobre 1997
<abstract>
Le système d'exploitation Linux est sûrement le seul au monde à pouvoir se
vanter d'offrir un support natif du protocole de transmission de données AX.25
employé par les radioamateurs à travers le monde. Le présent document se veut
un guide d'installation et de configuration de cette prise en charge.
</abstract>
<!-- Table of contents -->
<toc>
<!-- Begin the document -->
<sect><heading> Introduction.
<p>Le document trouve son origine dans une annexe du HAM-HOWTO.
L'importance de
son développement devint cependant incompatible avec une telle organisation.
L'installation et la prise en charge intégrée d'AX.25, la gestion NetRom et
Rose sous Linux sont décrites. Quelques exemples de configurations typiques
fournissent une base de travail.
<p>
La mise en oeuvre des protocoles radioamateurs sous Linux est très souple.
Les personnes peu familières du système d'exploitation Linux trouveront
peut-être la configuration un peu obscure. Il vous faudra un certain temps
pour maîtriser l'interaction des différents éléments. Attendez-vous à une
configuration pénible si vous ne vous êtes pas auparavant familiarisé avec
Linux. N'espérez pas passer à Linux depuis un autre environnement en
faisant l'économie de tout apprentissage.
<sect1><heading> Modifications par rapport à la version précédente
<p>
<verb>
Ajouts:
Page ouaibe de Joerg Reuters
Section "Informations supplémentaires"
configuration d'ax25ipd.
Corrections/Mises à jour:
Prévention des conflits dus aux pty
Nouvelles versions du module et des ax25-utils
A faire:
Mettre au point la section SCC qui est sûrement erronée
Étoffer la section touchant à la programmation
</verb>
<sect1><heading> Nouvelles versions du document
<p>
Les archives du Projet de Documentation Linux (LDP ou Linux Documentation
Project) constituent le meilleur emplacement où trouver la dernière mouture
de ce texte. Le LDP tient à jour un site ouaibe dans lequel figure l'AX.25
HOWTO :
<url url="http://sunsite.unc.edu/LDP/HOWTO/AX.25-HOWTO.html"
name="AX.25-HOWTO">.
Le texte est disponible sous différents formats à l'adresse suivante :
<url url="ftp://sunsite.unc.edu/pub/Linux/docs/howto/"
name="archive ftp sunsite.unc.edu">.
La version française est accessible via :
<url url="ftp://ftp.traduc.org/pub/HOWTO/FR"
name="archive Traduc.org">.
<p>
Vous pouvez me contacter mais comme je transmets directement les nouvelles
versions au coordinateur LDP des HOWTO, l'absence d'une nouvelle version
indique sûrement que je ne l'ai pas terminée.
<sect1><heading> Autres documents
<p>
La documentation sur les sujets apparentés ne manque pas. Bon nombre de textes
traitent de l'utilisation générale de Linux en réseau et je vous conseille
vivement de les lire : ils vous guideront dans vos efforts et offrent une
vision élargie à d'autres configurations envisageables.
Par exemple :
<url url="http://sunsite.unc.edu/LDP/HOWTO/HAM-HOWTO.html"
name="HAM-HOWTO">,
<url url="http://sunsite.unc.edu/LDP/HOWTO/NET-3-HOWTO.html"
name="NET-3-HOWTO">,
<url url="http://sunsite.unc.edu/LDP/HOWTO/Ethernet-HOWTO.html"
name="Ethernet-HOWTO">,
et :
<url url="http://sunsite.unc.edu/LDP/HOWTO/Firewall-HOWTO.html"
name="le Firewall-HOWTO">
<p>
Des informations plus générales sur Linux sont disponibles :
<url url="http://sunsite.unc.edu/LDP/HOWTO/" name="Linux HOWTO">
<sect><heading> Les protocoles de paquets par radio et Linux
<p>
Le protocole <em>AX.25</em> fonctionne aussi bien en mode connecté que
non-connecté et s'emploie tel quel pour des liaisons point-à-point ou
pour encapsuler d'autres protocoles tels qu'IP ou NetRom.
<p>
Sa structure se rapproche de celle du niveau 2 d'X25 avec des extensions
qui l'adaptent à l'environnement radioamateur.
<p>
Le protocole NetRom a pour objectif de fournir un protocole réseau complet.
Il repose sur AX.25 au niveau liaison de données et procure une couche
réseau dérivée d'AX.25. Le protocole NetRom autorise le routage dynamique
et la création d'alias pour les noeuds.
<p>
Le protocole Rose a été initialement conçu et réalisé par Tom Moulton alias
W2VY. Il constitue une mise en oeuvre du protocole par paquets X25 et
peut inter-opérer avec AX.25 au niveau liaison. Il fournit des services
de couche réseau. Les adresses Roses comportent 10 digits. Les quatre
premiers constituent le code d'identification du réseau de données
(DNIC ou Data Network Identification Code) et sont référencés dans
l'Appendice B de la recommandation X121 du CCITT. Des informations
supplémentaires sur le protocole Rose sont disponibles sur le site suivant :
<url url="http://www.rats.org/" name="Serveur Web RATS">.
<p>
Alan Cox a créé les toutes premières versions de support noyau pour AX.25.
Jonathon Naylor <tt><g4klx@g4klx.demon.co.uk></tt> a poursuivi le
développement, ajouté la gestion de NetRom et de Rose et assure à présent
officiellement la maintenance du code noyau relatif à AX.25. La prise en
compte de DAMA est l'oeuvre de Joerg, DL1BKE, <tt/jreuter@poboxes.com/.
Thomas Sailer, <tt><sailer@ife.ee.ethz.ch></tt> s'est chargé des
matériels Baycom et SoundModem. J'assure pour ma part le suivi des
utilitaires AX.25.
<p>
Linux gère les TNC (Terminal Node Controllers) KISS, les cartes Ottawa PI,
les PacketTwin Gracilis et autres cartes à base de SCC Z8530 via le pilote
SCC générique ainsi que les modems sur ports série et parallèle de Baycom.
Le nouveau pilote pour modems à base de carte son de Thomas accepte les
Soundblaster et les cartes à base de composants Crystal.
<p>
Le paquetage de programmes applicatifs comprend une messagerie individuelle
(PMS ou Personal Message System), une balise, un programme de connexion en
mode texte, un exemple de récupération des trames AX.25 au niveau de
l'interface et des utilitaires de configuration du protocole NetRom.
Il comprend également un serveur de type AX.25 qui gère les demandes de
connexions AX.25 et un démon qui se charge de l'essentiel du travail pour
le protocole NetRom.
<sect1><heading> Fonctionnement
<p>
La mise en oeuvre d'AX.25 sous Linux lui est propre de A à Z. Bien qu'elle
puisse ressembler à NOS, à BPQ ou à d'autres versions d'AX.25 sur certains
points, elle ne se confond avec aucune d'entre elles. La version Linux
peut être configurée pour se comporter de façon voisine aux autres mais
le processus n'en reste pas moins radicalement différent.
<p>
Pour vous aider à comprendre la démarche intellectuelle à suivre lors de
la configuration, cette section décrit les fonctionnalités structurelles
d'AX.25 et son adaptation au contexte Linux.
<bf><em> Diagramme simplifié des couches protocolaires </em></bf>
<tscreen><verb>
+----------+-----------+-------------+---------+
| AF_AX.25 | AF_NETROM | AF_INET | AF_ROSE |
+==========+===========+=============+=========+
| | | | |
| | | TCP/IP | |
| | +--------+ | |
| | NetRom | | Rose |
| +--------------------+----+---------+
| AX.25 |
+----------------------------------------------+
</verb></tscreen>
Le diagramme précédent illustre simplement le fait que Rose, NetRom, AX.25 et
TCP/IP reposent tous sur AX.25 mais que chacun est traité comme un protocole
différent au niveau de l'interface de programmation. Les noms
`<tt>AF_</tt>' correspondent aux noms donnés aux `<em>Familles
d'Adresses</em>' de chacun du point de vue du programmeur. On notera ici
l'obligation de configurer la pile AX.25 avant toute configuration des
protocoles NetRom, Rose ou TCP/IP.
<bf><em> Diagramme des modules logiciels de la pile réseau de Linux </em></bf>
<verb>
---------------+-----------+-----------------------++----------+---------------
Utilisateur |Programmes | call node || Démons | ax25d mheardd
| | pms mheard || | inetd netromd
---------------+-----------+-----------------------++----------+---------------
|Sockets | open(), close(), listen(), read(), write(), connect()
| +----------------------+-------------------+----------
| | AF_AX.25 | AF_NETROM | AF_ROSE | AF_INET
+-----------+--------------+-------+-----+-------------+----------
Noyau |Protocoles | AX.25 | NetRom | Rose | IP/TCP/UDP
+-----------+--------------+-------------+-------------+----------
|Périph. | ax0,ax1 | nr0,nr1 | rose0,rose1 | eth0,ppp0
+-----------+--------------+-------------+-------------+----------
|Pilotes | Kiss PI2 PacketTwin SCC BPQ | slip ppp
| | modems type son Baycom | ethernet
---------------+-----------+------------------------------------------+-----
Matériel | Cartes PI2, PacketTwin, SCC, Série, Ethernet
----------------------------------------------------------------------------
</verb>
Ce diagramme est plus général que le précédent. Il montre les relations entre
les applications, le noyau et le matériel ainsi qu'entre l'interface de
programmation des sockets, les modules de protocoles, les périphériques
réseau et leurs pilotes. Chaque niveau dépend de celui sur lequel il repose et,
de façon générale, la configuration doit se faire de bas en haut. Par exemple,
si vous souhaitez exécuter le programme <em>call</em>, vous devez configurer
le matériel, vérifier que le pilote adéquat est inclus dans le noyau, créer les
périphériques noyaux correspondants et inclure le protocole requis par
le programme <em>call</em>. J'ai essayé d'organiser le présent document de
cette façon.
<sect><heading> Composants logiciels de la suite AX.25/NetRom/Rose
<p>
Le paquetage AX.25 comprend trois volets : les sources du noyau, les outils de
configuration réseau et les applications utilisateur.
Les version 2.0.xx des noyaux Linux incluent les gestionnaires AX.25, NetRom,
SCC Z8530, PacketTwin et ceux des cartes PI. Les noyaux 2.1.* les améliorent
substantiellement. L'emploi d'un noyau 2.1.* dans un système de production est
vivement déconseillé. Pour y remédier, Jonathon Naylor propose un ensemble de
patches pour mettre à niveau la gestion du protocole radio amateur dans un
noyau 2.0.28. L'application des patches est très simple et apporte une palette
de fonctionnalités autrement absentes du noyau tel le support Rose.
L'emploi d'un noyau 2.2.x est également envisageable.
<sect1><heading> Récupération du noyau, des outils et utilitaires
<p>
<sect2><heading> Sources du noyau
<p>
Les sources du noyau sont disponibles via le réseau de miroirs de
ftp.kernel.org :
<bf>ftp.xx.kernel.org</bf>
où xx désigne un code pays tel fr, uk, de, us, etc...
Les différentes version du noyau se trouvent en :
<tscreen><verb>
/pub/linux/kernel/
</verb></tscreen>
Version courante de mise à jour d'AX.25 :
<bf>ftp.pspt.fi</bf>
<tscreen<verb>
/pub/linux/ham/ax25/ax25-module-14e.tar.gz
</verb></tscreen>
<sect2><heading> Les outils réseau
<p>
Dernière version alpha des outils réseau standard pour Linux gérant AX.25 et
NetRom :
<bf>ftp.inka.de</bf>
<tscreen><verb>
/pub/comp/Linux/networking/net-tools/net-tools-1.33.tar.gz
</verb></tscreen>
<p>
Paquetage ipfwadm :
<bf>ftp.xos.nl</bf>
<tscreen><verb>
/pub/linux/ipfwadm/
</verb></tscreen>
En 2.2.x, le paquetage <em>ipchains</em> remplace ipfwadm devenu obsolète.
<sect2><heading> Les utilitaires AX.25
<p>
Il existe deux familles distinctes d'outils AX.25. L'une dédiée aux noyaux
<tt>2.0.*</tt> et l'autre destinée aussi bien aux version <tt>2.1.*</tt>
qu'aux noyaux <tt>2.0.*</tt> patchés. Le numéro de version de ax25-utils
indique la version du noyau la plus ancienne à partir de laquelle les outils
fonctionneront. A vous de choisir une version des ax25-utils appropriée.
Les combinaisons suivantes fonctionnent, <bf> utilisez les </bf>.
<tscreen><verb>
Noyau Linux Utilitaires AX.25
---------------------- -------------------------
linux-2.0.29 ax25-utils-2.0.12c.tar.gz **
linux-2.0.28+module12 ax25-utils-2.1.22b.tar.gz **
linux-2.0.30+module14c ax25-utils-2.1.42a.tar.gz
linux-2.0.31+module14d ax25-utils-2.1.42a.tar.gz
linux-2.1.22 ++ ax25-utils-2.1.22b.tar.gz
linux-2.1.42 ++ ax25-utils-2.1.42a.tar.gz
</verb></tscreen>
<bf>Note</bf>: les versions <tt>ax25-utils-2.0.*</tt> identifiées ci-dessus avec
le symbole '<tt>**</tt>' sont à présent obsolètes. Le document couvre l'emploi
des logiciels conseillés dans les tables. Bien que les paquetages diffèrent, la
plus grande partie des informations reste valable pour les versions suivantes.
Utilitaires AX.25 :
<url url="ftp://ftp.pspt.fi/pub/linux/ham/ax25/" name="ftp.pspt.fi">
ou :
<url url="ftp://sunsite.unc.edu/pub/Linux/apps/ham/" name="sunsite.unc.edu">
<sect><heading> Installation des logiciels AX.25/NetRom/Rose
<p>
Une mise en oeuvre correcte d'AX.25 dans votre système Linux nécessite
l'installation et la configuration d'un noyau approprié ainsi que
des utilitaires AX.25.
<sect1><heading> Compilation du noyau
<p>
Si vous êtes un habitué de la compilation du noyau Linux, contentez-vous de
vérifier que vous avez activé les options adéquates et sautez cette section.
Si ce n'est pas le cas, lisez ce qui suit.
<p>
En principe, les sources du noyau sont décompactées au niveau du répertoire
<tt>/usr/src</tt> dans un sous-répertoire nommé <tt>linux</tt>. Pour ce faire,
prenez l'identité du super-utilisateur <tt>root</tt> et exécutez les
commandes ci-dessous :
<tscreen><verb>
# mv linux linux.old
# cd /usr/src
# tar xvfz linux-2.0.31.tar.gz
# tar xvfz /pub/net/ax25/ax25-module-14e.tar.gz
# patch -p0 &etago;usr/src/ax25-module-14/ax25-2.0.31-2.1.47-2.diff
# cd linux
</verb></tscreen>
Une fois les sources du noyau décompactées et la mise à jour appliquée,
lancez le script de configuration et activez les options qui correspondent
à la configuration matérielle dont vous souhaitez disposer. Vous
utiliserez la commande :
<tscreen><verb>
# make menuconfig
</verb></tscreen>
Si vous êtes bête^H^H^H^Hcourageux, vous pouvez essayer
<tscreen><verb>
# make config
</verb></tscreen>
Les claviophobes se serviront de :
<tscreen><verb>
# make xconfig
</verb></tscreen>
Je vais décrire la méthode plein-écran (menuconfig) dont j'apprécie la
facilité de déplacement mais vous êtes libre d'en utiliser une autre.
Dans tous les cas, vous devrez choisir parmi une série d'options auxquelles il
faudra répondre par `Y' ou `N' (voire `M' si vous avez recours aux modules, ce
sur quoi je fais l'impasse pour simplifier).
Options importantes pour la configuration d'AX.25 :
<verb>
Code maturity level options --->
...
[*] Prompt for development and/or incomplete code/drivers
...
General setup --->
...
[*] Networking support
...
Networking options --->
...
[*] TCP/IP networking
[?] IP: forwarding/gatewaying
...
[?] IP: tunneling
...
[?] IP: Allow large windows (not recommended if <16Mb of memory)
...
[*] Amateur Radio AX.25 Level 2
[?] Amateur Radio NET/ROM
[?] Amateur Radio X.25 PLP (Rose)
...
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[?] BAYCOM ser12 and par96 driver for AX.25
[?] Soundcard modem driver for AX.25
[?] Soundmodem support for Soundblaster and compatible cards
[?] Soundmodem support for WSS and Crystal cards
[?] Soundmodem support for 1200 baud AFSK modulation
[?] Soundmodem support for 4800 baud HAPN-1 modulation
[?] Soundmodem support for 9600 baud FSK G3RUH modulation
[?] Serial port KISS driver for AX.25
[?] BPQ Ethernet driver for AX.25
[?] Gracilis PackeTwin support for AX.25
[?] Ottawa PI and PI/2 support for AX.25
[?] Z8530 SCC KISS emulation driver for AX.25
...
</verb>
Vous <bf/devez/ répondre `Y' aux options marquées d'un <tt/*/'. Le reste
dépend de votre configuration matérielle et d'options laissées à votre choix.
Certaines de ces options sont décrites un peu plus loin. Si vous ne voyez pas
ce dont il retourne, continuez la lecture et revenez à cette section
ultérieurement.
<p>
Une fois la configuration du noyau achevée, vous devriez pouvoir compiler
proprement un nouveau noyau :
<tscreen><verb>
# make dep
# make clean
# make zImage
</verb></tscreen>
Déplacez ensuite le fichier <tt>arch/i386/boot/zImage</tt> et éditez le
fichier <tt>/etc/lilo.conf</tt> en conséquence avant de relancer <em>lilo</em>
pour être sûr que vous démarrerez bien sur le bon noyau.
<p>
<sect2> Un mot sur les modules
<p>
Je vous recommande de ne <bf>pas</bf> compiler quelque pilote que ce soit en
tant que module. Dans presque toutes les installations, vous n'y gagnez rien
sinon une complexité accrue. De nombreuses personnes ont des problèmes avec
les modules, non par la faute du code, mais parce que les modules sont plus
compliqués à installer et à configurer.
[NdT:manifestement nous ne faisons pas le même arbitrage complexité/souplesse]
<p>
Si vous avez choisi de compiler certains composants en tant que modules, vous
devrez également utiliser :
<tscreen><verb>
# make modules
# make modules_install
</verb></tscreen>
afin d'installer vos modules à l'emplacement adéquat.
<p>
Certains ajouts au fichier <tt>/etc/conf.modules</tt> sont nécessaires afin
que <em/kerneld/ sache gérer l'interface d'accès aux fonctions modularisées.
Les entrées suivantes doivent être présentes :
<tscreen><verb>
alias net-pf-3 ax25
alias net-pf-6 netrom
alias net-pf-11 rose
alias tty-ldisc-1 slip
alias tty-ldisc-3 ppp
alias tty-ldisc-5 mkiss
alias bc0 baycom
alias nr0 netrom
alias pi0a pi2
alias pt0a pt
alias scc0 optoscc (or one of the other scc drivers)
alias sm0 soundmodem
alias tunl0 newtunnel
alias char-major-4 serial
alias char-major-5 serial
alias char-major-6 lp
</verb></tscreen>
<tscreen><verb>
# modprobe -c
</verb></tscreen>
vous renverra la configuration courante.
<sect2> Qu'y a-t-il de nouveau dans les noyaux 2.0.x patchés et les 2.1.y ?
<p>
Les noyaux <tt/2.1.*/ présentent des améliorations au niveau de quasiment tous
les pilotes et protocoles. Citons les plus significatives :
<descrip>
<tag>Modularisation</tag> tous les protocoles et gestionnaires ont été
modularisés de façon à être gérés via <em/insmod/ et <em/rmmod/. La mémoire
demandée par le noyau diminue dans le cas de modules employés par
intermittence. Le développement et la mise au point des gestionnaires
devient également plus facile. Cela étant, la configuration devient
légèrement plus compliquée.
<tag>Uniformisation des pilotes</tag> l'accès aux périphériques tels
les Baycom, SCC, PI, PacketTwin et autres a maintenant lieu via une
interface réseau usuelle semblable à celle du gestionnaire ethernet. Ils
n'apparaissent désormais plus comme des TNC KISS. L'utilitaire
<em/net2kiss/ permet de créer une interface KISS pour ces périphériques
si on le souhaite.
<tag>bugs</tag> il y a eu de nombreuses corrections et des fonctionnalités
ont été ajoutées tel le protocole Rose.
</descrip>
<sect1><heading> Les outils de configuration du réseau
<p>
A présent que le noyau est compilé, vous devez faire de même avec les nouveaux
outils de configuration du réseau. Ces outils permettent de modifier la
configuration des périphériques réseau et des tables de routage.
<p>
Le nouveau paquetage alpha des <tt>net-tools</tt> standard gère AX.25 et
NetRom. Je l'ai essayé et il semble fonctionner correctement chez moi.
<sect2><heading> Patch correctif incluant la gestion Rose
<p>
Le paquetage standard net-tools-1.33.tar.gz comporte certains bugs qui
affectent AX.25 et NetRom. J'ai produit un correctif qui supporte aussi
Rose.
<p>
Le patch est disponible à l'adresse suivante :
<url url="ftp://zone.pspt.fi/pub/linux/ham/ax25/net-tools-1.33.rose.tjd.diff.gz"
name="zone.pspt.fi">.
<sect2><heading> Compilation des net-tools standard
<p>
Lisez le fichier <tt>Release</tt> et suivez les indications qui y sont données.
Je suis passé par les étapes ci-dessous :
<tscreen><verb>
# cd /usr/src
# tar xvfz net-tools-1.33.tar.gz
# zcat net-tools-1.33.rose.tjd.diff.gz | patch -p0
# cd net-tools-1.33
# make config
</verb></tscreen>
Arrivés à ce point, vous devrez répondre à une série de questions de
configuration d'une façon similaire à ce qui se fait pour le noyau.
N'oubliez pas d'inclure tous les protocoles et gestionnaires de périphériques
dont vous souhaitez vous servir ultérieurement. Dans le doute, répondez par
l'affirmative (``Y'').
<p>
Une fois la compilation effectuée :
<tscreen><verb>
# make install
</verb></tscreen>
installera les programmes à leur place définitive.
<p>
Pour disposer des fonctionnalités de type pare-feu IP (firewall), vous
aurez besoin des derniers outils d'administration <tt>ipfwadm</tt>.
Ils remplacent <tt>ipfw</tt> qui ne fonctionne à présent plus.
<p>
Pour la compilation d'<tt>ipfwadm</tt> :
<tscreen><verb>
# cd /usr/src
# tar xvfz ipfwadm-2.0beta2.tar.gz
# cd ipfwadm-2.0beta2
# make install
# cp ipfwadm.8 /usr/man/man8
# cp ipfw.4 /usr/man/man4
</verb></tscreen>
<sect1><heading> Utilitaires et applications AX.25
<p>
Une fois les étapes de compilation et de redémarrage du noyau menées
à leur terme avec succès, il vous reste à compiler les applications AX.25.
Les commandes devraient ressembler à ce qui suit :
<tscreen><verb>
# cd /usr/src
# tax xvfz ax25-utils-2.1.42a.tar.gz
# cd ax25-utils-2.1.42a
# make config
# make
# make install
</verb></tscreen>
Les fichiers sont installés par défaut dans les sous-répertoires <tt/bin/,
<tt/sbin/, <tt/etc/ et <tt/man/ du répertoire <tt>/usr</tt>.
<p>
S'il s'agit de la première installation des utilitaires AX.25 sur votre
système, vous devrez installer quelques fichiers de configuration type dans
le répertoire <tt>/etc/ax25/</tt> via :
<tscreen><verb>
# make installconf
</verb></tscreen>
<p>
En cas de messages du type :
<verb>
gcc -Wall -Wstrict-prototypes -O2 -I../lib -c call.c
call.c: In function `statline':
call.c:268: warning: implicit declaration of function `attron'
call.c:268: `A_REVERSE' undeclared (first use this function)
call.c:268: (Each undeclared identifier is reported only once
call.c:268: for each function it appears in.)
</verb>
vérifiez encore une fois que les <em>ncurses</em> sont correctement
installées. Le script de configuration tente de localiser
les ncurses à certains emplacements usuels mais sur des installations
faisant n'importe quoi avec les ncurses, le script échoue à cette étape.
<sect><heading> Numéros d'identification, adresses et préliminaires divers
<p>
Chaque port AX.25 et NetRom sur votre système doit se voir allouer un
numéro d'identification (callsign/ssid). Il se configure dans les fichiers
dont il va être à présent question.
<p>
Certaines mises en oeuvre d'AX.25 telles NOS et BPQ permettent l'emploi d'un
ssid commun sur un même port AX.25 et NetRom. Pour des raisons techniques
assez compliquées, Linux l'interdit. En pratique, ça ne s'avère pas un
problème aussi important qu'on pourrait le croire.
<p>
Cela signifie que vous devez garder présents à l'esprit certains éléments
lorsque vous configurez votre système.
<p>
<enum>
<item> Chaque port AX.25 et NetRom doit disposer d'un ssid unique.
<item> TCP/IP utilise le ssid du port AX.25 par lequel il émet ou reçoit
(celui dont il est question juste au-dessus).
<item> NetRom emploie le ssid spécifié dans son fichier de configuration mais
seulement lorsqu'il dialogue avec un autre NetRom. Il ne s'agit <bf/pas/
du ssid que les clients AX.25 de votre noeud NetRom vont employer.
Davantage de détails sur ce point tout à l'heure.
<item> Rose utilise par défaut le ssid du port AX.25 à moins qu'on ne lui en
spécifie explicitement un autre grâce à la commande `<em/rsparms/' qui
forcera le même ssid sur <bf/tous/ les ports.
<item> Les autres programmes tels `<em/ax25d/' écoutent via un ssid
quelconque qui n'est soumis à aucune contrainte d'unicité entre ports
différents.
<item> Si le routage est fait avec attention, vous pouvez affecter la même
adresse IP à tous les ports.
</enum>
<sect1><heading> Que sont les T1, T2, N2 ?
<p>
Toutes les piles AX.25 ne sont pas de type TNC2. La nomenclature Linux
diffère sur certains points de celle du monde des TNC. Le tableau ci-dessous
vous aidera à établir les correspondances entre les différents concepts.
<tscreen><verb>
-------+----------+------------------------------------------------
Linux | TAPR TNC | Description
-------+----------+------------------------------------------------
T1 | FRACK | Temps d'attente avant retransmission d'une
| | trame privée d'accusé de réception.
-------+----------+------------------------------------------------
T2 | RESPTIME | Temps minimum d'attente entre trames avant
| | émission d'un acquittement.
-------+----------+------------------------------------------------
T3 | CHECK | Périodicité d'émission d'un paquet de
| | vérification de l'état de la connexion.
-------+----------+------------------------------------------------
N2 | RETRY | Nombre de tentatives de retransmission avant
| | de signaler un échec.
-------+----------+------------------------------------------------
Idle | | Durée d'inactivité d'une connexion avant sa
| | fermeture.
-------+----------+------------------------------------------------
Window | MAXFRAME | Nombre maximal de trames transmises sans
| | acquittement.
-------+----------+------------------------------------------------
</verb></tscreen>
<sect1><heading> Paramètres configurables dynamiquement
<p>
Les noyaux <tt/2.1.*/ et <tt/2.0.* +moduleXX/ permettent la modification
à la volée de paramètres auparavant statiques. Un examen attentif de la
structure du répertoire <tt>/proc/sys/net/</tt> révèle de nombreux fichiers
dont les noms correspondent à ceux de paramètres réseau.
Les fichiers dans le répertoire <tt>/proc/sys/net/ax25/</tt> représentent
chacun un port AX.25 configuré. Le nom du fichier reflète celui du port.
La structure des fichiers dans <tt>/proc/sys/net/ax25/<portname>/</tt> est
la suivante :
<verb>
Fichier Signification Valeur Défaut
ip_default_mode Mode IP par défaut 0=DG 1=VC 0
ax25_default_mode Mode AX.25 par défaut 0=normal 1=étendu 0
backoff_type Backoff 0=Linéaire 1=exponentiel 1
connect_mode Mode connecté 0=non 1=oui 1
standard_window_size Fenètre standard 1 <= N <= 7 2
extended_window_size Fenètre étendue 1 <= N <= 63 32
t1_timeout Délai maximal T1 1s <= N <= 30s 10s
t2_timeout Délai maximal T2 1s <= N <= 20s 3s
t3_timeout Délai maximal T3 0s <= N <= 3600s 300s
idle_timeout Attente d'inactivité 0m <= N 20m
maximum_retry_count N2 1 <= N <= 31 10
maximum_packet_length Trame AX.25 1 <= N <= 512 256
</verb>
T1, T2, T3 sont donnés en secondes tandis que la durée d'inactivité est en
minutes. Notez que les valeurs employées dans l'interface sysctl s'expriment
dans une unité interne multiple par 10 du temps en secondes. La résolution
atteint donc le dixième de seconde. Dans le cas d'une alarme qui peut être
nulle, c'est à dire pour T3 et pour la durée d'inactivité, une valeur nulle
équivaut à une désactivation.
<p>
La structure des fichiers dans <tt>/proc/sys/net/netrom/</tt> est la suivante :
<verb>
Fichier Valeur par défaut
default_path_quality 10
link_fails_count 2
network_ttl_initialiser 16
obsolescence_count_initialiser 6
routing_control 1
transport_acknowledge_delay 50
transport_busy_delay 1800
transport_maximum_tries 3
transport_requested_window_size 4
transport_timeout 1200
</verb>
<p>
La structure des fichiers dans <tt>/proc/sys/net/rose/</tt> est la suivante :
<verb>
Fichier Valeur par défaut
acknowledge_hold_back_timeout 50
call_request_timeout 2000
clear_request_timeout 1800
link_fail_timeout 1200
maximum_virtual_circuits 50
reset_request_timeout 1800
restart_request_timeout 1800
routing_control 1
window_size 3
</verb>
<p>
Le positionnement d'un paramètre se fait simplement en l'écrivant dans le
fichier. Par exemple, pour vérifier puis modifier la taille de fenêtre Rose,
vous pourriez exécuter :
<tscreen><verb>
# cat /proc/sys/net/rose/window_size
3
# echo 4 >/proc/sys/net/rose/window_size
# cat /proc/sys/net/rose/window_size
4
</verb></tscreen>
<sect><heading> Configuration d'un port AX.25
<p>
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 <tt>/etc/ax25/axport</tt>. Chaque
port dont vous souhaitez vous servir doit être répertorié dans ce fichier.
<sect1><heading> Création des périphériques AX.25
<p>
Le périphérique réseau correspond à ce qui apparaît lorsque vous entrez la
commande `<em/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.
<p>
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.
<p>
Chacun de ces pilotes crée un périphérique lors de son invocation.
<sect2><heading> Création des périphériques KISS
<p>
<bf/Options de configuration du noyau/ :
<tscreen><verb>
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Serial port KISS driver for AX.25
</verb></tscreen>
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 <em>minicom</em> ou <em>seyon</em> vous
permettra de configurer le TNC en kiss.
<p>
Servez-vous du programme <em/kissattach/ pour créer les périphériques KISS.
Par exemple :
<tscreen><verb>
# /usr/sbin/kissattach /dev/ttyS0 radio
# kissparms -p radio -t 100 -s 100 -r 25
</verb></tscreen>
Les périphériques KISS se retrouvent sous la dénomination `<tt/ax[0-9]/'.
Au premier appel de <em/kissattach/, `<tt/ax0/' est créé ; au second,
`<tt/ax1/', etc ... Chaque périphérique KISS est associé à un port série.
<p>
<em/kissparms/ permet de positionner divers paramètres sur un périphérique
KISS.
<p>
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 `<tt>/dev/ttyS0</tt>' et le port `<tt/radio/'
du fichier <tt>/etc/ax25/axports</tt>. Il positionne ensuite <em/txdelay/ et
<em/slottime/ à 100 ms et <em/ppersist/ à 25.
<p>
Reportez vous aux pages de <em/man/ pour davantage d'informations.
<sect3><heading> Configuration des TNC Dual Port
<p>
L'utilitaire <em/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 <em/avant/ toute autre configuration
AX.25. Les périphériques que vous configurerez correspondent à des pseudo-TTY
(<tt>/dev/ttyq*</tt>) 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 (`<tt>/dev/ptyq*</tt>') et une esclave
(`<tt>/dev/ttyq*</tt>'). Les extrémités sont en relation telles que si
<tt>/dev/ptyq0</tt> est l'extrémité maître d'un tuyau, alors
<tt>/dev/ttyq0</tt> est son extrémité esclave. Le côté maître doit être
ouvert avant le côté esclave. <em/mkiss/ divise un périphérique série grâce
à ce mécanisme.
<p>
Par exemple, pour un TNC double-port connecté au port série
<tt>/dev/ttyS0</tt> en 9600 bps, les commandes suivantes créeront deux
pseudo-tty qui se comporteront comme des ports séries munis de TNC usuels :
<tscreen><verb>
# /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
# /usr/sbin/kissattach /dev/ttyq0 port1
# /usr/sbin/kissattach /dev/ttyq1 port2
</verb></tscreen>
<tt>/dev/ttyq0</tt> et <tt>/dev/ttyq1</tt> se manipulent ensuite avec
<em/kissattach/ comme décrit précédemment dans l'exemple relatif à
<tt/port1/ et <tt/port2/. N'utilisez pas directement <em/kissattach/ sur
le port série car <em/mkiss/ y accède.
<p>
<em/mkiss/ accepte de nombreux arguments optionnels. En voici un résumé :
<descrip>
<tag>-c</tag> 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.
<tag>-s <speed></tag> fixe le débit du port série.
<tag>-h</tag> 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.
<tag>-l</tag> déclenche l'émission de messages à destination de <em/syslog/.
</descrip>
<sect2><heading> Création d'un périphérique Baycom
<p>
<bf/Options de compilation du noyau/ :
<tscreen><verb>
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] BAYCOM ser12 and par96 driver for AX.25
</verb></tscreen>
Malgré l'opinion suivant laquelle les modems Baycom ne fonctionneraient pas
très bien sous Linux, Thomas Sailer(<tt><sailer@ife.ee.ethz.ch></tt>) en
a développé le gestionnaire. Son pilote gère les ports série <tt>Ser12</tt> et
<tt>Par96</tt> ainsi que les modems parallèles <tt>PicPar</tt>.
Vous trouverez davantage d'informations concernant les modems à l'adresse :
<url url="http://www.baycom.de/" name="Baycom Web site">.
<p>
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).
<p>
Les périphériques BayCom se retrouvent sous la dénomination <tt/bc0/,
<tt/bc1/, <tt/bc2/ etc...
<p>
L'utilitaire <em/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 <em/insmod/.
<p>
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 :
<tscreen><verb>
# setserial /dev/ttyS0 uart none
# insmod hdlcdrv
# insmod baycom mode="ser12*" iobase=0x3f8 irq=4
</verb></tscreen>
Un modem parallèle de type Par96 sur le port LPT1: utilisant la détection
DCD matérielle :
<tscreen><verb>
# insmod hdlcdrv
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0
</verb></tscreen>
Ce n'est pas la meilleure façon de faire. L'utilitaire <em/sethdlc/
fonctionne également avec plusieurs périphériques.
<p>
La page de <em/man/ d'<em/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 :
<tscreen><verb>
# insmod hdlcdrv
# insmod baycom
</verb></tscreen>
Vous pouvez également avoir incorporé le gestionnaire en dur dans le noyau.
<p>
Configuration de <tt/bc0/ pour un modem parallèle BayCom sur LPT1 avec
détection DCD logicielle :
<tscreen><verb>
# sethdlc -p -i bc0 mode par96 io 0x378 irq 7
</verb></tscreen>
Configuration de <tt/bc1/ pour un modem série sur COM1 :
<tscreen><verb>
# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
</verb></tscreen>
<sect2><heading> Configuration des paramètres d'accès au canal AX.25
<p>
Ces paramètres équivalent à ppersist, txdelay et slottime pour KISS. Ici
aussi, vous utiliserez <em/sethdlc/.
<p>
La page de man relative à <em/sethdlc/ reste la source d'informations la
plus complète mais un ou deux autres exemples ne feront pas de mal.
<p>
Configuration de <tt/bc0/ avec TxDelay égal à 200 ms, SlotTime à 100 ms,
PPersist à 40, en half duplex :
<tscreen><verb>
# sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
</verb></tscreen>
Notez que les paramètres de durée sont donnés en millisecondes.
<sect3><heading> Configuration d'AX.25 avec le pilote BayCom
<p>
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.
<p>
Tout d'abord il faut donner un numéro d'identification AX.25 au périphérique.
<em/ifconfig/ le fait très bien :
<tscreen><verb>
# /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
</verb></tscreen>
La commande précédente affecte l'identité AX.25 <tt/VK2KTJ-15/ au
périphérique <tt/bc0/. Vous disposez également de <em/axparms/ mais vous
aurez de toute façon besoin d'<em/ifconfig/ pour activer le périphérique :
<tscreen><verb>
# ifconfig bc0 up
# axparms -setcall bc0 vk2ktj-15
</verb></tscreen>
<p>
L'étape suivante consiste à ajouter une entrée dans le fichier
<tt>/etc/ax25/axports</tt> comme vous le feriez pour tout autre périphérique.
Les données du fichier <tt/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.
<p>
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.
<sect2><heading> Création d'un périphérique modem-son
<p>
<bf/Options de compilation du noyau/ :
<tscreen><verb>
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Soundcard modem driver for AX.25
[?] Soundmodem support for Soundblaster and compatible cards
[?] Soundmodem support for WSS and Crystal cards
[?] Soundmodem support for 1200 baud AFSK modulation
[?] Soundmodem support for 4800 baud HAPN-1 modulation
[?] Soundmodem support for 9600 baud FSK G3RUH modulation
</verb></tscreen>
Thomas Sailer 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.
<p>
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 :
<url url="http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html"
name="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.
<p>
Les périphériques modem-son se retrouvent sous la dénomination <tt/sm0/,
<tt/sm1/, <tt/sm2/, etc...
<p>
<bf>Remarque</bf>: 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.
<sect3><heading> Configuration de la carte son
<p>
Le pilote SoundModem n'initialise pas la carte réseau. Le paquetage ax25-utils
comprend l'utilitaire `<em/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 :
<tscreen><verb>
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]
</verb></tscreen>
Par exemple, pour une carte SoundBlaster à l'adresse 0x388 employant
l'interruption 10 et la canal DMA 1, vous entreriez :
<tscreen><verb>
# setcrystal -s 0x388 -i 10 -d 1
</verb></tscreen>
Pour une carte WindowSoundSystem à l'adresse 0x534 employant l'interruption 5
et la canal DMA 3 :
<tscreen><verb>
# setcrystal -w 0x534 -i 5 -d 3
</verb></tscreen>
Le paramètre <tt/[-f synthio]/ correspond à l'adresse du synthétiseur. Le
paramètre <tt/[-c dma2]/ détermine le second canal DMA pour un fonctionnement
simultané dans les deux sens (full-duplex).
<sect3><heading> Configuration des périphériques modem-son
<p>
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.
<p>
L'utilitaire <em/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.
<p>
Par exemple, avec une seule carte de type SoundBlaster configurée comme
ci-dessus, émulant un modem 1200 bps :
<tscreen><verb>
# insmod hdlcdrv
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
</verb></tscreen>
Ce n'est pas la meilleure façon de faire. L'utilitaire <em/sethdlc/
fonctionne également avec plusieurs périphériques.
<p>
La page de <em/man/ d'<em/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 :
<tscreen><verb>
# insmod hdlcdrv
# insmod soundmodem
</verb></tscreen>
Vous pouvez également avoir incorporé le gestionnaire en dur dans le noyau.
<p>
Configuration du pilote pour émuler un modem G3RUH 9600 sur le périphérique
<tt/sm0/ avec la carte WindowsSoundSystem précédente et le port parallèle en
0x378 pour alimenter l'émetteur :
<tscreen><verb>
# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
</verb></tscreen>
Configuration du pilote pour émuler un modem HAPN 4800 sur le périphérique
<tt/sm1/ avec la carte SoundBlaster précédente et le port série en
0x2f8 pour alimenter l'émetteur :
<tscreen><verb>
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
</verb></tscreen>
Configuration du pilote pour émuler un modem AFS 1200 sur le périphérique
<tt/sm1/ avec la carte SoundBlaster précédente et le port série en
0x2f8 pour alimenter l'émetteur :
<tscreen><verb>
# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
</verb></tscreen>
<sect3><heading> Configuration des paramètres d'accès au canal AX.25
<p>
Ces paramètres équivalent à ppersist, txdelay et slottime pour KISS. Ici
aussi, vous utiliserez <em/sethdlc/.
<p>
La page de man relative à <em/sethdlc/ reste la source d'informations la
plus complète mais un ou deux autres exemples ne feront toujours pas de mal.
<p>
Configuration de <tt/sm0/ avec TxDelay égal à 100 ms, SlotTime à 50 ms,
PPersist à 128 en full duplex :
<tscreen><verb>
# sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full
</verb></tscreen>
Notez que les paramètres de durée sont donnés en millisecondes.
<sect3><heading> Choix du volume et ajustement du pilote
<p>
Il est <em/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 :
<em/smdiag/ et <em/smmixer/.
<p>
<descrip>
<tag><em/smdiag/</tag> fournit deux type d'affichage : soit un écran de type
oscilloscope, soit un visuel normal.
<tag><em/smmixer/</tag> permet l'ajustement des niveaux audio de
transmission et de réception.
</descrip>
<em/smdiag/ en mode 'visuel' avec un périphérique SoundModem en <tt/sm0/ :
<tscreen><verb>
# smdiag -i sm0 -e
</verb></tscreen>
<em/smmixer/ avec un périphérique SoundModem en <tt/sm0/ :
<tscreen><verb>
# smmixer -i sm0
</verb></tscreen>
<sect3><heading> Configuration d'AX.25 avec le pilote SoundModem
<p>
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.
<p>Tout d'abord il faut donner un numéro d'identification AX.25 au
périphérique. <em/ifconfig/ le fait très bien :
<tscreen><verb>
# /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 up
</verb></tscreen>
La commande précédente affecte l'identité AX.25 <tt/VK2KTJ-15/ au périphérique
<tt/sm0/. Vous disposez également de <em/axparms/ mais vous aurez de toute
façon besoin d'<em/ifconfig/ pour activer le périphérique :
<tscreen><verb>
# ifconfig sm0 up
# axparms -setcall sm0 vk2ktj-15
</verb></tscreen>
<p>
L'étape suivante consiste à ajouter une entrée dans le fichier
<tt>/etc/ax25/axports</tt> comme vous le feriez pour tout autre périphérique.
Les données du fichier <tt/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.
<p>
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.
<sect2><heading> Création d'un périphérique à base de carte PI
<p>
<bf/Options de compilation du noyau/ :
<tscreen><verb>
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Ottawa PI and PI/2 support for AX.25
</verb></tscreen>
Les périphériques PI se retrouvent sous la dénomination `<tt/pi[0-9][ab]/'
où la première carte détectée se verra allouer `<tt/pi0/', la seconde
`<tt/pi1/', etc... `<tt/a/' et `<tt/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 :
<tscreen><verb>
# /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
</verb></tscreen>
La commande précédente affecte l'identité AX.25 <tt/VK2KTJ-15/ au premier port
de la carte PI et l'active. Pour utiliser le périphérique, il vous reste à
ajouter au fichier <tt>/etc/ax25/axports</tt> l'entrée correspondant à son
identité AX.25.
<p>
Le gestionnaire de cartes PI a été écrit par :
<tt>David Perry, <dp@hydra.carleton.edu></tt>
<sect2><heading> Création d'un périphérique PacketTwin
<p>
<bf/Options de compilation du noyau/ :
<tscreen><verb>
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Gracilis PackeTwin support for AX.25
</verb></tscreen>
Les périphériques PacketTwin se retrouvent sous la dénomination
`<tt/pt[0-9][ab]/' où la première carte détectée se verra allouer `<tt/pt0/',
la seconde `<tt/pt1/', etc. `<tt/a/' et `<tt/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 :
<tscreen><verb>
# /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
</verb></tscreen>
La commande précédente affecte l'identité AX.25 <tt/VK2KTJ-15/ au premier port
de la carte PacketTwin et l'active. Pour utiliser le périphérique, il vous
reste à ajouter au fichier <tt>/etc/ax25/axports</tt> l'entrée correspondant
à son identité AX.25.
<p>
Le gestionnaire de cartes PacketTwin a été écrit par :
<tt>Craig Small VK2XLZ, <csmall@triode.apana.org.au></tt>.
<sect2><heading> Création d'un périphérique SCC générique
<p>
<bf/Options de compilation du noyau/ :
<tscreen><verb>
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] Z8530 SCC KISS emulation driver for AX.25
</verb></tscreen>
Joerg Reuter, DL1BKE, <tt/jreuter@poboxes.com/ 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.
<sect3><heading> Récupération et compilation des outils de configuration
<p>
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.
<p>
Vous trouverez le paquetage des outils de configuration à une des adresses
suivantes :
<url name="Joerg's web page" url="http://www.rat.de/jr/">
<bf>db0bm.automation.fh-aachen.de</bf>
<tscreen><verb>
/incoming/dl1bke/
</verb></tscreen>
<bf>insl1.etec.uni-karlsruhe.de</bf>
<tscreen><verb>
/pub/hamradio/linux/z8530/
</verb></tscreen>
<bf>ftp.ucsd.edu</bf>
<tscreen><verb>
/hamradio/packet/tcpip/linux
/hamradio/packet/tcpip/incoming/
</verb></tscreen>
<p>
Différentes versions s'offrent à vous. Choisissez la plus adaptée à votre
noyau :
<verb>
z8530drv-2.4a.dl1bke.tar.gz 2.0.*
z8530drv-utils-3.0.tar.gz 2.1.6 et au delà
</verb>
<p>
Voici les commandes que j'ai employées lors de la compilation et de
l'installation du paquetage pour mon noyau 2.0.30 :
<tscreen><verb>
# 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
</verb></tscreen>
<p>
Au terme de ces opérations, trois nouveaux exécutables devraient s'être
installés dans votre répertoire <tt>/sbin</tt> : <em>gencfg</em>,
<em>sccinit</em> et <em>sccstat</em>. Ces programmes vont vous servir à
configurer le pilote pour votre carte.
<p>
De nouveaux périphériques apparaîtront également dans votre répertoire
<tt>/dev</tt> sous les noms <tt>scc0</tt>-<tt>scc7</tt>. Ils joueront plus
tard le rôle de périphériques KISS que vous pourrez employer.
<p>
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 `<tt>Y</tt>' à :
`<tt>Z8530 SCC kiss emulation driver for AX.25</tt>' durant le
`<tt>make config</tt>'.
<p>
Si vous avez choisi 'make module', le module <tt/scc.o/ sera installé
dans le sous-répertoire adéquat de <tt>/lib/modules</tt> et il ne vous sera
pas nécessaire de recompiler tout le noyau. N'oubliez pas d'exécuter un
<em/insmod/ afin de charger le module avant d'essayer de le configurer.
<sect3><heading> Configurer le pilote pour sa carte
<p>
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.
<p>
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 à <tt>doc/scc_eng.doc</tt>
et à <tt>doc/scc_ger.doc</tt>. J'ai repris les points les plus
importants mais de nombreux détails sont passés sous silence.
<p>
Le fichier de configuration principal, lu par le programme <em>sccinit</em>,
se trouve en <tt>/etc/z8530drv.conf</tt>. 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 :
<tscreen><verb>
# sccinit
</verb></tscreen>
au fichier <tt>rc</tt> 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.
<sect4><heading> Configuration des paramètres matériels
<p>
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 <tt>#define MAXSCC 4</tt> dans le
fichier <tt>scc.c</tt>.
<p>
Liste des mots-clefs et des arguments :
<descrip>
<tag>chip</tag> le terme <tt>chip</tt> sert à séparer les strophes. Il ne
nécessite pas d'arguments et ceux-ci sont de toute façon ignorés.
<tag>data_a</tag> adresse du port de données pour le canal `A' du
z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x300).
<tag>ctrl_a</tag> adresse du port de contrôle pour le canal `A' du
z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x304).
<tag>data_b</tag> adresse du port de données pour le canal `B' du
z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x301).
<tag>ctrl_b</tag> adresse du port de contrôle pour le canal `B' du
z8530. Un nombre hexadécimal est attendu en argument (par exemple 0x305).
<tag>irq</tag> interruption (IRQ) utilisée par le SCC 8530. Un entier, 5 par
exemple, est attendu.
<tag>pclock</tag> 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).
<tag>board</tag> modèle de la munie du 8530 : <<====== ne manque-t-il pas un mot ?
<descrip>
<tag>PA0HZP</tag> carte SCC PA0HZP
<tag>EAGLE</tag> carte Eagle
<tag>PC100</tag> carte SCC PC100 DRSI
<tag>PRIMUS</tag> carte PRIMUS-PC (DG9BL)
<tag>BAYCOM</tag> carte (U)SCC BayCom
</descrip>
<tag>escc</tag> 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).
<tag>vector</tag> 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.
<tag>special</tag> optionnel, donne l'adresse du registre spécial
sur diverses cartes. Nul par défaut.
<tag>option</tag> optionnel. Nul par défaut.
</descrip>
Quelques exemples de configuration des cartes les plus courantes :
<descrip>
<tag>BayCom USCC</tag><tscreen>
<verb>
chip 1
data_a 0x300
ctrl_a 0x304
data_b 0x301
ctrl_b 0x305
irq 5
board BAYCOM
#
# SCC chip 2
#
chip 2
data_a 0x302
ctrl_a 0x306
data_b 0x303
ctrl_b 0x307
board BAYCOM
</verb></tscreen>
<tag>PA0HZP SCC card</tag><tscreen>
<verb>
chip 1
data_a 0x153
data_b 0x151
ctrl_a 0x152
ctrl_b 0x150
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
#
#
#
chip 2
data_a 0x157
data_b 0x155
ctrl_a 0x156
ctrl_b 0x154
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
</verb></tscreen>
<tag>DRSI SCC card</tag><tscreen>
<verb>
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
</verb></tscreen>
</descrip>
Si vous disposez déjà d'une configuration qui fonctionne avec votre carte
sous NOS, la commande <em>gencfg</em> permet de convertir les commandes
du pilote NOS PE1CHL en quelque chose d'utilisable pour le pilote z8530.
<p>
<em>gencfg</em> 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 :
<tscreen><verb>
# gencfg 2 0x150 4 2 0 1 0x168 9 4915200
</verb></tscreen>
<sect3><heading> Configuration du canal
<p>
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.
<p>
Les mots-clefs et leurs arguments s'inscrivent également dans le fichier
<tt>/etc/z8530drv.conf</tt>, <bf>à la suite</bf> de la section des paramètres
matériels.
<p>
L'ordre est très important dans cette section mais tout devrait marcher même
si vous vous écartez de celui proposé.
<descrip>
<tag> device </tag> en première position, spécifie le nom du périphérique
auquel le reste de la configuration s'applique (par exemple
<tt>/dev/scc0</tt>)
<tag> speed </tag> débit de l'interface en bits par seconde. Un nombre entier
est attendu (par exemple <tt>1200</tt>)
<tag> clock </tag> origine de l'horloge de synchronisation des données. Les
valeurs possibles sont :
<descrip>
<tag> dpll </tag> fonctionnement normal monodirectionnel
(half-duplex) ;
<tag> external </tag> le modem dispose de sa propre horloge Rx/Tx ;
<tag> divider </tag> utilisation du diviseur bidirectionnel (si
disponible).
</descrip>
<tag> mode </tag> type de codage des données. À choisir entre <tt>nrzi</tt>
et <tt>nrz</tt>
<tag> rxbuffers </tag> nombre de tampons de réception à allouer en mémoire.
Un nombre entier est attendu (8 par exemple)
<tag> txbuffers </tag> nombre de tampons d'émission à allouer en mémoire. Un
nombre entier est attendu (8 par exemple )
<tag> bufsize </tag> 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 <tt>384</tt>
<tag> txdelay </tag> délai d'attente de la transmission KISS. Un nombre
entier de ms est attendu
<tag> persist </tag> paramètre persist (KISS). Argument de type entier
<tag> slot </tag> slot time (KISS). Argument de type entier en ms
<tag> tail </tag> the KISS transmit tail value. Argument entier en ms
<tag> fulldup </tag> indicateur de fonctionnement bidirectionnel (KISS), à
choisir entre <tt>1</tt> pour le bidirectionnel et <tt>0</tt> pour le
monodirectionnel
<tag> wait </tag> paramètre d'attente (KISS). Argument de type entier en ms
<tag> min </tag> paramètre min (KISS). Argument de type entier en secondes
<tag> maxkey </tag> temps de keyup (?) maximal (KISS). Argument de type entier
en secondes
<tag> idle </tag> délai d'attente sur inactivité (KISS). Argument de type
entier en secondes
<tag> maxdef </tag> paramètre maxdef (KISS). Argument de type entier
<tag> group </tag> paramètre group (KISS). Argument de type entier
<tag> txoff </tag> valeur de txoff (KISS). Argument de type entier en ms
<tag> softdcd </tag> valeur de softdcd (KISS). Argument de type entier
<tag> slip </tag> indicateur slip (KISS). Argument de type entier
</descrip>
<sect3><heading> Utilisation du pilote
<p>
Il suffit d'employer les périphériques <tt>/dev/scc*</tt> 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 :
<tscreen><verb>
# kissattach -s 4800 /dev/scc0 VK2KTJ
</verb></tscreen>
NOS permet également d'attacher le périphérique de la même façon. Avec JNOS,
vous entreriez une commande du style :
<tscreen><verb>
attach asy scc0 0 ax25 scc0 256 256 4800
</verb></tscreen>
<sect3><heading>Les outils <em>sccstat</em> et <em>sccparam</em>
<p>
Afin de diagnostiquer les problèmes, <em>sccstat</em> affiche la
configuration courante de n'importe quel périphérique SCC. Essayez :
<tscreen><verb>
# sccstat /dev/scc0
</verb></tscreen>
Vous devriez récupérer une quantité impressionnante d'informations touchant
à la configuration et à l'état du port SCC <tt>/dev/scc0</tt>.
<p>
<em>sccparam</em> sert à modifier la configuration après l'initialisation du
noyau. La syntaxe est similaire à celle de la commande <tt>param</tt> de NOS.
Pour positionner <tt>txtail</tt> à 100 ms sur un port :
<tscreen><verb>
# sccparam /dev/scc0 txtail 0x8
</verb></tscreen>
<sect2><heading> Création d'un périphérique BPQ
<p>
<bf/Options de configuration du noyau/ :
<tscreen><verb>
General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] BPQ Ethernet driver for AX.25
</verb></tscreen>
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.
<p>
Les périphériques BPQ se retrouvent sous la dénomination `<tt/bpq[0-9]/'.
`<tt/bpq0/' est associé à `<tt/eth0/', `<tt/bpq1/' à `<tt/eth1/' etc.
<p>
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 à :
<url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO">.
<p>
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 :
<tscreen><verb>
# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
</verb></tscreen>
Vérifiez bien que l'identifiant correspond à celui qui figure dans le fichier
<tt>/etc/ax25/axports</tt> pour ce port.
<sect2><heading> Configuration d'un noeud BPQ pour le dialogue avec la couche AX.25 de Linux
<p>
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 :
<tscreen><verb>
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
</verb></tscreen>
<sect1><heading> Mise au point du fichier <tt>/etc/ax25/axports</tt>
<p>
<tt>/etc/ax25/axports</tt> est un fichier texte standard que vous créerez avec
n'importe quel éditeur. Son format est le suivant :
<tscreen><verb>
portname callsign baudrate paclen window description
</verb></tscreen>
avec :
<descrip>
<tag> portname </tag> nom affecté au port
<tag> callsign </tag> identifiant AX.25
<tag> baudrate </tag> vitesse de communication avec le TNC
<tag> paclen </tag> longueur de paquet maximale applicable au port pour les
communications AX.25 en mode connecté
<tag> window </tag> paramètre de fenêtre (K) AX.25. Il s'agit de la même
chose que le paramètre <tt> MAXFRAME </tt> de nombreux TNC.
<tag> description </tag> champ de commentaire
</descrip>
Chez moi, le fichier ressemble à ça :
<tscreen><verb>
radio VK2KTJ-15 4800 256 2 4800bps 144.800 MHz
ether VK2KTJ-14 10000000 256 2 BPQ/ethernet device
</verb></tscreen>
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.
<sect1><heading> Routage AX.25
<p>
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 <em/axparms/ effectue cette tâche. Sa page de
<em/man/ en donne une description exhaustive. À titre d'exemple :
<tscreen><verb>
# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
</verb></tscreen>
Cette commande établit une entrée pour <tt/VK2XLZ/ via <tt/VK2SUT/ sur le
port AX.25 nommé <tt/radio/.
<sect><heading> TCP/IP et l'interface AX.25
<p>
Si vous disposez d'interfaces KISS, deux méthodes s'offrent à vous pour
configurer une adresse IP : soit la commande <em>kissattach</em>, soit le
recours conventionnel à <em/ifconfig/.
<p>
Modifiant l'exemple KISS précédent de façon à créer une interface AX.25 avec
une adresse IP égale à <tt>44.136.8.5</tt> et un <tt>MTU</tt> de <tt>512</tt>
octets :
<tscreen><verb>
# /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0
# /sbin/route add default ax0
</verb></tscreen>
Au besoin, vous emploierez <em>ifconfig</em> pour configurer les autres
paramètres.
<p>
Si vous disposez d'autre interfaces, utilisez <em>ifconfig</em> pour
configurer l'adresse IP et le masque de réseau du port et ajoutez une route
vers le port comme vous le feriez avec n'importe quelle autre interface IP.
L'exemple suivant s'appuie sur une carte PI mais fonctionnerait de façon
similaire avec un périphérique AX.25 quelconque :
<tscreen><verb>
# /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up
# /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
# /sbin/route add default pi0a
</verb></tscreen>
Les commandes précédentes correspondent à une configuration familière aux
utilisateurs de NOS et de ses variantes ou de toute autre logiciel IP.
Notez que la route par défaut n'est pas nécessaire si un autre périphérique
réseau la met lui-même en place.
<p>
Pour tester votre configuration, lancez un ping ou un telnet vers votre
machine :
<tscreen><verb>
# ping -i 5 44.136.8.58
</verb></tscreen>
L'argument `<tt>-i 5</tt>' force <em>ping</em> à envoyer ses requêtes ICMP
toutes les 5 secondes et non chaque seconde.
<sect><heading> Configuration d'un port NetRom
<p>
Le protocole NetRom s'appuye sur les ports AX.25 que vous créerez. Sa
configuration s'effectue par l'intermédiaire de deux fichiers. L'un décrit
les interfaces NetRom et l'autre les ports AX.25 sous-jacents. La procédure
détaillée ci-dessous s'appliquera à toutes les interfaces NetRom que vous
souhaiterez définir.
<sect1><heading> Le fichier <tt>/etc/ax25/nrports</tt>
<p>
Ce fichier est l'analogue pour les ports NetRom du fichier
<tt>/etc/ax25/axports</tt> pour les ports AX.25. Tous les périphériques
NetRom que vous souhaitez employer doivent figurer dans le fichier
<tt>/etc/ax25/nrports</tt>. Le plus souvent, une station Linux ne comprendra
qu'un seul port NetRom qui utilisera certains des périphériques AX.25. Pour
certains services tels un BBS, le besoin de définir plusieurs alias NetRom
peut se manifester ; on ajoute alors des périphériques NetRom en conséquence.
<p>
Le format du fichier est le suivant :
<tscreen><verb>
name callsign alias paclen description
</verb></tscreen>
Avec :
<descrip>
<tag> name </tag> nom affecté au port.
<tag> callsign </tag> identifiant pour le trafic NetRom transitant par ce
port. Attention, il ne s'agit <bf/pas/ de l'adresse à laquelle les clients
doivent se connecter pour disposer d'une interface de type <em/noeud/
(ce mode sera décrit un peu plus loin). L'identifiant doit être unique et
ne réapparaître nulle part dans les fichiers <tt>/etc/ax25/axports</tt> et
<tt>/etc/ax25/nrports</tt>.
<tag> alias </tag> alias NetRom du port.
<tag> paclen </tag> taille maximale des trames NetRom transmises par le port.
<tag> description </tag> commentaire.
</descrip>
Par exemple, pour créer un port NetRom connu du reste du réseau NetRom
sous l'identité `<tt/LINUX:VK2KTJ-9/' :
<tscreen><verb>
netrom VK2KTJ-9 LINUX 236 Linux Switch Port
</verb></tscreen>
Des programmes tels <em/call/ se servent du fichier <tt>nrports</tt>.
<sect1><heading> Le fichier <tt>/etc/ax25/nrbroadcast</tt>
<p>
Ce second fichier peut contenir une nombre d'entrées variable, normalement
une pour chaque port AX.25 convoyant du trafic NetRom.
<p>
Le format du fichier est le suivant :
<tscreen><verb>
axport min_obs def_qual worst_qual verbose
</verb></tscreen>
Avec :
<descrip>
<tag> axport </tag> nom du port tiré du fichier <tt>/etc/ax25/axports</tt>.
En l'absence d'entrée dans le fichier <tt>/etc/ax25/nrbroadcasts</tt> pour
un port AX.25, aucun routage NetRom n'aura lieu via ce port et toute
diffusion NetRom sera ignorée.
<tag> min_obs </tag> paramètre d'obsolescence minimale du port.
<tag> def_qual </tag> qualité par défaut.
<tag> worst_qual </tag> qualité minimale admissible. Toute route de
qualité moindre sera ignorée.
<tag> verbose </tag> activation de la diffusion des informations de
routage globales ou seulement relatives au noeud.
</descrip>
Par exemple :
<tscreen><verb>
radio 1 200 100 1
</verb></tscreen>
<sect1><heading> Création des périphériques réseau NetRom
<p>
Une fois les deux fichiers mis au point, il faut créer les périphériques
NetRom. La démarche est proche du cas AX.25 à ceci près que l'on se sert à
présent de la commande <em/nrattach/. Elle constitue un pendant à la commande
<em/axattach/ et crée des périphériques NetRom qui se retrouvent sous la
dénomination `<tt/nr[0-9]/' (la première invocation produit `<tt/nr0/', la
seconde `<tt/nr1/' etc.) Pour associer un périphérique NetRom au port
défini précédemment, on utilise :
<tscreen><verb>
# nrattach netrom
</verb></tscreen>
Cette commande active le périphérique NetRom (<tt>nr0</tt>) nommé
<tt>netrom</tt> configuré conformément au contenu du fichier
<tt>/etc/ax25/nrports</tt>.
<sect1><heading> Lancement du démon NetRom
<p>
Le noyau Linux gère le protocole NetRom et assure la commutation mais il ne
prend pas en charge certaines fonctions. Le démon NetRom maintient les tables
de routage NetRom et diffuse les messages de routage NetRom. Il se lance via :
<tscreen><verb>
# /usr/sbin/netromd -i
</verb></tscreen>
Le fichier <tt>/proc/net/nr_neigh</tt> devrait progressivement se
remplir d'informations concernant vos voisins NetRom.
<p>
N'oubliez pas d'inclure la commande <tt>/usr/sbin/netromd</tt> dans vos
scripts de démarrage ou d'en créer un dédié à l'automatisation du processus.
<sect1><heading> Routage NetRom
<p>
Peut-être voudrez-vous mettre en place des routes statiques pour certains hôtes
particuliers. La commande <em/nrparms/ dispose d'une telle fonction. Reportez-vous
à la page de <em/man/ pour une description complète. A titre d'exemple,
pour indiquer sur mon port AX.25 `<tt/radio/' une route NetRom vers le
<tt/#MINTO:VK2XLZ-10/ en passant par mon voisin <tt/VK2SUT-9/ :
<tscreen><verb>
# /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9
</verb></tscreen>
<p>
<em/nrparms/ permet également de créer manuellement de nouveau voisins.
La commande suivante crée un voisin NetRom <tt/VK2SUT-9/ d'une qualité de
<tt/120/ qui ne sera pas supprimé automatiquement.
<tscreen><verb>
# /usr/sbin/nrparms -routes radio VK2SUT-9 + 120
</verb></tscreen>
<sect><heading> TCP/IP sur une interface NetRom
<p>
La configuration ressemble à celle d'AX.25 pour TCP/IP.
<p>
Soit vous précisez l'adresse IP et le MTU avec <em>nrattach</em>, soit vous
utilisez les commandes <em>ifconfig</em> et <em>route</em>. Il vous faudra
ajouter à la main les caractéristiques <em>arp</em> des hôtes concernés par
votre routage puisque votre machine ne dispose d'aucun mécanisme pour
déterminer une adresse NetRom utilisable afin d'atteindre une interface IP
particulière.
<p>
Pour créer une interface <tt>nr0</tt> d'adresse IP <tt>44.136.8.5</tt>, de
MTU <tt>512</tt> et configuré conformément aux spécifications du fichier
<tt>/etc/ax25/nrports</tt> relatives au port NetRom appelé <tt>netrom</tt> :
<tscreen><verb>
# /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
# route add 44.136.8.5 nr0
</verb></tscreen>
Autre méthode :
<tscreen><verb>
# /usr/sbin/nrattach netrom
# ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom VK2KTJ-9
# route add 44.136.8.5 nr0
</verb></tscreen>
En ce qui concerne le volet arp et le routage, pour joindre l'interface IP
<tt>44.136.80.4</tt> à l'adresse NetRom <tt>BBS:VK3BBS</tt> via un
voisin NetRom d'identifiant <tt>VK2SUT-0</tt>, on exécuterait :
<tscreen><verb>
# route add 44.136.80.4 nr0
# arp -t netrom -s 44.136.80.4 vk2sut-0
# nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0
</verb></tscreen>
Les arguments `<tt>120</tt>' et `<tt>6</tt>' passés à la <em>nrparms</em>
fixent les paramètres de qualité et d'obsolescence NetRom pour la route.
<sect><heading> Configuration des ports Rose
<p>
Le protocole de transmission de paquets Rose est semblable à la couche trois
des spécifications X.25. La gestion Rose du noyau est une version
<bf/modifiée/ de
<url url="http://fpac.lmi.ecp.fr/f1oat/f1oat.html"
name="FPAC Rose implementation">.
<p>
La couche Rose s'appuie sur les ports AX.25 que vous définissez. La procédure
détaillée ci-dessous s'appliquera à toutes les interfaces NetRom que vous
souhaiterez définir.
<sect1><heading> Le fichier <tt>/etc/ax25/rsports</tt>
<p>
Ce fichier est l'analogue pour les ports Rose du fichier
<tt>/etc/ax25/axports</tt> pour les ports AX.25.
<p>
Le format du fichier est le suivant :
<tscreen><verb>
name addresss description
</verb></tscreen>
Avec :
<descrip>
<tag> name </tag> nom affecté au port.
<tag> address </tag> adresse Rose sur 10 digits.
<tag> description </tag> commentaire.
</descrip>
Par exemple :
<tscreen><verb>
rose 5050294760 Rose Port
</verb></tscreen>
Notez que Rose emploie par défaut l'identifiant/ssid du port AX.25.
<p>
La commande <em/rsparms/ permet de modifier l'identifiant Rose. Par exemple,
pour que Linux se serve de l'identifiant <tt/VK2KTJ-10/ pour le trafic Rose
sur tous les ports AX.25 .
<tscreen><verb>
# /usr/sbin/rsprams -call VK2KTJ-10
</verb></tscreen>
<sect1><heading> Création des périphériques réseau Rose
<p>
Une fois le fichier <tt>/etc/ax25/rsports</tt> mis au point, vous pouvez créer
les périphériques Rose en reprenant la démarche AX.25. Vous emploierez la
commande <em/rsattach/ qui crée des périphériques sous l'appellation
`<tt/rose[0-5]/' (la première invocation produit `<tt/rose0/', la seconde
`<tt/rose1/' etc...). Par exemple :
<tscreen><verb>
# rsattach rose
</verb></tscreen>
Cette commande active le périphérique Rose (<tt/rose0/) nommé `<tt/rose/'
configuré conformément au contenu du fichier <tt>/etc/ax25/rsports</tt>.
<sect1><heading> Routage Rose
<p>
Le protocole Rose ne gère pour l'instant que le routage statique. Il
se définit par le biais de la commande <em/rsparms/.
<p>
Par exemple, pour indiquer une route vers le noeud Rose <tt/5050295502/ via un
port AX.25 nommé `<tt/radio/' dans le fichier <tt>/etc/ax25/axports</tt> en
passant par le voisin d'identificateur <tt/VK2XLZ/ :
<p>
<tscreen><verb>
# rsparms -nodes add 5050295502 radio vk2xlz
</verb></tscreen>
<p>
Un masque vous permettra éventuellement de regrouper différentes destinations
Rose sur une seule route. Par exemple :
<tscreen><verb>
# rsparms -nodes add 5050295502/4 radio vk2xlz
</verb></tscreen>
On retrouve l'exemple précédent à ceci près que toute adresse de destination
dont les quatre premiers digits correspondent (toute adresse commençant par
<tt/5050/ donc) sera routée. La variante suivante s'avère sûrement la moins
ambiguë :
<tscreen><verb>
# rsparms -nodes add 5050/4 radio vk2xlz
</verb></tscreen>
<sect><heading> Communications AX.25/NetRom/Rose
<p>
Maintenant que vos interfaces AX.25, NetRom et Rose sont activées, vous
devriez être capable de procéder à des essais.
<p>
Le paquetage des utilitaires AX.25 comprend le programme `<em/call/' qui
sert d'intermédiaire pour AX.25, NetRom et Rose.
<p>
Un appel AX.25 :
<tscreen><verb>
/usr/bin/call radio VK2DAY via VK2SUT
</verb></tscreen>
Un appel NetRom vers un noeud d'alias <tt/SUNBBS/ :
<tscreen><verb>
/usr/bin/call netrom SUNBBS
</verb></tscreen>
Un appel Rose pour <tt/HEARD/ au noeud <tt/5050882960/ :
<tscreen><verb>
/usr/bin/call rose HEARD 5050882960
</verb></tscreen>
Remarque : vous devez préciser à <em/call/ le port à employer, vu que le même
noeud de destination peut être joignable via n'importe lequel des ports
que vous aurez configurés.
<p>
<em>call</em> fournit un terminal de contrôle en mode ligne de commande pour
les appels AX.25. Les lignes commençant par `<tt>~</tt>' sont identifiées
comme des commandes. La commande `<tt>~.</tt>' coupe la communication.
<p>
Reportez-vous à la page de man sous <tt>/usr/man</tt> pour davantage
d'informations.
<sect><heading> Configurer Linux pour accepter les connexions
<p>
Linux est un système d'exploitation puissant qui présente beaucoup de
flexibilité dans sa configuration. Le coût de cette flexibilité se retrouve
dans la mise au point de la configuration souhaitée. Avant d'être en mesure
d'accepter les connexions AX.25, NetRom ou Rose, vous devez vous poser un
certain nombre de questions. La plus importante : "Que vais-je laisser de
visible aux utilisateurs une fois connectés ?" Des gens ont mis au point
de sympathiques petites applications qui fournissent des services aux
appelants tels <em/pms/ ou, plus évolué, <em/node/ (tous deux sont compris
dans le paquetage des utilitaires AX.25). Vous pouvez également souhaiter
offrir une invite d'identification afin que les utilisateurs disposent d'un
shell ou même écrire vos propres programmes tels une base de données maison
ou un jeu. Quoi que vous fassiez, il faut spécifier à AX.25 le programme à
exécuter quand une connexion s'établit.
<p>
Le démon <em/ax25d/ joue un rôle similaire à celui rempli par <em/inetd/
pour les connexion TCP/IP entre machines UNIX. Il se met à l'écoute des
connexions entrantes et lorsqu'il en détecte une, il examine par
l'intermédiaire d'un fichier de configuration le programme à lancer auquel
il transmet la connexion. Puisqu'il s'agit d'un outil standard de gestion
des appels AX.25, NetRom et Rose, je vais à présent décrire les étapes de sa
configuration.
<sect1><heading> Le fichier <tt>/etc/ax25/ax25d.conf</tt>
<p>
Ce fichier contient la configuration du démon <em>ax25d</em> en charge des
connexions AX.25, NetRom et Rose.
<p>
Bien que le fichier paraisse un peu cryptique au premier abord, il s'avère
rapidement des plus simples à l'usage, avec quelques pièges à éviter.
<p>
Le format général du fichier est le suivant :
<tscreen><verb>
# Je suis un commentaire qu'ax25d ignorera
[nom de port] || <nom de port> || {nom de port}
<interlocuteur1> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>
<interlocuteur2> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>
parametres window T1 T2 T3 idle N2 <mode>
<interlocuteur3> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>
...
default window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>
</verb></tscreen>
Avec :
<descrip>
<tag> # </tag> en début de ligne pour indiquer un commentaire ignoré du
programme <em>ax25d</em>
<tag> <port_name> </tag> nom du port AX.25, NetRom ou Rose tel
que spécifié dans un des fichiers <tt>/etc/ax25/axports</tt>,
<tt>/etc/ax25/nrports</tt> ou <tt>/etc/ax25/rsports</tt>. Le nom du port
est entouré par `<tt/[]/' s'il s'agit d'un port AX.25, `<tt/<>/' si
c'est un port NetRom ou `<tt/{}/' pour un port Rose. Ce champ admet une
variante qui précède le nom du port par `<tt>callsign/ssid via</tt>' pour
indiquer que vous voulez accepter les appels vers l'identificateur cité par
l'intermédiaire de cette interface. Un exemple l'illustrera.
<tag> <peer> </tag> est l'identifiant du noeud auquel la configuration
s'applique. Si vous ne spécifiez pas de ssid, tous seront considérés comme
valables.
<tag> window </tag> paramètre de fenêtre AX.25 (K) ou valeur de MAXFRAMDE
pour cette configuration.
<tag> T1 </tag> délai de retransmission de trame (T1) exprimé en
demi-secondes.
<tag> T2 </tag> délai d'attente par le logiciel AX.25 d'une seconde trame
avant de préparer une réponse. S'exprime en secondes.
<tag> T3 </tag> délai d'inactivité avant qu'une connexion inactive ne soit
coupée. S'exprime en secondes.
<tag> idle </tag> période d'inactivité en secondes.
<tag> N2 </tag> nombre d'essais de retransmission avant qu'une connexion
ne soit coupée.
<tag> <mode> </tag> procure un mécanisme d'établissement de certains
types de permissions. Les modes sont activés ou inhibés grâce à une
combinaison de caractères représentant chacun un droit. L'accentuation
ne joue pas et les caractères doivent former un bloc ininterrompu.
<descrip>
<tag> u/U </tag> UTMP - non-supporté
<tag> v/V </tag> Validate call - non-supporté
<tag> q/Q </tag> Quiet - pas d'enregistrement des connexions
<tag> n/N </tag> check NetRom Neighbour - non-supporté
<tag> d/D </tag> Disallow Digipeaters - les connexions doivent être directes
<tag> l/L </tag> Lockout - connexion interdite
<tag> */0 </tag> marker - marqueur, pas de mode spécifique
</descrip>
<tag> <uid> </tag> userid sous laquelle le programme maintenant la
connexion sera exécuté.
<tag> <cmd> </tag> nom complet de la commande à lancer, sans arguments.
<tag> <cmd-name> </tag> texte qui apparaîtra à l'invocation de
<em>ps</em> comme commande du programme (en général la même chose que
<cmd> mais sans le chemin d'accès).
<tag> <arguments> </tag> arguments de ligne de commande passés à
<:cmd> lorsqu'il est lancé. Les éléments suivants permettent de
passer des informations utilisées :
<descrip>
<tag> %d </tag> nom du port recevant la connexion
<tag> %U </tag> identificateur AX.25 de l'extrémité connectée,
sans ssid, en majuscules <tag> %u </tag> identificateur AX.25
de l'extrémité connectée, sans ssid, en minuscules
<tag> %S </tag> identificateur AX.25 de l'extrémité connectée,
avec ssid, en majuscules
<tag> %s </tag> identificateur AX.25 de l'extrémité connectée,
avec ssid, en minuscules
<tag> %P </tag> identificateur AX.25 du noeud distant initiateur
de la connexion, sans ssid, en majuscules
<tag> %p </tag> identificateur AX.25 du noeud distant initiateur
de la connexion, sans ssid, en minuscules
<tag> %R </tag> identificateur AX.25 du noeud distant initiateur
de la connexion, avec ssid, en majuscules
<tag> %r </tag> identificateur AX.25 du noeud distant initiateur
de la connexion, avec ssid, en minuscules
</descrip>
</descrip>
Ue section au format précédent est requise pour chaque interface AX.25,
NetRom ou Rose que vous voulez voir accepter des connexions.
<p>
Le paragraphe comprend deux lignes particulières, l'une commençant par la
chaîne `<tt>parameters</tt>' et l'autre par la chaîne `<tt>default</tt>'
(il y a une différence).
<p>
`<tt>default</tt>' couvre tous les cas qui ne sont pas spécifiés ailleurs.
Ainsi, tous les appels sur l'interface <interface_call> ne
disposant pas d'une règle spécifique se retrouvent dans la rubrique
`<tt>default</tt>'. En l'absence d'une telle section, toutes les connexions
hors règle sont immédiatement interrompues sans autre forme de procès.
<p>
`<tt>parameters</tt>' est plus subtil et dissimule le piège mentionné
précédemment. Si le caractère `*' est présent dans un champ, une valeur par
défaut issue de la section `<tt>parameters</tt>' est employée. Le noyau
possède d'ailleurs une liste de valeurs utilisées en l'absence de
`<tt>parameters</tt>'. Le danger réside en ce que les entrées spécifiées
via `<tt>parameters</tt>' ne s'appliquent qu'aux règles qui les suivent.
Une même interface peut comporter plusieurs entrées `<tt>parameters</tt>'.
Notez que les règles `<tt>parameters</tt>' ne permettent pas de positionner
les champs `<tt/uid/' et `<tt/command/'.
<sect1><heading> Un exemple de fichier <tt>ax25d.conf</tt>
<p>
<tscreen><verb>
# ax25d.conf pour VK2KTJ - 02/03/97
# Ce fichier de configuration utilise le port AX.25 défini plus haut.
# <peer> Win T1 T2 T3 idl N2 <mode> <uid> <exec> <argv[0]>[<args....>]
[VK2KTJ-0 via radio]
parameters 1 10 * * * * *
VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u +
VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u +
NOCALL * * * * * * L
default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
[VK2KTJ-1 via radio]
default * * * * * 0 root /usr/sbin/node node
<netrom>
parameters 1 10 * * * * *
NOCALL * * * * * * L
default * * * * * * 0 root /usr/sbin/node node
{VK2KTJ-0 via rose}
parameters 1 10 * * * * *
VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u +
VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u +
NOCALL * * * * * * L
default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
{VK2KTJ-1 via rose}
default * * * * * 0 root /usr/sbin/node node radio
</verb></tscreen>
Dans cet exemple, toute personne réclamant une connexion via l'identificateur
`<tt/VK2KTJ-0/' du port AX.25 `<tt/radio/' se verra appliquer les règles
suivantes :
<p>
Tout appel depuis un identifiant `NOCALL' se verra rejeté. Notez l'emploi
du mode `L'.
<p>
La ligne <tt/parameters/ modifie deux paramètres par défaut du noyau
(Window et T1) et exécutera <em>/usr/sbin/axspawn</em>. Les instances de
<em>/usr/sbin/axspawn</em> appelées ainsi apparaîtront en tant que <em/axspawn/
dans un affichage issu de <em/ps/. Les deux lignes qui suivent définissent deux
stations auxquelles s'appliqueront les permissions.
<p>
La dernière ligne de la section est la règle fourre-tout appliquée au reste
des connexions (VK2XLZ et VK2DAY inclus dès lors qu'ils ont recours à un ssid
différent de -1). Tous les paramètres prennent leurs valeurs par défaut et
le programme <em/pms/ sera lancé avec un argument de ligne de commande
spécifiant une connexion AX.25 d'identifiant <tt/VK2KTJ/ (reportez-vous à la
partie `Configuration du PMS' pour davantage de détails).
<p>
La configuration suivante accepte les appels à <tt/VK2KTJ-1/ via le port
<tt/radio/. Le programme <em/node/ est exécuté à chaque connexion.
<p>
Vient ensuite une spécification de connexions NetRom (notez l'emploi des
signes inférieur et supérieur à la place des crochets). Toute personne se
connectant via le port `<tt/netrom/' déclenche le programme <em/node/ si son
identifiant est différent de `<tt/NOCALL/'. Dans le cas contraire, tout accès
est refusé.
<p>
Les deux dernières configurations concernent des connexions entrantes Rose,
la première pour ceux qui appellent le `<tt/VK2KTJ-0/' sur notre noeud Rose et
la seconde pour ceux qui emploient le `<tt/VK2KTJ-1/'. Elles fonctionnent de
la même façon. Notez l'emploi des accolades qui indiquent des ports Rose.
<p>
L'exemple manque un peu de naturel mais je crois qu'il illustre clairement les
propriétés importantes de la syntaxe du fichier de configuration. La page de
<em/man/ explique dans son intégralité le contenu du fichier <tt/ax25d.conf/.
Le paquetage <tt>ax25-utils</tt> inclut un exemple plus détaillé qui pourrait
également vous être utile.
<sect1><heading> Lancer <em>ax25d</em>
<p>
Une fois les deux fichiers de configuration mis au point, lancez la commande :
<tscreen><verb>
# /usr/sbin/ax25d
</verb></tscreen>
À présent, les gens devraient pouvoir se connecter en AX.25 à votre machine.
N'oubliez pas de modifier les fichiers de commande de démarrage du système
de façon que <tt>ax25d</tt> soit invoqué automatiquement à chaque
réinitialisation de la station.
<sect><heading> Le logiciel <em>node</em>
<p>
Le logiciel <em>node</em> a été développé par Tomi Manninen
<tt><tomi.manninen@hut.fi></tt>. Il a été conçu à partir du programme PMS
et offre une fonctionnalité de noeud facilement configurable. Une fois les
utilisateurs connectés, il leur permet de se servir de telnet, de NetRom, de
Rose et de AX.25 vers l'extérieur ainsi que d'obtenir diverses informations
telles finger, la liste des noeuds et des écoutes etc. Le noeud peut être
configuré assez simplement pour exécuter n'importe quelle commande Linux.
<p>
Normalement, le noeud sera invoqué par <em>ax25d</em>, bien qu'il puisse
également être appelé par le démon IP <em>inetd</em> pour permettre
aux utilisateurs d'obtenir un accès telnet à votre machine. Le lancement
depuis la ligne de commande est également possible.
<sect1><heading> Le fichier <tt>/etc/ax25/node.conf</tt>
<p>
<tt>node.conf</tt> est un fichier texte qui spécifie la configuration du noeud.
Son format est le suivant :
<tscreen><verb>
# /etc/ax25/node.conf
# Fichier de configuration du programme node(8)
#
# Un '#' indique une ligne de commentaire qui sera ignorée.
# Nom d'hôte de la machine noeud
hostname radio.gw.vk2ktj.ampr.org
# Réseau local
# définit ce qui doit être considéré comme 'local' du point de vue de la
# vérification des permissions grâce à nodes.perms.
localnet 44.136.8.96/29
# Ports cachés
# rend certains ports invisibles aux utilisateurs. Les ports n'apparaîtront pas
# via la commande Ports.
hiddenports rose netrom
# Identification du noeud
# apparaîtra à l'invite du noeud
NodeId LINUX:VK2KTJ-9
# Port NetRom
# nom du port NetRom qui employé pour les connexions NetRom sortant du noeud
NrPort netrom
# Délai d'inactivité du noeud
# en secondes
idletimout 1800
# Délai d'inactivité des connexions
# en secondes
conntimeout 1800
# Reprise de connexion
# indique si les utilisateurs doivent être reconnectés spontanément en cas
# de rupture de la connexion distante ou bien s'ils doivent être complètement
# déconnectés.
reconnect on
# Alias
alias CONV "telnet vk1xwt.ampr.org 3600"
alias BBS "connect radio vk2xsb"
# Alias (commandes externes)
# exécution de commandes externes au noeud
# extcmd <cmd> <flag> <userid> <commande>
# Flag == 1 pour l'instant
# <commande> a le même format que dans ax25d.conf
extcmd PMS 1 root /usr/sbin/pms pms -u %U -o VK2KTJ
# Enregistrement
# le niveau 3 est le plus détaillé, 0 désactive l'enregistrement
loglevel 3
# Caractère de contrôle
# 20 = (Control-T)
EscapeChar 20
</verb></tscreen>
<sect1><heading> Le fichier <tt>/etc/ax25/node.perms</tt>
<p>
<em>node</em> affecte des permissions aux utilisateurs. On décide ainsi des
utilisateurs qui ont le droit ou non d'employer des commandes telles (T)elnet
ou (C)onnect. <tt>node.perms</tt> contient cinq champs. Le caractère `*' dans
l'un d'eux indique une absence de contraintes pour son application. On
construit ainsi facilement des règles applicables par défaut.
<p>
<descrip>
<tag> user </tag>
Le premier champ indique l'identifiant d'appel concerné par les permissions.
Une éventuelle partie ssid sera ignorée.
<tag> method </tag>
Chaque protocole et chaque méthode d'accès disposent également de permissions.
Par exemple, les utilisateurs connectés via AX.25 ou NetRom peuvent être
autorisés à se servir de (C)onnect tandis que ceux issus d'une session telnet
depuis un noeud non-local s'en verront refuser l'accès. Le deuxième champ
spécifie donc à quelle méthode d'accès les permissions s'appliquent. Voici les
classes de méthodes d'accès :
<tscreen><verb>
method description
------ -----------------------------------------------------------
ampr session telnet depuis une adresse amprnet (44.0.0.0)
ax25 connexion AX.25
host node invoqué depuis la ligne de commande
inet session telnet depuis une adresse non locale, de type non amprnet
local session telent depuis un hôte 'local'
netrom connexion NetRom
rose connexion Rose
* n'importe quelle connexion
</verb></tscreen>
<tag> port </tag>
Vous pouvez également contrôler les permissions pour les utilisateurs AX.25
sur la base des ports employés. Le troisième champ contient un nom de port
si vous décidez d'employer cette possibilité (disponible seulement pour les
connexions AX.25).
<tag> password </tag>
Un mot de passe peut également être demandé lors de l'établissement de la
connexion. Cela s'avère pratique pour protéger des comptes utilisateurs
spécifiques disposant de privilèges particulièrement élevés. Si le quatrième
champ est positionné, il correspond au mot de passe attendu.
<tag> permissions </tag>
Les permissions sont fixées par le biais du dernier champ de chaque ligne.
L'information est codée au niveau du bit, chaque service disposant d'un bit
qui indique s'il est ou non activé. Ci-suit la liste des services et la
position du champ avec le bit positionné :
<tscreen><verb>
valeur description
------ -------------------------------------------------
1 Login
2 (C)onnect AX.25
4 (C)onnect NetRom
8 (T)elnet vers les hôtes locaux
16 (T)elnet vers amprnet (44.0.0.0)
32 (T)elnet vers les hôtes non-locaux, de type non-amprnet
64 (C)onnect AX.25 pour les ports cachés
128 (C)onnect Rose
</verb></tscreen>
On additionne ensuite les puissances de deux associées aux bits des
permissions activées. Le résultat va dans le cinquième champ.
</descrip>
<p>
Un exemple de fichier <tt>nodes.perms</tt> :
<tscreen><verb>
# /etc/ax25/node.perms
#
# L'opérateur a pour identité VK2KTJ, s'identifie par le mot de passe 'secret'
# et dispose de toutes les permissions pour toutes les méthodes de connexion.
vk2ktj * * secret 255
# Les utilisateurs suivants sont exclus
NOCALL * * * 0
PK232 * * * 0
PMS * * * 0
# Les utilisateur d'INET n'ont pas le droit de se connecter
* inet * * 0
# Les utilisateurs AX.25, NetRom, locaux, liés à l'hôte ou AMPR disposent de
# (C)onnect et de (T)elnet vers les hôtes locaux et ampr mais se voient
# interdire les autres adresses IP.
* ax25 * * 159
* netrom * * 159
* local * * 159
* host * * 159
* ampr * * 159
</verb></tscreen>
<sect1><heading> Exécution de <em>node</em> depuis <em>ax25d</em>
<p>
L'invocation du programme <em>node</em> par le démon <em>ax25d</em>
nécessite l'ajout de règles appropriées au fichier
<tt>/etc/ax25/ax25d.conf</tt>. Je souhaitais une configuration telle que les
utilisateurs puissent se connecter soit à <em>node</em> soit à un service
de leur choix. <em>ax25d</em> l'autorise par le biais d'une création
astucieuse d'alias de ports. Par exemple, partant de la configuration
d'<em>ax25d</em> donnée plus haut, on veut que tous les utilisateurs se
connectant à <tt>VK2KTJ-1</tt> reçoivent le noeud. Pour cela, on ajoute la
règle suivante au fichier <tt>/etc/ax25/ax25d.conf</tt> :
<tscreen><verb>
[vk2ktj-1 via radio]
default * * * * * 0 root /usr/sbin/node node
</verb></tscreen>
Linux répondra à toute demande de connexion sur le port AX.25 `<tt/radio/'
d'identifiant `<tt/VK2KTJ-1/' en exécutant le programme <em>nde</em>.
<sect1><heading> Exécution de <em>node</em> depuis <em>inetd</em>
<p>
Offrir la possibilité d'ouvrir une session telnet sur votre machine et
d'accéder au programme <em>node</em> est une tache plutôt facile. Commencez
par choisir le port auquel les utilisateurs se connecteront. Dans mon exemple,
j'ai pris arbitrairement le port 3694 bien que Tomi détaille dans sa
documentation la marche à suivre pour remplacer le démon telnet usuel par le
programme <em>node</em>.
<p>
Il faut modifier deux fichiers.<p>
Ajouter au fichier <tt>/etc/services</tt> :
<tscreen><verb>
node 3694/tcp #OH2BNS's node software
</verb></tscreen>
et au fichier <tt>/etc/inetd.conf</tt> :
<tscreen><verb>
node stream tcp nowait root /usr/sbin/node node
</verb></tscreen>
Une fois <em>inetd</em> redémarré, tout utilisateur effectuant un telnet vers
le port 3694 de votre machine se verra demander un login et, selon la
configuration, un mot de passe avant d'être connecté à <em>node</em>.
<sect><heading> Configuration de <em>axspawn</em>.
<p>
<em/axspawn/ permet aux stations AX.25 qui se connectent d'ouvrir une session
sur votre machine. Il peut être lancé par le programme <em/ax25d/ décrit
ci-dessus d'une façon similaire à <em/node/. Pour ouvrir une session
utilisateur, vous ajouterez une variante de la ligne suivante au fichier
<tt>/etc/ax25/ax25d.conf</tt> :
<tscreen><verb>
default * * * * * 1 root /usr/sbin/axspawn axspawn %u
</verb></tscreen>
Si la ligne s'achève sur le caractère <tt/+/, l'utilisateur devra appuyer sur
la touche d'entrée avant de pouvoir s'identifier. Par défaut, il n'y a pas
d'attente. Toutes les configurations d'hôtes qui suivent la ligne précédente
déclencheront l'appel d'<em/axspawn/ lorsqu'ils se connecteront. Quand
<em/axspawn/ s'exécute, il vérifie tout d'abord que l'argument de ligne de
commande fourni est un identifiant licite, supprime le SSID puis parcourt le
fichier <tt>/etc/passwd</tt> pour voir si l'utilisateur dispose d'un compte.
Si c'est le cas et que le mot de passe associé est <tt/""/ (vide) ou <tt/+/,
la session utilisateur est ouverte. En présence d'un autre mot de passe,
celui-ci est demandé. Si le compte n'existe pas, <em/axspawn/ peut être
configuré de façon à en créer un automatiquement.
<sect1><heading> Mise au point du fichier <tt>/etc/ax25/axspawn.conf</tt>
<p>
Le format du fichier est le suivant :
<tscreen><verb>
# /etc/ax25/axspawn.conf
#
# creation automatique de comptes utilisateur
create yes
#
# compte d'invite en l'absence de creation automatique et si tout le reste
# echoue. Se desactive ave "no"
guest no
#
# id ou nom du groupe pour le compte automatique
group ax25
#
# id de depart
first_uid 2001
#
# id maximale
max_uid 3000
#
# emplacement des repertoires utilisateurs crees automatiquement
home /home/ax25
#
# shell utilisateur
shell /bin/bash
#
# lien entre les id utilisateur et le numero d'identification pour les
# connexions sortantes
associate yes
</verb></tscreen>
Détail des huit caractéristiques configurables de <em/axspawn/ :
<descrip>
<tag>#</tag> indique un commentaire.
<tag>create</tag> si ce champ est positionné à <tt>yes</tt> alors
<em>axspawn</em> tentera de créer un compte pour tout utilisateur qui
n'apparaît pas dans le fichier <tt>/etc/passwd</tt>.
<tag>guest</tag> fournit le nom du compte à employer pour les utilisateurs
n'en ayant pas lorsque <em>create</em> est positionné à <tt>no</tt>. On y
trouve souvent <tt>ax25</tt> ou <tt>guest</tt>.
<tag>group</tag> indique le groupe pour les utilisateurs qui n'apparaissent
pas dans le fichier <tt>/etc/passwd</tt>.
<tag>first_uid</tag> valeur de départ des identités utilisateur lors
de la création automatique
<tag>max_uid</tag> identité utilisateur maximale disponible à la
création automatique
<tag>home</tag> répertoire dans lequel seront créés les comptes utilisateurs
<tag>shell</tag> shell de login des nouveaux utilisateurs
<tag>associate</tag> indique si les connexions sortantes de l'utilisateur ont
lieu avec son identifiant d'appel personnel ou avec celui de votre station
</descrip>
<sect><heading> Configuration de <em>pms</em>
<p>
<em>pms</em> fournit un système simple de messagerie personnelle. Il a été
écrit à l'origine par Alan Cox. Dave Brown, N2RJT,
<tt><dcb@vectorbd.com></tt> en a repris le développement. Les
fonctionnalités sont restées simples : envoi de courrier électronique au
propriétaire de la station et obtention d'informations limitée. Dave travaille
actuellement à les enrichir.
<p>
Il faut tenir à jour quelques fichiers contenant des informations sur le
système et ajouter les entrées adéquates au fichier <tt/ax25d.conf/ de telle
sorte qu'il s'exécute pour les utilisateurs connectés.
<p>
<sect1><heading> Mise au point du fichier <tt>/etc/ax25/pms.motd</tt>
<p>
Le fichier <tt>/etc/ax25/pms.motd</tt> contient l'équivalent du message du jour
affiché aux utilisateurs après qu'ils se sont connectés et ont reçu
l'en-tête usuel de BBS. Il s'agit d'un simple fichier texte qui sera transmis
tel quel.
<sect1><heading> Mise au point du fichier <tt>/etc/ax25/pms.info</tt>
<p>
<tt>/etc/ax25/pms.info</tt> est également un simple fichier texte dans lequel
vous renseignerez des informations plus détaillées relatives à votre station
ou à sa configuration. Ce fichier est transmis aux utilisateurs en réponse à
la commande <tt>Info</tt> depuis l'invite <tt>PMS</tt>.
<sect1><heading> Associer les identifiants AX.25 aux comptes utilisateurs
<p>
Lors de l'envoi d'un courrier à destination d'un identifiant d'appel AX.25,
<em>pms</em> s'attend à trouver une association avec une identité
d'utilisateur usuelle sur la station. La section suivante décrit le processus.
<sect1><heading> Ajout de PMS au fichier <tt>/etc/ax25/ax25d.conf</tt>
<p>
L'ajout de <em>pms</em> au fichier <tt>ax25d.conf</tt> est très simple. Il vous
faut néanmoins garder un élément en tête : Dave a ajouté la prise en compte
d'arguments de ligne commande à PMS afin de gérer différentes conventions de
fin de ligne. AX.25 et NetRom requièrent une fin de ligne et un saut de ligne
tandis que le standard Unix comprend juste le caractère de fin de ligne.
Par exemple, pour une entrée correspondant au lancement par défaut de PMS à
l'ouverture d'une connexion sur un port AX.25, vous ajouteriez :
<tscreen><verb>
default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj
</verb></tscreen>
Cette ligne exécute <em>pms</em> en lui précisant qu'il s'agit d'une connexion
AX.25 et que PMS a pour propriétaire <tt>vk2ktj</tt>. Consultez la page de
<em>man</em> pour l'emploi d'autres méthodes de connexion.
<sect1><heading> Tester PMS
<p>
Exécutez depuis la ligne de commande :
<verb>
# /usr/sbin/pms -u vk2ktj -o vk2ktj
</verb>
En remplaçant votre identifiant d'appel par le mien, cela lancera pms en lui
imposant l'emploi de la convention unix de fin de ligne et en donnant
<tt>vk2ktj</tt> comme identité à l'utilisateur connecté.
<p>
Vous pouvez également demander à un autre noeud de se connecter afin de
confirmer le fonctionnement de votre <tt>ax25d.conf</tt>.
<sect><heading> Configuration des programmes <em>user_call</em>
<p>
On trouve derrière ce nom les programmes <em/ax25_call/ et
<em/netrom_call/. Il s'agit de programmes très simples destinés
à être lancés par <em/ax25d/ pour automatiser les connexions depuis des
hôtes distants. On peut bien sûr les employer dans des scripts ou via
d'autres démons tels <em/node/.
<p>
Ils équivalent au programme <em/call/ et n'effectuent aucun traitement sur les
données, ce qui vous épargne le problème des conversions de fin de lignes.
<p>
Un exemple pour commencer. On suppose que vous disposez d'un petit réseau
personnel, d'une station Linux tenant lieu de passerelle radio et d'une
autre machine -- on prendra un noeud BPQ -- qui lui est connectée par un lien
ethernet.
<p>
En principe, si vous voulez que les utilisateurs radio puissent joindre le
noeud BPQ, il leur faudra le faire par l'intermédiaire de votre noeud Linux
ou se connecter au démon node puis établir la connexion. <em/ax25_call/
peut simplifier le processus s'il est invoqué par <em/ax25d/.
<p>
Prenons le cas d'un noeud BPQ d'identifiant <tt/VK2KTJ-9/, la station Linux
étant munie d'un port AX.25/ethernet nommé `<tt/bpq/'. `<tt/radio/' désignera
le port radio de la machine passerelle.
<p>
Un enregistrement dans le fichier <tt>/etc/ax25/ax25d.conf</tt> du type :
<tscreen><verb>
[VK2KTJ-1 via radio]
default * * * * * * *
root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9
</verb></tscreen>
permet aux les connexions directes à `<tt/VK2KTJ-1/' qui n'est autre que
le démon Linux <em/ax25d/, celui ci les commutant automatiquement sur un
lien AX.25 à `<tt/VK2KTJ-9/' via l'interface `<tt/bpq/'.
<p>
Vous pouvez essayer toutes sortes d'autres configurations. Les utilitaires
`<em/netrom_call/' et `<em/rose_call/' opèrent de façon
similaire. Un radioamateur en a fait usage pour faciliter l'accès à un
BBS distant. En principe, on aurait dû entrer à la main une chaîne de
connexion démesurément longue. Il a donc ajouté une entrée faisant
apparaitre le BBS comme une entité appartenant au réseau local, <em/ax25d/
servant en fait de proxy pour l'accès à la machine distante.
<sect><heading> Configuration des commandes Rose Uplink et Downlink
<p>
Si vous avez l'habitude des réalisations Rose à base de ROM, vous ne
serez pas dépaysé par la méthode d'appel AX.25 à travers un réseau Rose.
Soit un noeud local d'utilisateurs Rose d'identifiant <tt/VK2KTJ-5/ et
un appelant AX.25 souhaitant se connecter à <tt/VK5XXX/ au noeud Rose
distant <tt/5050882960/, il lancera la commande :
<tscreen><verb>
c vk5xxx v vk2ktj-5 5050 882960
</verb></tscreen>
Au niveau du noeud distant, <tt/VK5XXX/ recevra une connexion avec
l'identifiant des utilisateurs locaux AX.25 digipétée par l'intermédiaire
de l'identifiant des noeuds Rose distants.
<p>
La couche protocolaire Rose de Linux ne gère pas cette fonctionnalité dans
le noyau mais les deux applications <em/rsuplnk/ et <em/rsdwnlnk/ savent
s'en charger.
<sect1><heading> Configuration d'une liaison Rose descendante
<p>
Afin que votre station Linux accepte un appel Rose et établisse une
connexion AX.25 vers une destination à l'écoute de laquelle il n'est pas,
vous devez ajouter un enregistrement à votre fichier
<tt>/etc/ax25/ax25d.conf</tt>. En principe, cette ligne correspondra au
comportement par défaut pour les connexions Rose entrantes. Par exemple,
vous êtes à l'écoute des demandes d'accès Rose aux destinations telles
<tt/NODE-0/ ou <tt/HEARD-0/ que vous gérez localement, mais toutes les
autres connexions sont transmises à la commande <em/rsdwnlink/ sous
l'hypothèse qu'il s'agit d'utilisateurs AX.25.
<p>
Une configuration typique :
<tscreen><verb>
#
{* via rose}
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5
#
</verb></tscreen>
Avec cette configuration, tout appel qui effectue une connexion Rose
sur votre noeud Linux vers une destination à l'écoute de laquelle vous
ne vous tenez pas se verra converti en une connexion AX.25 sur le port
<tt/4800/ avec <tt/VK2KTJ-5/ pour chemin.
<sect1><heading> Configuration d'un liaison Rose montante
<p>
Pour que votre station Linux accepte les connexions AX.25 d'une façon
similaire à celle du noeud Rose, vous ajouterez à votre fichier
<tt>/etc/ax25/ax25d.conf</tt> une ligne du type :
<tscreen><verb>
#
[VK2KTJ-5* via 4800]
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose
#
</verb></tscreen>
Notez la syntaxe particulière pour l'identifiant local. Le caractère
`<tt/*/' indique que l'application doit être invoquée si l'identifiant
est reconnu dans le chemin de répétition d'une connexion.
<p>
Avec cette configuration, un appel AX.25 peut établir des appels Rose au
moyen de la séquence présentée dans l'introduction. Toute personne
demandant un relai via l'identifiant <tt/VK2KTJ-5/ sur le port AX.25
<tt/4800/ sera traité par la commande <em/rsuplnk/.
<sect><heading> Association des identifiants AX.25 aux comptes utilisateurs
<p>
Dans de nombreuses situations, il est fortement souhaitable d'associer
un identifiant à compte utilisateur. Par exemple lorsque plusieurs opérateurs
radioamateurs partagent la même machine et souhaitent employer leur propre
identifiant lorsqu'ils effectuent des appels ou lorsque des utilisateurs
de PMS désirent dialoguer avec quelqu'un en particulier sur une station.
<p>
Les utilitaires AX.25 permettent de réaliser cette association. On l'a déjà
évoqué dans la section relative à PMS mais je le répète ici afin de m'assurer
que vous ne passerez pas à côté.
<p>
L'association s'effectue grâce à la commande <em>axparms</em>. Par exemple :
<tscreen><verb>
# axparms -assoc vk2ktj terry
</verb></tscreen>
Cette commande associe l'identifiant AX.25 <tt>vk2ktj</tt> à l'utilisateur
<tt>terry</tt>. Tout courrier destiné à <tt>vk2ktj</tt> sur <em>pms</em>
sera transmis au compte Linux <tt>terry</tt>.
<p>
Songez à mettre ces correspondances dans vos fichiers <em>rc</em> de
démarrage afin qu'elles soient disponibles à chaque réinitialisation.
<p>
<bf/Notez/ que vous ne devez surtout pas associer un identifiant au compte
<tt/root/ vu que cela pourrait poser des problèmes de configuration à
d'autres programmes.
<sect><heading> Entrées du système de fichier <tt>/proc/</tt>
<p>
Le pseudo système de fichiers <tt>/proc</tt> contient divers fichiers
spécifiques aux programmes AX.25 et NetRom. Ces fichiers sont normalement
employés par les utilitaires AX.25 mais leur formatage est tel qu'ils
peuvent vous intéresser. Le format est suffisamment simple pour ne pas
nécessiter beaucoup d'explications.
<descrip>
<tag>/proc/net/arp</tag> : liste des associations entre adresses IP
et adresses de niveau MAC, qu'il s'agisse d'ethernet, d'AX.25 ou d'un
autre protocole MAC.
<tag>/proc/net/ax25</tag> : sockets AX.25 ouverts. Elles peuvent être
en attente de connexion ou actives.
<tag>/proc/net/ax25_bpqether</tag> : identifiants AX.25
de type Ethernet BPQ.
<tag>/proc/net/ax25_calls</tag> : équivalences entre identités
d'utilisateurs Linux et identifiants d'appel telles que définies par la
commande <em/axparms -assoc/.
<tag>/proc/net/ax25_route</tag> : informations sur les chemins AX.25
<tag>/proc/net/nr</tag> : sockets NetRom ouvertes. Elles peuvent être
en attente de connexion ou actives.
<tag>/proc/net/nr_neigh</tag> : liste de voisins NetRom
<tag>/proc/net/nr_nodes</tag> : informations sur les voisins NetRom
<tag>/proc/net/rose</tag> : sockets Rose ouvertes. Elles peuvent être en
attente de connexion ou actives.
<tag>/proc/net/rose_nodes</tag> : correspondances entre destinations
et voisins Rose
<tag>/proc/net/rose_neigh</tag> : liste de voisins Rose
<tag>/proc/net/rose_routes</tag> : connexions Rose en cours
</descrip>
<sect><heading> Programmation réseau AX.25, NetRom, Rose
<p>
L'avantage le plus important lié à l'utilisation des protocoles par
paquets radioamateurs du noyau réside en la facilité de développement
des programmes et applications qui les emploient.
<p>
Bien que la programmation réseau sous Unix déborde du cadre de ce document,
je vais décrire les principaux éléments d'utilisation des protocoles
AX.25, NetRom et Rose au sein de vos programmes.
<p>
<sect1><heading> Familles d'adresses
<p>
La programmation AX.25, NetRom et Rose est assez semblable à la programmation
TCP/IP sous Linux. LEs principales différences se font au niveau des familles
d'adresses et des structures d'adresse à mettre en place.
<p>
Les noms de familles d'adresses pour AX.25, NetRom et Rose sont respectivement
<tt/AF_AX.25/, <tt/AF_NETROM/ et <tt/AF_ROSE/.
<sect1><heading> Fichiers d'en-tête
<p>
Incluez toujours les fichiers `<tt/ax25.h/', `<tt/netrom.h/' ou `<tt/rose.h/'
si vous vous servez de ces protocoles. Les débuts de fichiers-types
ressemblent à quelque chose du style :
<p>
Pour AX.25 :
<tscreen><verb>
#include <ax25.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_AX.25
</verb></tscreen>
Pour NetRom :
<tscreen><verb>
#include <ax25.h>
#include <netrom.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_NETROM;
</verb></tscreen>
Pour Rose :
<tscreen><verb>
#include <ax25.h>
#include <rose.h>
int s, addrlen = sizeof(struct sockaddr_rose);
struct sockaddr_rose sockaddr;
sockaddr.srose_family = AF_ROSE;
</verb></tscreen>
<sect1><heading> Mise en forme des identifiants et exemples
<p>
La librairie <tt>lib/ax25.a</tt> du paquetage des utilitaires AX.25 contient
des routines de conversion des identifiants. Vous pouvez bien sûr écrire les
vôtres si vous le souhaitez.
<p>
Les programmes <em/user_call/ sont d'excellents exemples à partir
desquels travailler. Leur source code est inclus dans les outils AX.25.
Si vous passez un peu de temps à les examiner, vous remarquerez rapidement
que quatre-vingt-dix pour cent du travail consiste à préparer l'ouverture
des sockets. En fait la connexion est rapide mais la mise en place prend
du temps.
<p>
Les exemples sont assez simples pour ne pas prêter à confusion. Si vous avez
des questions, adressez-vous directement à la liste de diffusion
<tt/linux-hams/ où quelqu'un vous aidera sûrement.
<sect><heading> Quelques configurations-types
<p>
Ci-suivent des exemples de configurations parmi les plus typiques. Il ne
s'agit que d'un guide dans la mesure où il y a autant de façons de configurer
un réseau qu'il y a de réseaux disponibles mais il peut vous servir de point
de départ.
<sect1><heading> Un petit réseau Ethernet local avec un routeur Linux vers un
réseau radio local
<p>
Nombre d'entre vous disposent de petits réseaux locaux chez eux et désirent
connecter les stations de ce réseau à un réseau radio local. J'ai ce type
de configuration chez moi. J'ai réussi à obtenir un bloc d'adresses contiguës
que je gère par une route unique sur mon Ethernet local. Votre coordinateur
IP local vous aidera si vous souhaitez procéder ainsi. Les adresses du réseau
Ethernet local forment un sous-ensemble des adresses radio. Voici ma
configuration personnelle avec le routeur Linux :
<tscreen><verb>
. . . . . .
-+- .
| Reseau /---------\ . Reseau
| 44.136.8.96/29| | . 44.136.8/24 \ | /
| | Routeur | . \|/
| | | . |
| eth0 | & | . /-----\ /----------\ |
+---------------+ +-----| TNC |----| Radio |---/
| 44.136.8.97 | serveur | . \-----/ \----------/
| | | sl0
| | Linux | 44.136.8.5
| | | .
| | | .
| \_________/ .
-+- . . . . . .
</verb></tscreen>
<tscreen><verb>
#!/bin/sh
# /etc/rc.net
# Configuration d'un port AX.25 de type KISS et d'une interface Ethernet
echo "/etc/rc.net"
echo " Configuring:"
echo -n " loopback:"
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
echo " done."
echo -n " ethernet:"
/sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \
broadcast 44.136.8.103 up
/sbin/route add 44.136.8.97 eth0
/sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0
echo " done."
echo -n " AX.25: "
kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
route add -host 44.136.8.5 sl0
route add -net 44.136.8.0 window 1024 sl0
echo -n " Netrom: "
nrattach -i 44.136.8.5 netrom
echo " Routing:"
/sbin/route add default gw 44.136.8.68 window 1024 sl0
echo " default route."
echo done.
# end
</verb></tscreen>
<tt>/etc/ax25/axports</tt>
<tscreen><verb>
# name callsign speed paclen window description
4800 VK2KTJ-0 4800 256 2 144.800 MHz
</verb></tscreen>
<tt>/etc/ax25/nrports</tt>
<tscreen><verb>
# name callsign alias paclen description
netrom VK2KTJ-9 LINUX 235 Linux Switch Port
</verb></tscreen>
<tt>/etc/ax25/nrbroadcast</tt>
<tscreen><verb>
# ax25_name min_obs def_qual worst_qual verbose
4800 1 120 10 1
</verb></tscreen>
<itemize>
<item> L'option IP_FORWARDING doit être activée dans le noyau.
<item> Les fichiers de configuration AX.25 correspondent essentiellement à
ceux donnés dans les sections précédentes. Reportez-y vous si nécessaire.
<item> J'ai décidé d'attribuer au port radio une adresse qui n'appartient
pas au bloc attribué à mon réseau local. Rien n'y obligeait et j'aurais
dû facilement y affecter l'adresse <tt>44.136.8.97</tt>.
<item><tt>44.136.8.68</tt> correspond à ma passerelle d'encapsulation IP
dans IP et est donc ma route par défaut.
<item> Chaque station sur l'Ethernet est munie de la route suivante :
<tscreen><verb>
route add -net 44.0.0.0 netmask 255.0.0.0 \
gw 44.136.8.97 window 512 mss 512 eth0
</verb></tscreen>
Les paramètres <em>mss</em> et <em>window</em> me permettent d'obtenir les
meilleures performances possibles aussi bien pour les connexions Ethernet
locales que pour les accès radio.
<item> smail, http, ftp et d'autres démons s'exécutent également sur le
routeur qui est ainsi la seule station à fournir aux autres des services.
<item> Le routeur est un 386DX20 d'entrée de gamme avec 20 Mo de disque et une
configuration Linux minimaliste.
</itemize>
<sect1><heading> Passerelle d'encapsulation IP dans IP
<p>
L'emploi de Linux comme passerelle d'encapsulation IP est maintenant courant
à travers le monde. Le nouveau gestionnaire de tunnel IP accepte les routes
multiples encapsulées et rend obsolète l'ancien démon <em>ipip</em>.
<p>
Un schéma classique :
<tscreen><verb>
. . . . . .
--- .
| Reseau /----------\ . Reseau
| 154.27.3/24 | | . 44.136.16/24 \ | /
| | Linux | . \|/
| | | . |
| eth0 | | . /-----\ /----------\ |
+---------------+Passerelle+-----| TNC |----| Radio |---/
| 154.27.3.20 | | . \-----/ \----------/
| | IPIP | sl0
| | | 44.136.16.1
| | | .
| | | .
| \__________/ .
--- . . . . . .
</verb></tscreen>
Voici les fichiers de configuration intéressants :
<tscreen><verb>
# /etc/rc.net
# This file is a simple configuration that provides one KISS AX.25
# radio port, one Ethernet device, and utilises the kernel tunnel driver
# to perform the IPIP encapsulation/decapsulation
#
echo "/etc/rc.net"
echo " Configuring:"
#
echo -n " loopback:"
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
echo " done."
#
echo -n " ethernet:"
/sbin/ifconfig eth0 154.27.3.20 netmask 255.255.255.0 \
broadcast 154.27.3.255 up
/sbin/route add 154.27.3.20 eth0
/sbin/route add -net 154.27.3.0 netmask 255.255.255.0 eth0
echo " done."
#
echo -n " AX.25: "
kissattach -i 44.136.16.1 -m 512 /dev/ttyS1 4800
/sbin/ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.16.255
/sbin/route add -host 44.136.16.1 sl0
/sbin/route add -net 44.136.16.0 netmask 255.255.255.0 window 1024 sl0
#
echo -n " tunnel:"
/sbin/ifconfig tunl0 44.136.16.1 mtu 512 up
#
echo done.
#
echo -n "Routing ... "
source /etc/ipip.routes
echo done.
#
# end.
</verb></tscreen>
et :
<tscreen><verb>
# /etc/ipip.routes
# This file is generated using the munge script
#
/sbin/route add -net 44.134.8.0 netmask 255.255.255.0 tunl0 gw 134.43.26.1
/sbin/route add -net 44.34.9.0 netmask 255.255.255.0 tunl0 gw 174.84.6.17
/sbin/route add -net 44.13.28.0 netmask 255.255.255.0 tunl0 gw 212.37.126.3
...
...
...
</verb></tscreen>
<tt>/etc/ax25/axports</tt>
<tscreen><verb>
# name callsign speed paclen window description
4800 VK2KTJ-0 4800 256 2 144.800 MHz
</verb></tscreen>
Quelques points à noter :
<itemize>
<item> Le nouveau gestionnaire de tunnel utilise le champ <em>gw</em> de
la table de routage à la place du paramètre <em>pointopoint</em> pour
fixer l'adresse de la passerelle IPIP distante. Il supporte ainsi plusieurs
routes par interface.
<item> Vous <bf>pouvez</bf> attribuer la même adresse à deux interfaces
réseau. Dans l'exemple courant, <tt>sl0</tt> et <tt>tunl0</tt> ont tous
deux été munis de l'adresse IP du port Radio. La passerelle distante
récupère ainsi la bonne adresse de votre passerelle dans les datagrammes
encapsulés qu'elle reçoit.
<item> Les commandes de routage relatives aux routes encapsulées peuvent être
générées automatiquement via une version modifiée du script <em>munge</em>
incluse ci-dessous. Les instructions de routage sont écrites dans un fichier
séparé et appelées par la commande <tt>source /etc/ipip.routes</tt> de
<em>bash</em> (en supposant que vous employez les mêmes conventions).
Le fichier source doit être au format de commande route NOS.
<item> Remarquez l'emploi de l'argument <em>window</em> dans la commande
<em>route</em>. Ce paramètre améliore les performances de la liaison radio.
</itemize>
<p>
Le nouveau script tunnel-munge :
<tscreen><verb>
#!/bin/sh
#
# From: Ron Atkinson <n8fow@hamgate.cc.wayne.edu>
#
# This script is basically the 'munge' script written by Bdale N3EUA
# for the IPIP daemon and is modified by Ron Atkinson N8FOW. It's
# purpose is to convert a KA9Q NOS format gateways route file
# (usually called 'encap.txt') into a Linux routing table format
# for the IP tunnel driver.
#
# Usage: Gateway file on stdin, Linux route format file on stdout.
# eg. tunnel-munge < encap.txt > ampr-routes
#
# NOTE: Before you use this script be sure to check or change the
# following items:
#
# 1) Change the 'Local routes' and 'Misc user routes' sections
# to routes that apply to your own area (remove mine please!)
# 2) On the fgrep line be sure to change the IP address to YOUR
# gateway Internet address. Failure to do so will cause serious
# routing loops.
# 3) The default interface name is 'tunl0'. Make sure this is
# correct for your system.
echo "#"
echo "# IP tunnel route table built by $LOGNAME on `date`"
echo "# by tunnel-munge script v960307."
echo "#"
echo "# Local routes"
echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0"
echo "#"
echo "# Misc user routes"
echo "#"
echo "# remote routes"
fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \
awk '{
split($3, s, "/")
split(s[1], n,".")
if (n[1] == "") n[1]="0"
if (n[2] == "") n[2]="0"
if (n[3] == "") n[3]="0"
if (n[4] == "") n[4]="0"
if (s[2] == "1") mask="128.0.0.0"
else if (s[2] == "2") mask="192.0.0.0"
else if (s[2] == "3") mask="224.0.0.0"
else if (s[2] == "4") mask="240.0.0.0"
else if (s[2] == "5") mask="248.0.0.0"
else if (s[2] == "6") mask="252.0.0.0"
else if (s[2] == "7") mask="254.0.0.0"
else if (s[2] == "8") mask="255.0.0.0"
else if (s[2] == "9") mask="255.128.0.0"
else if (s[2] == "10") mask="255.192.0.0"
else if (s[2] == "11") mask="255.224.0.0"
else if (s[2] == "12") mask="255.240.0.0"
else if (s[2] == "13") mask="255.248.0.0"
else if (s[2] == "14") mask="255.252.0.0"
else if (s[2] == "15") mask="255.254.0.0"
else if (s[2] == "16") mask="255.255.0.0"
else if (s[2] == "17") mask="255.255.128.0"
else if (s[2] == "18") mask="255.255.192.0"
else if (s[2] == "19") mask="255.255.224.0"
else if (s[2] == "20") mask="255.255.240.0"
else if (s[2] == "21") mask="255.255.248.0"
else if (s[2] == "22") mask="255.255.252.0"
else if (s[2] == "23") mask="255.255.254.0"
else if (s[2] == "24") mask="255.255.255.0"
else if (s[2] == "25") mask="255.255.255.128"
else if (s[2] == "26") mask="255.255.255.192"
else if (s[2] == "27") mask="255.255.255.224"
else if (s[2] == "28") mask="255.255.255.240"
else if (s[2] == "29") mask="255.255.255.248"
else if (s[2] == "30") mask="255.255.255.252"
else if (s[2] == "31") mask="255.255.255.254"
else mask="255.255.255.255"
if (mask == "255.255.255.255")
printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\
,n[1],n[2],n[3],n[4],$5
else
printf "route add -net %s.%s.%s.%s gw %s netmask %s dev tunl0\n"\
,n[1],n[2],n[3],n[4],$5,mask
}'
echo "#"
echo "# default the rest of amprnet via mirrorshades.ucsd.edu"
echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0"
echo "#"
echo "# the end"
</verb></tscreen>
<sect1><heading> Configuration d'une passerelle d'encapsulation AXIP
<p>
Nombre de passerelles Radio Amateur avec l'Internet encapsulent AX.25, NetRom
et Rose dans IP. Le cas des trames AX.25 relève du RFC 1226 écrit par Brian
Kantor. Mike Westerhof a réalisé un démon d'encapsulation AX.25 sous Unix en
1991. Le paquetage des utilitaires ax25-utils en contient une version
légèrement améliorée.
<p>
Un programme d'encapsulation AXIP reçoit des trames AX.25 d'un côté,
examine la destination AX.25 afin d'en déduire l'adresse IP à laquelle
les envoyer et les encapsule dans un datagramme TCP/IP avant de les émettre.
Il accepte également les datagrammes TCP/IP qui contiennent des trames AX.25,
extrait ces dernières et les traite comme s'il s'agissait de trames AX.25
reçues depuis un port AX.25. La distinction des trames IP contenant de
l'AX.25 se fait par l'intermédiaire d'un identifiant de protocole égal à 4
(la valeur 94 est possible quoique désuète). Le RFC 1226 décrit tout ça en
détail.
<p>
L'outil <em/ax25ipd/ inclus dans le paquetage ax25-utils se présente
comme un programme gérant une interface KISS, au travers de laquelle passeront
des trames AX.25, et une interface d'adaptation TCP/IP. Il se configure par
l'intermédiaire du fichier <tt>/etc/ax25/ax25ipd.conf</tt>.
<sect2><heading> Options de configuration d'AXIP
<p>
<em/ax25ipd/ opère dans deux modes : "digipeater" et "tnc". En mode "tnc",
le démon agit comme un TNC kiss. Vous lui fournissez des trames
d'encapsulation KISS et il les transmet comme dans la configuration normale.
En mode "digipeater", le démon agit comme un noeud de transmission AX.25.
Les différences entre ces deux modes sont subtiles.
<p>
Vous configurez dans le fichier à cet effet les "routes" ou correspondances
entre les identifiants AX.25 et les adresses IP des machines auxquelles vous
désirez également transmettre des paquets AX.25. Chaque route dispose
d'options qui seront expliquées un peu plus tard.
<p>
Voici les autres options à configurer :
<list>
<item> le tty du démon <em/ax25ipd/ ainsi que sa vitesse (en général
l'extrémité d'un tuyau)
<item> l'identifiant souhaité pour le mode "digipeat"
<item> l'intervalle beacon
<item> le choix entre une encapsulation AX.25 dans des datagrammes IP ou bien
dans des datagrammes UDP/IP. L'essentiel des passerelles AXIP emploie
une encapsulation IP mais certaines sont situées derrière des filtres qui
ne laisseront passer que les datagrammes UDP/IP. Le choix doit coïncider
avec ce qui est attendu à l'autre extrémité.
</list>
<sect2><heading> Un fichier de configuration <tt>/etc/ax25/ax25ipd.conf</tt>
typique
<p>
<tscreen><verb>
#
# fichier de configuration ax25ipd pour la station floyd.vk5xxx.ampr.org
#
# Transport axip. 'ip' garantit la compatibilite avec la plupart des
# autres passerelles.
#
socket ip
#
# Mode d'operation de ax25ipd (digi ou tnc)
#
mode tnc
#
# Si digi est selectionne, vous devez definir un identifiant. Si vous avez
# choisi tnc, l'identifiant est optionnel mais cela pourrait changer dans le
# futur (2 identifiants pour une kiss double port).
#
#mycall vk5xxx-4
#mycall2 vk5xxx-5
#
# En mode digi, on peut definir un alias (2 etc.).
#
#myalias svwdns
#myalias2 svwdn2
#
# ident toutes les 540 secondes ...
#
#beacon after 540
#btext ax25ip -- tncmode rob/vk5xxx -- Experimental AXIP gateway
#
# Port serie (ou tuyau connecte a kissattach dans mon cas)
#
device /dev/ttyq0
#
# Vitesse du peripherique
#
speed 9600
#
# niveau de log 0 - pas de sortie
# niveau de log 1 - informations de configuration
# niveau de log 2 - evenements majeurs et erreurs
# niveau de log 3 - evenements majeurs, erreurs et suivi des trames AX.25
# niveau de log 4 - tout
# niveau de log 0 pour le moment
#
loglevel 2
#
# En mode digi, on peut avoir un veritable tnc. param permet de passer les
# parametres tnc.
#
#param 1 20
#
# Adresses de broadcast. Chaque adresse figurant dans la liste sera relayee
# vers une des routes munies de l'indicateur idoine.
#
broadcast QST-0 NODES-0
#
# Definition des routes AX.25. Autant que necessaires
# Format :
# route <id destination> <ip destination> [indicateur]
#
# Indicateurs valides :
# b - broadcast
# d - route par defaut
#
route vk2sut-0 44.136.8.68 b
route vk5xxx 44.136.188.221 b
route vk2abc 44.1.1.1
#
#
</verb></tscreen>
<sect2><heading> Exécuter <em/ax25ipd/
<p>
<descrip>
<tag> Commencez par mettre en palce le fichier <tt>/etc/ax25/axports</tt>
<tscreen><verb>
# /etc/ax25/axports
#
axip VK2KTJ-13 9600 256 AXIP port
#
</verb></tscreen>
<tag> Exécutez <em/kissattach/ pour créer le port : </tag>
<tscreen><verb>
/usr/sbin/kissattach /dev/ptyq0 axip
</verb></tscreen>
<tag> Lancez <em/ax25ipd/ : </tag>
<tscreen><verb>
/usr/sbin/ax25ipd &
</verb></tscreen>
<tag> Testez la liaison AXIP : </tag>
<tscreen><verb>
call axip vk5xxx
</verb></tscreen>
</descrip>
<sect2><heading> Remarques concernant certains indicateurs des routes
<p>
"<tt/route/" met en place les destinations d'envoi de vos trames AX.25
encapsulées. Lorsque le démon <em/ax25ipd/ reçoit un paquet sur son
interface, il compare l'identifiant de destination avec chacun de ceux
présents dans sa table de routage. S'il trouve une correspondance, le paquet
est alors encapsulé dans un datagramme IP et transmis à l'hôte spécifié.
<p>
Deux indicateurs peuvent être ajoutés à n'importe quelle route du fichier
<tt/ax25ipd.conf/ :
<descrip>
<tag>b</tag> tout trafic à destination d'une adresse repérée par le mot-clef
"<tt/broadcast/" doit transiter par cette route.
<tag>d</tag> tout paquet ne correspondant à aucune autre route doit suivre
ce chemin.
</descrip>
<p>
L'indicateur de broadcast est très utile puisqu'il permet l'envoi
d'informations à destination de toutes les stations vers des stations AXIP :
les routes axip fonctionnent normalement en point-à-point et sont incapables
de gérer des paquets de diffusion générale.
<sect1><heading> Lier NOS à Linux au moyen d'un pipe
<p>
De nombreuses personnes aiment se servir de NOS sous Linux en raison de
la richesse fonctionnelle et de la facilité d'emploi auxquelles il les
a habituées. La plupart d'entre eux souhaitent que leur version de NOS
puisse dialoguer avec le noyau Linux de façon à offrir certaines des
possibilités de Linux aux radio-utilisateurs de NOS.
<p>
Brandon S. Allbery, alias KF8NH, a fourni les informations qui suivent
relatives à l'interconnexion de NOS avec le noyau Linux par l'intermédiaire
de tuyaux (pipe).
<p>
Linux et NOS gérant tous deux le protocole SLIP, il est possible de les
relier au moyen d'une liaison slip. Vous pourriez le faire grâce à deux
ports série et à un câble null-modem mais ce serait aussi coûteux
qu'inefficace. Comme d'autres systèmes de type Unix, Linux dispose de
tuyaux dits `pipes' (prononcer paillepeu). Il s'agit de pseudo-périphériques
qui émulent le comportement de tty usuels du point de vue
des logiciels en redirigeant le flux vers d'autres tuyaux. Pour les
utiliser, un programme doit d'abord ouvrir l'extrémité <bf>maître</bf>
d'un tuyau après quoi un second programme peut ouvrir la terminaison
<bf>esclave</bf>. Lorsque les deux bouts sont ouverts, les programmes
peuvent communiquer l'un avec l'autre en écrivant des caractères dans
les tuyaux comme s'il s'agissait de terminaux usuels.
<p>
Pour employer les tuyaux entre NOS et Linux, vous devez d'abord choisir
un tuyau. Le répertoire <tt>/dev</tt> en regorge : les extrémités maîtres
se nomment <tt>ptyq[1-f]</tt> et celles esclaves <tt>ttyq[1-f]</tt>.
Gardez à l'esprit qu'elles fonctionnent par paires et que si vous
utilisez <tt>/dev/ptyqf</tt> à un bout, vous devrez employer
<tt>/dev/ttyqf</tt> à l'autre.
<p>
Une fois le tuyau choisi, vous allouez la terminaison maître à Linux et
l'esclave à NOS (le noyau démarre le premier et l'extrémité maître doit
être la première ouverte). N'oubliez pas que le noyau Linux doit être
muni d'une adresse IP différente de celle de NOS. A mettre en place si
ce n'est pas déjà le cas.
<p>
Le tuyau se configure comme un périphérique série. Pour une liaison slip,
les commandes à exécuter seront donc du type :
<p>
<tscreen><verb>
# /sbin/slattach -s 38400 -p slip /dev/ptyqf &
# /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
mtu 1536 44.70.4.88
# /sbin/route add 44.70.248.67 sl0
# /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.70.248.67
</verb></tscreen>
<p>
Dans cet exemple, le noyau Linux dispose de l'adresse <tt>44.70.4.88</tt>
et NOS de l'adresse <tt>44.70.248.67</tt>. La commande <em>route</em> de
la dernière ligne indique simplement au noyau Linux qu'il doit router tous
les datagrammes à destination d'amprnet via le lien slip créé par la
commande <em>slattach</em>. Vous pouvez par exemple copier ces commandes
dans le fichier <tt>/etc/rc.d/rc.inet2</tt> (selon votre installation)
après toutes les autres commandes de configuration réseau afin que la
liaison slip apparaisse automatiquement à la réinitialisation du système.
Remarque : on ne gagne rien à utiliser <em>cslip</em> au lieu de
<em>slip</em>. Au contraire, les performances diminuent de par la nature
purement virtuelle du lien (on passe plus de temps à compresser les
en-têtes qu'à transmettre toutes les données).
<p>
Essayez les commandes suivantes pour configurer la terminaison du côté
NOS :
<p>
<tscreen><verb>
# you can call the interface anything you want; I use "linux" for convenience.
attach asy ttyqf - slip linux 1024 1024 38400
route addprivate 44.70.4.88 linux
</verb></tscreen>
<p>
Ces commandes créent un port slip nommé `linux' sur l'extrémité esclave
du tuyau et ajoutent une route qui y pointe. Une fois NOS démarré, vous
devriez pouvoir exécuter des ping et des telnet de NOS vers Linux et
vice-versa. Si ce n'est pas le cas, vérifiez encore une fois que vous
ne vous êtes trompé nulle part, surtout au niveau des adresses et des
tuyaux.
<sect><heading> Où trouver de l'information sur... ?
<p>
Ce document suppose une certaine expérience de la transmission paquets
par radio, et, comme ce n'est pas forcément le cas, j'ai regroupé un ensemble
de références à d'autres informations utiles.
<p>
<sect1> Transmission paquets par radio
<p>
Vous trouverez des informations générales sur la transmission paquets par
radio sur les sites suivants :
<list>
<item><url name="American Radio Relay League" url="http://www.arrl.org/">,
<item><url name="Radio Amateur Teleprinter Society"
url="http://www.rats.org/">
<item><url name="Tucson Amateur Packet Radio Group"
url="http://www.tapr.org/">
</list>
<p>
<sect1> Documentation sur les protocoles
<p>
<list>
<item> AX.25, NetRom - Jonathon Naylor a regroupé de nombreux documents sur le
sujet qui sont disponibles via : <url name="ax25-doc-1.0.tar.gz"
url="ftp://ftp.pspt.fi/pub/ham/linux/ax25/ax25-doc-1.0.tar.gz"
</list>
<p>
<sect1> Documentation sur le matériel
<p>
<list>
<item> Informations sur la carte <bf>PI2</bf> :
<url name="Ottawa Packet Radio Group" url="http://hydra.carleton.ca/">.
<item> Informations sur le matériel <bf>Baycom</bf> :
<url name="Baycom Web Page" url="http://www.baycom.de/">.
</list>
<sect><heading> Groupes de discussion radioamateurs et Linux
<p>
Il existe plusieurs endroits où parler de Linux ou de radio amateurisme.
Par exemple dans les groupes de discussion <tt>comp.os.linux.*</tt>, sur la
liste de diffusion <tt>HAMS</tt> de <tt>vger.rutgers.edu</tt>. Mentionnons
également la liste <tt>tcp-group</tt> sur <tt>ucsd.edu</tt> (origine des
discussions TCP/IP radio amateur) et le canal <tt>#linpeople</tt> sur le
réseau irc <tt>linuxnet</tt>.
Pour vous abonner à la liste de diffusion Linux <bf>linux-hams</bf>, envoyez
un courrier à :
<tscreen><verb>
Majordomo@vger.rutgers.edu
</verb></tscreen>
avec dans le corps du message la ligne suivante :
<tscreen><verb>
subscribe linux-hams
</verb></tscreen>
La ligne de sujet sera ignorée.
<p>
La liste de diffusion <bf>linux-hams</bf> est archivée aux adresses :
<url url="http://hes.iki.fi/archive/linux-hams/"
name="zone.pspt.fi">
et :
<url url="http://zone.oh7rba.ampr.org/archive/linux-hams/"
name="zone.oh7rba.ampr.org">.
Les débutants sont priés de commencer par utiliser les archives. Celles-ci
contiennent des réponses à l'essentiel des questions courantes.
<p>
Pour souscrire à la liste <tt>tcp-group</tt>, envoyez un courrier à l'adresse :
<tscreen><verb>
listserver@ucsd.edu
</verb></tscreen>
avec dans le corps du message la ligne :
<tscreen><verb>
subscribe tcp-group
</verb></tscreen>
<bf>Remarque :</bf> n'oubliez pas que <tt>tcp-group</tt> a pour thème les
discussions autour de l'emploi des protocoles évolués parmi lesquels figure
TCP/IP. <em> Les questions spécifiques à Linux n'y ont normalement pas leur
place. </em>
<sect><heading> Remerciements
<p>
Les personnes dont les noms suivent ont contribué à l'élaboration de ce
document (l'ordre n'a pas d'importance): Jonathon Naylor, Thomas Sailer,
Joerg Reuter, Ron Atkinson, Alan Cox, Craig Small, John Tanner,
Brandon Allbery, Hans Alblas, Klaus Kudielka, Carl Makin.
<sect><heading> Copyright.
<p>
Copyright (c) 1996 Terry Dawson.
La distribution de ce document doit se conformer aux termes de la
licence LDP tels que définis à l'adresse :
<htmlurl
url="http://sunsite.unc.edu/LDP/COPYRIGHT.html"
name="sunsite.unc.edu/LDP/COPYRIGHT.html">.
<p>
<!--
Ce HOWTO est une documentation libre et gratuite ; vous pouvez la
redistribuer et/ou la modifier selon les termes de la licence LDP.
Ce document est distribué dans l'espoir qu'il rendra service, cela
sans aucune garantie ; sans même une garantie implicite de possibilité
de commercialisation pour un objectif précis.
Consultez la licence LDP pour de plus amples détails.
-->
</article>
