<!doctype linuxdoc system>
<article>
<title>Modems-HOWTO
<author>Jean Michel VANSTEENE <vanstee@worldnet.net>
<date>13 Février 1996
<abstract>
Le modem est devenu aujourd'hui un produit à la mode. Que ce soit
pour l'accès à Internet ou pour se connecter chez un
particulier qui laisse bénévolement sa machine disponible, il
faut un modem. Or, cet appareil, d'apparence fort simple, cache des choses
très sophistiquées et son emploi peut engendrer bien des
soucis. J'ai constaté d'ailleurs que bon nombre d'utilisateurs se
posaient des questions à son propos. (Et ceux qui ne s'en posent pas
ont parfois des problèmes qu'ils seraient aptes à
résoudre par eux-même, s'ils connaissaient un peu son
fonctionnement.)
Ce document n'est ni un HOWTO ni une FAQ, ce qui est à priori
inhabituel pour un document Linux. J'ai longuement réfléchi
avant de me lancer dans cette aventure. Parmi mes priorités, la
première a été d'être clair et de ne pas tomber
dans le genre cours magistral...
Le but de ce document est en fait d'éclaircir un peu des notions
<it>dont on a entendu parler</it> : bande passante, bits/seconde,
baud, modulation, interface série, connexions à
vingt-huit-huit ...
Après avoir lu ce document, de deux choses l'une : soit vous
vous dites <it>c'est imbitable</it>, et là vous sautez sur votre
courrier-é préféré pour m'engueu... me le dire,
soit vous pensez que ca vous a apporté quelque-chose et là,
vous sautez sur votre courrier-é... pour me le dire. En tout cas,
toute remarque sera la bienvenue, comme d'habitude.
</abstract>
<!-- Table des matieres -->
<toc>
<sect>
Introduction
<p>
La communication a toujours été, est et sera toujours un
échange de signaux entre un émetteur et un récepteur.
Afin d'avoir les idées claires sur ce que nous allons aborder,
décomposons les différentes étapes de la
communication. Le meilleur modèle que nous allons prendre est
l'homme qui l'utilise depuis fort longtemps.
<p>
<bf/Première étape /: prenons un homme, bien rasé
de préférence, propre et prêt à se rendre au
travail. Justement il a un mot à dire à sa femme avant de
partir. C'est l'information à transmettre.
<p>
<bf/Deuxième étape /: comment la transmettre. Si elle
est là, il crie (bon, il parle), sinon il écrit le message
sur un bout de papier. Notre homme est donc capable (voyez-vous ça,
il est à peine 7h30 du matin !) de coder son information en
fonction de la manière dont il transmet son message.
<p>
Pour communiquer, nous utilisons des éléments de base dont
l'ensemble forme l'alphabet. Une succession de ces éléments
définit un vocabulaire. En fait il s'agit ni plus ni moins que d'un
code, complexe certes, mais compréhensible par tous ceux qui
l'adoptent. Moins il est ambigu, plus il est précis. (Vous pouvez
essayer de donner trois sens différents à cette phrase pour
comprendre que notre langue est parfois ambiguë : il est
énormément bête .) Pour s'exprimer, il est
ensuite capable de découper une suite de mots
(éléments continus) en phonèmes
(éléments discontinus), que le récepteur saura
réassembler.
<p>
En informatique, l'information de base est <bf/binaire/, donc codée
sur deux valeurs logiques que l'on note habituellement 0 et 1. C'est le
code sans doute le plus élémentaire qui soit. Aussi il existe
un certain nombre de codes intermédiaires. Nous citerons par exemple
le code ASCII, permettant de coder les lettres et chiffres.
<p>
<bf/Troisième étape /: sa femme découvre le
message (ou l'entend). Elle est capable de le reconstituer. Les lettres
(respectivement les phonèmes) forment des mots qui forment des
phrases qui forment le message. Ouf ! On y est.
<sect1>
Résumons un peu
<p>
<bf/Découpage horizontal/. La communication n'est possible que s'il
existe un code commun. À tout niveau il faut s'assurer non seulement
que le code employé a un sens, mais en plus qu'il a le même
pour l'émetteur et le récepteur. On parle alors de
<it/protocole/. Au niveau le plus bas, un signal est utilisé comme
un moyen de communication. Il transporte en effet un message sous une
forme particulière appelé <it/codage/ ou <it/modulation/. Un
signal a une nature physique et un modèle mathématique. Nous
nous étendrons davantage sur sa nature que sur le modèle qui,
bien qu'intéressant, nous amènerait trop loin. Le signal
s'appuie sur un support.
<p>
<bf/Découpage vertical/. De l'idée au code
employé : plusieurs niveaux de traitement sont utilisés
pour transformer un message complexe en éléments plus simples
aptes à être véhiculés et compris par une
entité homologue.
<p>
Or s'il y a un signal, il faut forcément un support de transmission,
permettant de le véhiculer d'un point à un autre. Nous
verrons cela un peu plus loin. Celui qui nous intéresse concerne les
transmissions téléphoniques.
<p>
Voici donc jetées les bases de la communication. Nous allons
maintenant éclaircir un peu tout cela dans les différentes
parties qui vont suivre. La première étape consiste à
consolider les bases sur les signaux, ensuite nous verrons leur
transmission.
<sect>
Un peu de théorie du signal...
<p>
La voix est un bon exemple de signal permettant de véhiculer une
information. Ce signal est caractérisé par sa <bf/bande
passante/, c'est-à-dire le domaine de fréquences sur lequel
elle peut s'étendre. En général cette bande est
continue et comprise entre 30 et 15000 Hz. Ce signal est de type
sinusoïdal.
Sans entrer dans des détails mathématiques, disons qu'un
signal est composé d'une fréquence principale et
d'harmoniques. Il est possible d'en donner une représentation
mathématique grâce aux séries de Fourier, mais nous
n'irons pas plus loin. Disons simplement que ce signal est appelé
signal <sq/analogique/, parce qu'il peut prendre n'importe quelle valeur de
façon continue entre deux instants : le signal est
<sq/modulé/.
<sect1>
Les supports de transmission
<p>
Un signal quel qu'il soit, n'a d'intérêt que s'il peut
être transporté. Il faut savoir qu'un système de
transmission n'est jamais en mesure d'émettre des signaux sans leur
faire subir de déformations : selon leur nature, on parle de
distorsion, d'affaiblissement, de diaphonie ... Comme nous le verrons
plus loin, les lignes téléphoniques ne font pas exception
à cette règle.
<p>
Chaque type de support est caractérisé entre autres par son
aptitude à transmettre un signal plus ou moins fidèlement. De
nombreux supports sont utilisés en transmission de
données : les supports avec guide physique (câbles,
fibres, ...) et les supports sans guide physique (ondes radio, ondes
lumineuses). Pour donner une idée, de la qualité des
supports, disons que les câbles électriques à paires
torsadées sont les moins fiables, suivis par les câbles
coaxiaux. Les fibres optiques offrent actuellement le meilleur compromis
fiabilité/performance.
<sect>
Les télécommunications analogiques et numériques
<p>
<sect1>
Les télécommunications analogiques
<p>
C'est un mode de communication utilisé depuis très longtemps
notamment dans la technologie téléphonique. Il s'agit en
effet d'une activité beaucoup moins consommatrice de ressources,
tant financières que technologiques que la transmission
numérique. On n'est pas tout à fait prêt à
pouvoir s'en passer.
<sect1>
Le signal téléphonique
<p>
À l'origine, le téléphone a été
conçu pour transmettre la voix. Malheureusement, il n'est pas
possible, étant donné le support utilisé, de
véhiculer le signal complet, c'est-à-dire l'ensemble des
fréquences le constituant. Le domaine de fréquences (on
parle de largeur de bande) que peuvent transmettre les lignes
téléphoniques est officiellement compris entre 300 et 3400
hertz<footnote>Les <it/codecs/ (codeurs-décodeurs) modernes
utilisés dans les centraux téléphoniques actuels ont
une bande passante de l'ordre de 200 à 3700 Hz et la qualité
des lignes des abonnés s'en trouve généralement
améliorée.</footnote>. On applique donc au signal de
départ un <it/filtre passe-bande/ qui restreint l'espace de
fréquence attribué à la transmission du signal sur
cette liaison. Ceci correspond heureusement à 90% de netteté
de la voix.
<P>
Selon le principe bien admis que tout traitement a un coût, le plus
simple et le moins coûteux en télécommunications est de
transmettre le signal avec le moins de transformations possible. C'est
bien ce qui se passe pour la voix par téléphone. Les seules
transformations sont d'ordre analogique comme l'amplification par exemple.
<sect1>
Les télécommunications numériques
<p>
Nous avons déjà évoqué
précédemment que le fonctionnement de nos chers ordinateurs
était fondé sur la seule information binaire. Celle-ci est
représentée, dès lors qu'il s'agit de la visualiser
(oscilloscope) ou de la transporter, par un signal rectangulaire à
deux niveaux. <p>
Pour transporter un tel signal, le plus simple et le moins coûteux
consiste à lui faire subir le moins de traitement possible, voire
à le transporter tel quel. On imagine aisément que pour
transmettre ce signal sur un support, il suffise de définir deux
signaux électriques représentant les niveaux logiques 0 et 1.
De plus ce type de transmission offre des performances
considérablement supérieures à la transmission
analogique, ceci pour deux raisons.
La première est un faible taux d'erreurs. En effet, alors qu'en
transmission numérique, les signaux sont transmis avec des tensions
d'amplitude variable, en transmission numérique le nombre de niveaux
est limité. Les signaux parasites s'infiltrant dans un signal
analogique sont donc très difficiles à supprimer et
engendrent des erreurs. En transmission numérique, les
défauts sont plus facilement repérables et les
équipements régénèrent plus facilement un
signal parasité ou affaibli.
La deuxième raison tient au fait que l'on sait mieux traiter une
information numérique. Ainsi, en utilisant les méthodes de
multiplexage, de compression, l'acheminement des données se fait
beaucoup plus rapidement. De plus le coût du matériel de
traitement diminue considérablement.
<sect1>
Alors pourquoi l'analogique ?
<p>
Cette question est bien entendu la première que l'on se pose
maintenant. La réponse tient en quelques mots :
essentiellement pour des raisons financières. Lorsque les
ordinateurs sont organisés en petits groupes fermés,
l'infrastructure à mettre en place pour les relier est bien
sûr numérique. Mais dès lors que les communications
s'établissent sur de grandes distances, elles doivent empreinter
l'infrastructure existante, qui est analogique. L'évolution se fait
lentement vers le tout numérique, Numéris en est l'exemple
prometteur.
<sect1>
De l'analogique au numérique et réciproquement
<p>
Puisqu'il faut s'adapter à un monde fait de numérique et
d'analogique, il faut savoir passer de l'un à l'autre. C'est
essentiellement ce qui va se passer avec les modems. Faisons d'abord un
point rapide sur les méthodes de conversion entre l'analogique et le
numérique.
<sect2>
De l'analogique au numérique
<p>
L'information de départ est représentée par un signal
qui, si on le transforme en tensions électriques, peut prendre une
infinité de valeurs (dans un intervalle fini, heureusement !)
entre deux instants. Pour le transcrire dans un monde fait d'un nombre
limité de niveaux significatifs, il faut le coder. Un des principes
de codage les plus simples consiste à prélever à
intervalle régulier la valeur de la tension, puis de la
représenter en binaire sur 7 ou 8 bits. Le
prélèvement est usuellement appelé
<it/échantillonnage/ et la fréquence d'échantillonnage
correspond au nombre d'échantillons prélevés par
seconde. Un codeur-décodeur prélève en
général 8000 échantillons par seconde.
<sect2>
Du numérique à l'analogique
<p>
A l'inverse, la transformation d'une information numérique en
analogique consiste à moduler un signal de base en fonction de cette
information. C'est le rôle du modulateur-démodulateur (modem).
Considérons maintenant ce signal de base. S'agissant d'un signal
analogique, c'est donc une sinusoïde dont la fréquence peut
varier, dans le cas qui nous intéresse, de 1000 à 2000
hertz. C'est la porteuse. La modulation de ce signal va consister ensuite
à en faire varier un ou plusieurs paramètres : la
<bf/phase/, <bf/l'amplitude/ ou la <bf/fréquence/. <p>
La modulation d'amplitude consiste à modifier l'amplitude de la
porteuse, selon l'information binaire à transmettre. Par exemple
une valeur de l'amplitude est attribuée au 0 et une autre au 1.
<p>
La modulation de fréquence correspond à la même notion,
mais ici les deux valeurs sont représentées par des
fréquences différentes.
<p>
Enfin, la modulation de phase, consiste à faire varier la phase de
la porteuse, de 45, 135, 225 ou 315 degrés par exemple.
<p>
La <bf/rapidité de modulation/ caractérise la vitesse
à laquelle ces changements s'effectuent. C'est la
caractéristique essentielle qui permet de définir la bande
passante.
<p>
Arrêtons-nous là un instant pour évoquer maintenant la
notion de débit. Il est en effet facile d'imaginer pouvoir faire
varier un signal à volonté, mais ce serait ne pas tenir
compte de certaines caractéristiques physiques des supports qui nous
contraignent fortement.
<sect1>
Des bits et des débits
<P>
Une des valeurs caractéristique des supports de transmission est le
débit maximum qu'ils peuvent supporter. Comment s'empêcher de
comparer un support à une route. Le nombre maximum de
véhicules qu'une autoroute est capable de supporter par heure est
très supérieur à celui d'une route
départementale (même si vous n'aimez pas les routes
départementales, mais ceci est une autre histoire ...).
<P>
En ce qui concerne les supports de transmission, leur débit maximum
est directement lié à la largeur de la bande passante. Chose
promise, chose due, pas trop de mathématiques ici. Mais il est
impossible de ne pas parler de deux valeurs fondamentales qui vont
permettre de comprendre ce qui se passe avec les modems : ce sont le
<bf/débit binaire maximum/ et la <bf/capacité de transmission
maximale/.
<sect2>
Le débit binaire maximum
<p>
Sur un canal de transmission dont la bande passante est B, il est
montré qu'un signal peut être entièrement
reconstitué à l'arrivée, si on le transmet en prenant
2B échantillons par seconde. Le débit maximum s'écrit
alors :
<tscreen><verb>
Dmax = 2B
</verb></tscreen>
Si, de plus, le signal peut prendre plus de deux valeurs significatives, la
formule se généralise en :
<tscreen><verb>
Dmax = 2B log V
2
</verb></tscreen>
où <bf/V/ correspond au nombre de niveaux significatifs (ou
états) que peut prendre le signal : c'est sa <bf/valence/. Par
exemple, V=4 si le signal peut prendre les valeurs +10 volts,
+5 volts, -5 volts et -10 volts.
Ceci pour vous montrer qu'en théorie, sur une ligne
téléphonique dont la bande passante est de 3000 hertz, le
débit maximum est de 6000 bits/s avec deux niveaux significatifs (un
pour le 0, un pour le 1), 12000 bits/s avec quatre niveaux, etc. Le
débit maximum est théoriquement infini.
<sect2>
La capacité de transmission maximale
<p>
Un des inconvénients supplémentaires des supports est le
<bf/bruit/. Or la quantité de bruit présente sur une ligne
s'exprime par rapport à la puissance utile du signal transmis :
c'est le <bf>rapport signal/bruit</bf>. Plus ce rapport est grand,
meilleure est la qualité. La capacité de transmission
maximale est une fonction de ce rapport. Pour une ligne
téléphonique, cette capacité maximale atteint 30000
bits/s. Cela signifie bien que sur ces lignes <bf>on ne peut transmettre
à plus de 30000 bits/s</bf><footnote>C'est bien une capacité
maximale physique, à ne pas confondre avec des débits
logiques après compression de données.</footnote> quels que
soient la valence et la fréquence du signal. C'est une limite au
débit binaire maximum.
<sect><heading><label id="sec-modems">
Le modem
<p>
Le rôle du modem est d'adapter les signaux rectangulaires de
données, que le réseau téléphonique ne peut pas
transmettre tels quels, en signaux transmissibles par ce réseau.
Il a en fait deux fonctions :
<itemize>
<item>
un rôle d'<bf/adaptation du signal/ aux lignes du réseau
utilisé, c'est-à-dire de modulation et de
démodulation ;
<item>
un rôle de <bf/dialogue/ avec l'équipement informatique auquel
il est relié.
</itemize>
Il tient donc exactement le même rôle fonctionnel qu'une couche
de communication (TCP, par exemple). Il possède une <bf/interface/
permettant un dialogue avec un utilisateur se trouvant à un niveau
supérieur. Ici il s'agit d'une interface physique (y compris
électrique). Il communique avec une entité paire (un autre
modem) selon un <bf/protocole/.
La structure interne d'un modem est décrite ci-dessous :
<verb>
+-----+ +--------+ +-------------+ +----------------+
| J +----->| codeur +-------> | modulateur +------>| |
| O | +--------+ +-------------+ | |
| N | | |
| C | | transformateur |
| T | | |
| I | | ligne |
| O | +----------+ +--------------+ | |
| N |<-----+ decodeur |<------+ demodulateur |<-----| |
+-----+ +----------+ +--------------+ +----------------+
</verb>
Les paramètres caractérisant un modem sont :
<itemize>
<item>
le <it>débit d'information</it> en bits/s ;
<item>
le <it>mode de transmission</it> : synchrone ou asynchrone ;
<item>
le <it>support de transmission utilisé</it> : réseau ou
ligne spécialisée ;
<item>
le <it>mode de couplage</it> à la ligne : électrique ou
acoustique.
</itemize>
Nous aborderons assez rapidement l'ensemble de ces paramètres, selon
l'utilisation que nous aurons à en faire. La notion de débit
devrait maintenant être assimilée.
<P>
Penchons-nous rapidement sur les modes et les supports de transmission
utilisés. Voyons ensuite plus précisément le
rôle d'adaptation du signal du modem, puis le dialogue qui met en jeu
la jonction et la ligne.
<p>
Commençons par définir un vocabulaire commun.
<sect1><heading><label id="sec-vocab">
Vocabulaire
<p>
Un <bf/avis/ est une recommandation édictée par l'U.I.T
(Union Internationale des Télécommunications), organisation
intergouvernementale compétente en télécommunications.
Les avis ont valeur de norme au sein de l'Europe, puisque les organismes de
Télécom nationaux ont encore le monopole. Les
recommandations sont issues de travaux de diverses commissions
d'études et sont adoptées lors des assemblées
pleinières (délai de l'ordre de neuf mois, étant
donné l'évolution rapide des technologies). La section <ref
id="sec-norme" name="Etat actuel de la normalisation"> décrit les
différents avis actuellement en vigueur.
<p>
Dans sa normalisation, l'U.I.T définit l'équipement
informatique comme un <bf/ETTD/ (<it>Équipement Terminal de
Traitement de Données</it>) et le modem comme un <bf/ETCD/
(<it>Équipement Terminal de Circuit de Données</it>). La
connexion d'un équipement informatique à un modem, par
exemple, est réalisée par l'intermédiaire d'une
<bf/jonction/ ou <bf/interface/.
<p>
On appelle half-duplex (bidirectionnel à l'alternat), une
transmission s'effectuant dans un seul sens à la fois. On appelle
full duplex (bidirectionnel simultané), une transmission pouvant
s'effectuer dans les deux sens en même temps. Ces transmissions
peuvent avoir lieu indifféremment sur liaison 2 ou 4 fils.
<sect1>
Le mode de transmission
<p>
Une transmission de donnée est toujours liée au facteur
temps. Dans les transmissions en série qui constituent la
majorité des transmissions, l'émetteur et le récepteur
doivent travailler à la même cadence. Dans le mode
<bf/synchrone/, ils sont calés sur le même rythme grâce
à des signaux d'horloge émis avant la transmission. Dans le
mode <bf/asynchrone/, l'horloge du récepteur n'est
déclenchée puis arrêtée que sur réception
de bits de début et de fin. On les appelle bits de <bf/start/ et de
<bf/stop/. Ce mode, bien que moins performant, est le plus utilisé
actuellement dans les communications à travers le réseau
public.
<sect1>
Le support de transmission ou ligne
<p>
Un modem est utilisable principalement sur deux types de supports : le
<bf/réseau commuté/ ou la <bf/ligne
spécialisée/. Sur chaque type de support, les liaisons
peuvent être à deux ou quatre fils.
<p>
Dans le cas qui nous intéresse, le modem est relié au
réseau téléphonique commuté et la liaison est
à deux fils. Nous l'utilisons soit en half duplex, soit en full
duplex selon l'avis (voir définition de ce mot au paragraphe <ref
id="sec-vocab" name="Vocabulaire">.
<p>
A ce propos, réfléchissons un peu sur l'utilisation qui est
faite actuellement du Réseau Téléphonique
Commuté (appelé aussi RTC). Nous l'utilisons bien souvent en
full duplex sur liaison deux fils (avis V.32 ou V.34). Lorsqu'on utilise
des lignes à quatre fils, il est facile d'imaginer que l'on consacre
deux fils à chaque sens de transmission. Pour chaque sens,
considérant les vitesses de modulations maximales possibles, on
conçoit qu'il faut combiner plusieurs types de modulations pour
obtenir des débits maintenant courants de l'ordre de 28800 bits/s.
Or le RTC n'utilise que <bf/deux/ fils. Pour travailler en full-duplex
à des débits relativement faibles (en fait jusqu'à
l'avis V22 bis), il était possible de partager la bande de
fréquence en deux moitiés, une pour chaque sens. Avec les
débits employés actuellement ce n'est plus possible. Pour
travailler en full-duplex à d'importants débits, il est fait
appel à des algorithmes complexes dits <sq/de suppression
d'écho/ (proche et lointain). Imaginez le travail à
réaliser : chaque modem reçoit les données
envoyées par le distant mélangées à ses propres
données. Le tout est encore pollué par de
l'écho ! Et pour compliquer le tout, tout ceci varie dans le
temps, et bien sûr d'une communication à l'autre.
<P>
Vous comprendrez donc qu'avec une telle utilisation du RTC, les modems
soient continuellement soumis à rude épreuve pour ce qui est
de la correction, ceci pouvant conduire à des débits
variables selon le moment.
<sect1>
L'adaptation du signal
<p>
Nous avons vu aux sections précédentes ce qu'étaient
une modulation et un débit. Rassemblons maintenant un peu toutes ces
idées. Bien souvent, c'est sur ce point délicat que les
esprits se perdent. Nous avons vu que la rapidité de modulation est
une caractéristique essentielle de la bande passante. Plus cette
rapidité est grande, plus la bande passante demandée est
large. Sur le réseau téléphonique, la bande maximale
officielle est de 3100 hertz (300 à 3400 Hz). Dans les centraux
téléphoniques modernes, elle va jusqu'à 3500 Hz.
<p>
Pour bien comprendre le mécanisme de l'adaptation du signal,
imaginez maintenant que nous disposions d'un appareil électrique
capable d'émettre quatre niveaux de tensions possibles.
Les données à transmettre sont quant à elles toujours
présentées sous forme d'un flot ininterrompu (ou presque)
d'informations binaires.
L'idée serait de regrouper les bits deux par deux et de les faire
passer par ce dispositif, afin d'obtenir en sortie le niveau de tension
correspondant. Un tel signal en sortie est dit de <bf/valence/ 4. Plus
généralement, la valence d'un signal est le nombre
d'états qu'il peut prendre. Cette transformation du signal est
appelée <bf/codage/.
<p>
Afin d'adapter ce signal de sortie au support, il faut maintenant le
moduler, par exemple en choisissant d'effectuer une modulation de phase.
Etant donnée sa valence, nous avons besoin de quatre
décalages de phase.
A chaque fois que <bf/deux/ bits se présentent, il est possible
d'effectuer <bf/une/ modulation. A l'autre bout, l'équipement est
capable de regénérer deux bits. Le débit (en
<bf>bits/s</bf>) est donc bien double de la vitesse de modulation
(exprimée en <bf/bauds/).
<p>
<sect2>
Exemple
<p>
Vous configurez un modem à 4800 bits par seconde (V.27 ter).
Que va-t-il se passer ? Selon cette norme, le modem va
réaliser une modulation de phase différentielle octovalente.
Il va donc regrouper les bits par trois (<bf/tribits/) pour moduler le
signal. La vitesse de modulation est donc de 1600 bauds et le débit
de 4800 bits/seconde. Pour obtenir un débit de 9600 bits par
seconde, il faudra combiner un autre type de modulation. La section <ref
id="sec-modul" name="Débits et modulations"> présente
l'essentiel des modulations utilisées dans les différentes
normes actuelles.
<sect2>
Résumé
<p>
L'adaptation du signal peut se faire de trois manières :
<itemize>
<item>
par une simple modulation appropriée ;
<item>
par un codage puis une modulation ;
<item>
par un simple codage. Ce type d'adaptation est présent dans certains
modems dits <sq>bande de base</sq> qui transmettent directement ce code sur
la ligne. Ce ne sont pas ceux que nous utilisons couramment.
</itemize>
La rapidité de modulation s'exprime en <bf/bauds/. Elle correspond
au nombre de changements d'états du signal par seconde sur la ligne
de transmission. Une rapidité de <it/b/ bauds ne correspond pas
forcément à <it/b/ bits/s sur la ligne. Une configuration
binaire (un ou plusieurs bits selon la valence) correspond à un
état du signal.
<sect1>
Le dialogue
<p>
Intéressons-nous maintenant au dialogue entre l'équipement
informatique et la jonction.
<sect2>
La jonction série
<p>
La jonction spécifie les caractéristiques mécaniques,
électriques et fonctionnelles des signaux. Bien entendu ces
jonctions sont normalisées (voir plus loin les tableaux
récapitulatifs sur l'état actuel de la normalisation) et
celle qui nous intéresse plus particulièrement est
référencée sous le nom V.24 par l'U.I.T, sensiblement
équivalente de la norme RS-232C définie par
l'E.I.A<footnote>Electronic Industries Association.</footnote>.
<p>
Voici une description des signaux de l'interface V.24 les plus couramment
utilisés :
<tscreen><verb>
+------+-----------+-----------+--------+------+--------------------------------+
| Code | No broche | No broche | RS-232 | V.24 | Signification |
| | ISO 2110 | DB 9 | | | |
+------+-----------+-----------+--------+------+--------------------------------+
| 101 | 1 | | PG | TP | Terre de protection |
| | | | | | |
| 102 | 7 | 5 | SG | TS | Terre de signalisation |
+------+-----------+-----------+--------+------+--------------------------------+
| 103 | 2 | 3 | TD | ED | Emission de donnees |
| | | | | | |
| 104 | 3 | 2 | RD | RD | Reception de donnees |
+------+-----------+-----------+--------+------+--------------------------------+
| 105 | 4 | 7 | RTS | DPE | Demande pour emettre |
| | | | | | |
| 106 | 5 | 8 | CTS | PAE | Pret a emettre |
| | | | | | |
| 107 | 6 | 6 | DSR | PDP | Poste de donnees pret |
| | | | | | |
| 108 | 20 | 4 | DTR | TDP | Terminal de donnees pret |
| | | | | | |
| 109 | 8 | 1 | DCD | DS | Detection du signal de ligne |
+------+-----------+-----------+--------+------+--------------------------------+
| 125 | 22 | 9 | RI | IA | Indicateur d'appel |
+------+-----------+-----------+--------+------+--------------------------------+
</verb></tscreen>
Brochage des prises côté soudures :
<tscreen><verb>
+-----------+ +---------------------------------------+
| 5 4 3 2 1 | | 13 12 11 10 9 8 7 6 5 4 3 2 1 |
\ 9 8 7 6 / \ 25 24 23 22 21 20 19 18 17 16 15 14 /
`---------' `-------------------------------------'
DB 9 ISO IS 2110
</verb></tscreen>
<sect2><heading><label id="sec-dialogue">
Le dialogue proprement dit
<p>
Prenons deux postes de travail équipés d'un modem chacun et
souhaitant communiquer.
<p>
Nous passerons rapidement sur le fait que les équipements doivent
être reliés à la masse. Ceci est réalisé
grâce au circuit 101. D'autre part, il est nécessaire de
définir une référence de signalisation : c'est le
rôle du circuit 102.
<p>
Dès sa mise sous tension, l'ETTD présente un état
logique <sq/1/ sur le circuit 108 : <it/Terminal de Données
Prêt/ (DTR). Dès la mise sous tension de l'ETCD, celui-ci
présente l'état <it/Poste de Données Prêt/ (DSR)
correspondant à un état logique <sq/1/ sur le circuit 107,
assurant ainsi que le modem est sous tension et connecté à la
ligne.
<p>
L'ETTD ayant des données à émettre, demande à
émettre. Il présente sur la jonction l'information
<it/Demande Pour Émettre/ (RTS) sur le circuit 105. Ceci valide le
modulateur de l'ETCD qui émet alors une porteuse.
<p>
Du coté appelé, l'ETCD détecte la présence de
la porteuse sur la ligne de transmission et le signale à l'ETTD sur
le circuit 109 : <it/Détection de signal/ (porteuse). Les
circuits 107 et 108 auront été initialisés au
préalable comme ci-dessus.
<p>
L'ETTD ayant signalé son intention d'émettre sur le circuit
105 reçoit en réponse peu de temps après le signal
<it/Prêt À Émettre/ (CTS) sur le circuit 106.
Les données peuvent ensuite circuler via les circuits 103 et 104.
<sect2>
Le contrôle de flux
<p>
Lorsqu'un émetteur émet de façon systématique
plus de données que le récepteur ne peut en accepter, il se
pose alors un problème qui ne peut être résolu que
grâce au mécanisme de <it>contrôle de flux</it>.
Le contrôle de flux peut être de différents types :
<descrip>
<tag/logiciel/
Le modem insère des caractères de contrôles dans le
flot de données circulant entre l'ETCD et l'ETTD : <bf/XOFF/
pour arrêter l'envoi et <bf/XON/ pour le reprendre.
<tag/matériel/
Généralement appelé <bf>CRTSCTS</bf>, il met en oeuvre
l'emploi des circuits 105 (RTS) et 106 (CTS). Ce symbole est en fait le
nom donné à la constante du fichier d'inclusion
<it/termios.h/.
</descrip>
Le fonctionnement du contrôle de flux matériel pendant la
transmission peut se résumer ainsi :
<P>
Avant d'émettre, le terminal doit lever son signal RTS (Request To
Send). À partir de ce moment, le modem, s'il est en mesure
d'émettre, lève le signal CTS (Clear To Send). Lorsque le
buffer du modem est plein, le modem descend CTS. Il le remonte
ensuite. Dans l'autre sens de transmission, lorsque le buffer du terminal
est plein, le terminal descend RTS.
<sect1>
La connexion au réseau téléphonique commuté
<p>
Maintenant, plusieurs questions se posent, et j'imagine que parmi celles
que vous vous posez il y a :
<itemize>
<item>
et sous Linux, le fonctionnement est-il identique ?
<item>
à quel moment le numéro du correspondant a t-il
été composé ?
<item>
mon modem est configuré en réception/émission, comment
ça marche ?
<item>
etc.
</itemize>
Nous allons maintenant tenter de répondre.
<p>
Eclaircissons un peu les choses. Le dialogue que nous venons de voir
concerne le dialogue <it/théorique/ ETTD-ETCD et ETCD-ETTD sans se
soucier d'éventuelles contraintes pouvant provenir du système
d'exploitation. Il est toujours vrai. Néanmoins, il ne suffit pas
forcément pour qu'une communication soit établie, notamment
via le RTC. Nous allons étudier ce fonctionnement point par point
en prenant un bon système d'exploitation (<bf/Linux/, mais ce n'est
qu'un exemple), un bon port série et du courage. Vous
continuez ?
<p>
Tout d'abord, nous avons vu qu'une communication commençait toujours
par le premier échange DTR/DSR, ou si vous préférez
108/107. La montée du circuit 108 est réalisée sous
Linux à l'ouverture du port série (ex. <tt>fopen
("/dev/ttyS0", ...)</tt>). Cela se voit très bien sur un modem
externe, le voyant TR est allumé. La réponse du modem par le
circuit 107 est un peu différente. Dans la section <ref
id="sec-dialogue" name="Le dialogue proprement dit">, pour des raisons de
simplicité, nous supposions que le modem répondait sur le
circuit 107 après un délai très bref,
c'est-à-dire qu'il était instantanément
connecté à la ligne.
Cette réponse est maintenant conditionnée par la connexion
à la ligne via le réseau téléphonique
commuté.
<p>
<sect2>
Initialisation du modem
<p>
En général, c'est juste après l'ouverture du port
série que le modem est initialisé. Cela se fait grâce
aux commandes AT que nous ne détaillerons pas. Simplement, ces
commandes sont envoyées au modem (par l'intermédiaire du
circuit 103) (ex. <tt/write/ sur le <it/descripteur de fichier/ du
périphérique) et interprétées par lui,
lorsque :
<itemize>
<item>
le circuit 108 est fermé (état <sq/1/) ;
<item>
le modem est en mode commande.
</itemize>
<sect2>
Établissement de la connexion
<p>
L'une des commandes d'initialisation permet la composition d'un
numéro. Le modem décroche (eh oui, ce terme barbare veut
dire que suite à la fermeture du relais, le central local envoie une
tonalité à la fréquence de 440 Hz <tt>:-)</tt>)
puis compose le numéro.
Sur l'équipement distant, le circuit 108 est également
monté. Le modem appelé détecte l'appel. Le signal
d'indication d'appel (circuit 125) est utilisé en interne pour
mémoriser l'appel, le modem réalisant donc lui-même la
connexion à la ligne. Cette mémorisation est maintenue par
DTR (jusqu'à déconnexion).
<p>
À ce moment précis, le modem appelé répond en
validant son modulateur qui émet la porteuse.
<p>
Le modem appelant, en état de décrochage et attendant la
porteuse, met son émetteur en service. Après
négociation, le circuit 109 (DCD) est alors validé. Du
côté de l'appelé, le circuit 109 est également
validé. La prise de contact est terminée. Les circuits 107
(DSR) des deux modems sont alors montés en réponse à
DTR (asservissement des circuits 107-109).
<sect2>
Réponse automatique ou manuelle
<p>
Du côté de l'appelé, il est possible de mettre le modem
en mode réponse automatique. Il répond alors tout seul
à l'appel après quelques sonneries. Le registre S0 des modems
est généralement réservé à la
configuration de ce mode.
<p>
Lorsque ce registre contient la valeur 0, (ATS0=0), le modem est en
réponse manuelle. Sous Linux, c'est assez souvent l'option choisie,
et c'est le logiciel (notamment <it/getty/) qui gère l'appel. En
effet les gestionnaires, de <it/tty/ tels que <it/getty/
préfèrent prendre en charge la connexion : ce n'est pas
au modem à répondre à un appel mais à
<it/getty/ lui même. Lorsque le modem reçoit un appel, il
émet simplement le message <bf/RING/ (bien sûr, si le mode
verbeux est bien configuré : ATE1). Sur ce, <it/getty/ envoie
la commande ATA qui valide le mode réponse et la porteuse.
<p>
Enfin, à la fermeture du port, les signaux 108/107 repassent
à l'état <bf/0/.
Voici à titre d'information l'organigramme d'un appel :
<tscreen><verb>
+---------------------------------------+
| Detection de l'invitation a numeroter |
+---------------------------------------+
|
+--------------------------+
| Numerotation |
+--------------------------+
|
+---------------------------------+
| Emission de la tonalite d'appel |
+---------------------------------+
|
+--------------------------+
+------- NON -----| Detection de tonalite |- OUI
| +--------------------------+ |
| | |
| +--------------+ +--------------------------+
| | Occupe | | Retour d'appel |
| +--------------+ +--------------------------+
| | |
| | +--------------------------+
+------------------------- NON -------| Detection arret tonalite |
| | +--------------------------+
| | |
| | +-------------------------------+
| | +-------- NON ----| Detection tonalite de reponse |
| | | +-------------------------------+
| | | |
| | | +--------------------------+
| | | +-NON--| Prise de contact aboutie |
| | | | +--------------------------+
| | | NO | |
TIMEOUT | BUSY | | ANSWER | TIMEOUT | CONNECT
+--------------------------+ +-------------+ +--------------------------+
| Appel infructueux | | Deconnexion | | Transmission de donnees |
+--------------------------+ +-------------+ +--------------------------+
</verb></tscreen>
<sect2>
Déconnexion
<p>
Plusieurs méthodes permettent de mettre fin à un appel :
<itemize>
<item>
<bf>Mode commande.</bf> Mettre le modem en mode commande et envoyer la
chaîne <tt>+++ATH</tt> ;
<item>
<bf>Perte de porteuse.</bf> L'une des causes est la déconnexion
normale de l'autre modem ;
<item>
<bf>Ouverture du circuit 108</bf> (DTR). C'est la méthode la plus
couramment employée.
</itemize>
<sect><heading><label id="sec-norme">
Etat actuel de la normalisation
<p>
Voici un tableau résumant l'état actuel de la normalisation
concernant les classes de débits supportés.
<tscreen><verb>
+----------+--------------------------------------------+
| Avis | Signification |
+----------+--------------------------------------------+
| V.21 | Utilisation sur RTC a 300 bits/s |
| | |
| V.22 | Utilisation a 1200 bits/s sur RTC 2 fils |
| | full duplex |
| V.22 bis | idem a 2400 bits/s |
| | |
| V.23 | Utilisation a 600 ou 1200 bits/s sur RTC |
| | ou 1200/75 bits/s |
| | |
| V.25 et | Composition automatique du numero et/ou |
| V.25 bis | reponse automatique a un appel sur RTC |
| | |
| V.26 | Utilisation a 2400 bits/s sur LS(*) 4 fils |
| | |
| V.26 bis | Modem 2400 bits/s (1200 en repli) sur RTC |
| | |
| V.27 | Modem 4800 bits/s pour LS |
| | |
| V.27 bis | Modem 4800 bits/s (2400 en repli) pour |
| | donnees synchrones |
| | |
| V.27 ter | Modem 4800 bits/s (2400 en repli) meme |
| | modulation mais pour le RTC |
| | |
| V.29 | Modem 9600 bits/s pour LS |
| | |
| V.32 | 9600 bits/s (4800 en repli) duplex 2 fils |
| | sur RTC |
| | |
| V.32 bis | 14400 bits/s |
| | |
| V.34 | 28800 bits/s sur RTC |
| | |
| V.42 | Correction d'erreurs LAP-M et MNP4 |
| | |
| V.42 bis | Correction d'erreurs + |
| | compression de donnees MNP5 |
| | |
| V.54 | Normalise les boucles de tests |
+----------+--------------------------------------------+
* LS = Ligne Specialisee
</verb></tscreen>
<sect1>
À propos du V.42 bis
<p>
Un tout petit mot à propos de la norme V.42 bis qui permet la
compression de données. L'algorithme utilise un dictionnaire de
chaînes de caractères. Lorsqu'une chaîne apparaît,
un <it/token/ est transmis qui n'est autre que l'index de cette
chaîne dans le dictionnaire. La longueur maximale d'une chaîne
ainsi que la taille maximale du dictionnaire sont négociées
au début de la connexion. La norme V.42 bis autorise une
longueur de chaîne comprise entre 6 et 250 caractères. La
taille minimale du dictionnaire est de 512 entrées (soit 9 bits pour
coder le rang d'un entrée). Le taux maximal de compression dans ce
cas est de :
<tscreen><verb>
250 * 8 : 9 = 222.2
</verb></tscreen>
soit un taux de 222:1. Un bon taux de compression est plus une affaire de
taille mémoire et d'efficacité en fonction des données
à coder qu'une affaire de puissance de processeur.
<sect1><heading><label id="sec-modul">
Débits et modulations
<p>
<quote>
Merci à Christian 'naddy' Weisgerber de son aide pour la
rédaction de cette partie.
</quote>
Voici rassemblés dans les tableaux suivants les débits et les
modulations correspondantes utilisés dans les principales normes
pour liaisons téléphoniques à 2 fils. Les <it/normes/
qui ne sont pas citées ci-après sont peu utilisées
voire oubliées aujourd'hui (liaisons à 4 fils, V.32 terbo,
Bell xxx, V.FC, ZyXEL, HST, PEP... certaines n'étant d'ailleurs pas
de véritables normes).
<tscreen><verb>
+------------------------------------------------------------------------+
| Avis b/s bauds modulation remarques |
+------------------------------------------------------------------------+
| V.21 300 300 FSK |
| |
| V.22 1200 600 DPSK |
| |
| V.22bis 2400 600 QAM |
| |
| V.23 1200 1200 FSK |
| 600 600 FSK |
| 75 75 FSK [1] |
| |
| V.32 9600 2400 QAM+TCM |
| 9600 2400 QAM |
| 4800 2400 QAM |
| |
| V.32bis 14400 2400 QAM+TCM |
| 12000 2400 QAM+TCM |
| 9600 2400 QAM+TCM |
| 7200 2400 QAM+TCM |
| 4800 2400 QAM |
| |
| V.34 (voir tableau suivant) |
| |
| V.27ter 4800 1600 DPSK |
| 2400 1200 DPSK |
| |
| V.29 9600 2400 QAM |
| 7200 2400 QAM |
| 4800 2400 QAM [2] |
| |
| V.17 14400 2400 QAM+TCM |
| 12000 2400 QAM+TCM |
| 9600 2400 QAM+TCM |
| 7200 2400 QAM+TCM |
+------------------------------------------------------------------------+
[1] Bande de retour.
[2] Pas utilise pour fax.
V.21, V.22, V.22bis, V.32, V.32bis, V.34 sont "full duplex".
V.27ter, V.29, V.17 sont "half duplex" et utilises pour fax.
V.23 est "half duplex" et asymetrique.
Les modulations:
FSK : Frequency Shift Keying (modulation de frequence)
DPSK : Differential Phase Shift Keying (modulation de phase differentielle)
QAM : Quadrature Amplitude Modulation (modulation d'amplitude en quadrature)
TCM : Trellis Coded Modulation (modulation codee en treillis)
</verb></tscreen>
Dans le cas de l'avis V.34, les choses se compliquent un peu. Cette norme
a des vitesses de modulation obligatoires (2400, 3000, 3200 bauds) et des
vitesses facultatives (2743, 2800, 3429 bauds). La modulation est toujours
de type QAM (modulation d'amplitude en quadrature) avec une des trois
méthodes TCM choisie par le récepteur. Les combinaisons
suivantes sont possibles :
<tscreen><verb>
+-------------------------------------------------------------+
| 2400 2743 2800 3000 3200 3429 bauds |
| b/s |
+-------------------------------------------------------------+
| 2400 x |
| 4800 x x x x x x |
| 7200 x x x x x x |
| 9600 x x x x x x |
| 12000 x x x x x x |
| 14400 x x x x x x |
| 16800 x x x x x x |
| 19200 x x x x x x |
| 21600 x x x x x x |
| 24000 x x x x x |
| 26400 x x x |
| 28800 x x |
+-------------------------------------------------------------+
</verb></tscreen>
<sect>
Foire Aux Questions
<p>
<descrip>
<tag/Comment puis-je changer facilement un paramètre de mon port
série ?/
La meilleure façon de le faire, aussi bien manuellement que dans un
script est de rediriger le périphérique sur l'entrée
standard de <it/stty/. Exemple :
<tscreen><verb>
stty crtscts < /dev/ttyS0
</verb></tscreen>
activera le contrôle de flux matériel sur le premier port
série utilisé en entrée.
<tscreen><verb>
stty -a < /dev/cua0
</verb></tscreen>
affichera tous les paramètres du premier port série
utilisé en sortie.
<tag/Pourquoi faut-il configurer CRTSCTS sur le port série ?/
Pour gérer le contrôle de flux matériel. Ce n'est pas
une obligation, c'est une garantie que l'échange de données
entre ETTD et ETCD se fera dans les meilleures conditions. Il faut bien
entendu que votre modem puisse le faire. Contrairement à une
idée reçue, si vous mettez l'option CRTSCTS dans le fichier
/etc/gettydefs, il n'est pas nécessaire d'effectuer en plus un
<tt>stty crtscts </dev/port\#</tt>. Par contre, il faut le mettre
à la fois dans la partie <it/initiale/ et <it/finale/ de gettydefs.
Notez qu'il s'agit bien d'un contrôle de flux local, et en aucun cas
il ne faut s'inquiéter de ce que fait le correspondant dans ce
domaine.
<tag>Je remarque que agetty modifie les droits du fichier /dev/ttyS0,
bizarre non ?</tag>
Ca peut effectivement paraître bizarre. Il s'agit en fait de
l'établissement d'une <it/session/ d'utilisation du
périphérique. Celui-ci prend alors les droits du <sq/chef/ de
session (<it/session leader/) qui se protège ainsi des utilisations
du même tty par d'autres processus.
<tag/Aurais-je accès à mon téléphone ?/
Cette question a été réellement posée. Si vous
n'avez qu'une ligne téléphonique, la réponse est non.
De plus, en décrochant le combiné téléphonique,
vous pertuberez la ligne et le modem risque fort de diminuer le
débit (pour le remonter si tout va bien ensuite).
<tag/Lorsque je me connecte chez mon fournisseur, comment mon adresse IP
est générée ?/
Cette question montre à l'évidence une confusion entre toutes
les notions réseaux. Bien qu'elle ait été posée
suite à un problème relatifs aux modems, la réponse ne
devrait théoriquement pas se trouver dans ce
document. Néanmoins, le chapitre suivant rappelle quelques principes
de base des empilements protocolaires afin de clarifier un peu tout cela.
</descrip>
<sect>
Un mot sur les empilements protocolaires couramment utilisés
<p>
Un tel titre pourrait faire croire à une erreur de mise en page ou
de <it/copier-coller/ étant donné le sujet du document. En
fait, il n'en est rien.
<p>
La connexion d'une machine à un fournisseur d'accès à
Internet met en jeu un ensemble de protocoles de communications : TCP,
UDP, IP, SLIP, PPP, etc. De nombreux utilisateurs souhaitent
réaliser ce type de connexion depuis chez eux, via un modem et
rencontrent parfois quelques problèmes de configuration.
<p>
Il est évident qu'il est à la fois difficile et inutile de
tout connaître de ces protocoles. Il faut vraiment <it/être du
métier/ pour bien les connaître, et encore ! Cependant il
semble raisonnable de penser que la mise en oeuvre de telles connexions,
sous Linux par exemple, ne peut se faire dans de bonnes conditions sans un
minimum de connaissances sur l'architecture de communication
utilisée.
La lecture du forum <it/fr.comp.os.linux/ montre parfois une certaine
confusion dans toutes les fonctions mises en oeuvre et qui engendrent
inévitablement de mauvais paramétrages.
<p>
Les quelques schémas qui suivent donnent une idée de la
façon dont tous ces <it/engrenages/ sont placés pour que
<sq/ça tourne/ !
<sect1>
TCP/UDP/IP
<P>
Ces sigles sont très fréquemment utilisés aujourd'hui
et pour cause : ces empilements de couches de communications tendent
à se répandre à vive allure. C'est à l'origine
un ensemble de protocoles développés dans le cadre du projet
ARPANET, créé par ARPA (aujourd'hui DARPA), l'agence pour les
projets de recherche avancée du Ministère de la
Défense des Etats-Unis.
<itemize>
<item>
TCP<footnote> Transmission Control Protocol </footnote> est une
entité de niveau Transport chargée de véhiculer des
données de manière fiable entre deux machines souhaitant
dialoguer ;
<item>
UDP<footnote> User Datagram Protocol</footnote> est une entité de
niveau Transport chargée de véhiculer des données
entre deux machines souhaitant dialoguer ;
<item>
IP<footnote> Internet Protocol</footnote> est une entité de niveau
Réseau chargée de véhiculer des données entre
deux noeuds d'un réseau.
</itemize>
<sect1>
PPP/SLIP
<P>
PPP<footnote>Point-to-Point Protocol</footnote> et SLIP<footnote>Serial
Line IP</footnote> proposent une méthode d'encapsulation des
datagrammes IP sur des liaisons point à point, par exemple les
lignes asynchrones série. En quelques mots, disons que SLIP est un
protocole très simple, assez ancien, datant d'une époque
où certains problèmes n'étaient pas aussi importants
qu'aujourd'hui : adressage, identification réciproque,
détection et correction d'erreurs, compression (extrait du
RFC-1055). PPP est quant à lui beaucoup plus complet et c'est
pourquoi il est généralement préféré par
les connaisseurs. Il offre toutes ces caractéristiques
regroupées en trois sous-ensembles :
<itemize>
<item>
une méthode d'encapsulation de type HDLC sur circuit commuté
ou permanent, synchrone ou asynchrone ;
<item>
un protocole LCP (Link Control Protocol) permettant d'établir, de
configurer et de tester une connexion ;
<item>
une famille de protocoles NCP (Network Control Protocols) pour
l'établissement et la configuration des protocoles réseaux.
</itemize>
<p>
Pour obtenir de plus amples renseignements, vous pouvez vous reporter aux
documents concernant ces protocoles : <bf/RFC-1055/ (SLIP),
<bf/RFC-1171/ et <bf/RFC-1172/ (PPP) et le <bf/PPP-HOWTO/.
<sect1>
Mise en oeuvre
<p>
<tscreen><verb>
+----------------+-------+ +--------+ +--------+ +------+ +-----+
| Applications | FTP | | TELNET | | SMTP | | TFTP | | ... |
+----------------+---+---+ +---+----+ +--------+ +--+---+ +-----+
| | | |
+----------------+---+---------+------++------------+-----+
| Transport | TCP | UDP |
+----------------+---------------------+------------------+
| Reseau | |
| | IP |
| | _____ _____ ______ |
| (interfaces) | / eth \ / ppp \ / slip \ |
+----------------+-----------------^---------+------------+
| Liaison | LLC | PPP | SLIP |
| | MAC | | |
+----------------+-------++--------+--------+-+-----------+
|| | |
+----------------+-------++--------+--------+-+-----------+
| Interfaces | LAN | V.24 | Fonctionnelle
| | (non decrit) | V.28 | Electrique
| | | ISO.2110 (25 br) | Physique
+----------------+-------++--------+--------+-+----------------+
|| | |
Ethernet +--+ +-+-+-+ Modem
==========| |===== |\ \-------
Fddi +--+ \ \_____\ /
\|_0_0_| ---------
</verb></tscreen>
La mise en oeuvre de tels protocoles se fait toujours de bas en haut (des
couches basses aux couches hautes) puisque la demande se fait de haut en
bas. Prenons un exemple :
<p>
Supposons que vous souhaitiez faire un <it/ftp/ de chez vous sur
<it/ftp.samachine.fr/. L'application <it/ftp/ demande à TCP
d'établir une connexion. Pour qu'elle puisse s'établir, PPP
doit déjà fonctionner. Pour que PPP fonctionne, le modem doit
être en ligne :
<p>
<itemize>
<item>
première étape : établissement d'une
communication entre deux modems. Cette étape est supposée
connue, maintenant ;
<item>
deuxième étape : mise en route de PPP, avec
éventuellement authentification ;
<item>
troisième étape : configuration de l'interface IP
correspondante. Il s'agit en général, sous Linux, de
l'interface <it/ppp0/. Une adresse IP pouvant provenir soit d'une
configuration locale, soit de votre fournisseur, est affectée
à l'interface. Dans ce dernier cas, celui-ci la fournit lors de
l'initialisation PPP. Dans les deux cas, c'est le démon PPP qui
configure l'adresse de l'interface ;
<item>
quatrième étape : établissement d'une connexion
TCP, puis initialisation de <it/ftp/. A partir de là, si tout s'est
bien passé, vous pouvez transférer vos fichiers.
<p>
</itemize>
Vous pouvez maintenant imaginer le déroulement d'une
déconnexion.
<sect1>
Les fichiers de configuration
<p>
<sect2>
Les applications
<p>
Vous comprendrez qu'il est difficile de décrire ici l'emplacement
des fichiers de configuration des applications. Prenez soin de lire les
fichiers README ou INSTALL et d'exécuter l'installation
correctement.
<sect2>
Les couches de communication : TCP/UDP/IP
<p>
Pour une configuration standard de votre machine, vous devez compiler le
noyau avec les options <sq/réseau/ suivantes :
<tscreen><verb>
Networking support y
Network firewalls n
Network aliasing n
TCP/IP networking y
IP: forwarding/gatewaying n
IP: multicasting n
IP: accounting n
IP: PC/TCP compatibility mode n
IP: Reverse ARP n
IP: Disable Path MTU Discovery
(normally enabled) n
IP: Disable NAGLE algorithm
(normally enabled) n
IP: Drop source routed frames y
IP: Allow large windows
(not recommended
if <16Mb of memory) n
The IPX protocol n
... autres protocoles n
</verb></tscreen>
Le fichier <it/resolv.conf/ doit contenir :
<tscreen><verb>
domain <domaine de votre fournisseur>
nameserver <adresse IP du serveur de nom de votre fournisseur>
</verb></tscreen>
<sect>
Le Minitel
<p>
Bien que ce merveilleux appareil commence à prendre de l'âge,
il est difficile de ne pas en parler un peu, notamment en raison de ses
spécificités. Pourquoi ne pas envisager en effet de faire un
serveur Minitel chez vous ou tout simplement de l'utiliser comme terminal.
Nous nous contenterons ici d'en donner quelques caractéristiques
intéressantes dans le cadre d'une utilisation avec Linux.
<p>
Les STUM 1B<footnote>Spécifications Techniques d'Utilisation du
Minitel 1B.</footnote> décrivent l'ensemble des
caractéristiques des divers modules du Minitel 1B :
<itemize>
<item>
l'écran ;
<item>
le clavier ;
<item>
le modem ;
<item>
la prise péri-informatique.<footnote>A ce propos, je tiens à
votre disposition un schéma électronique d'un montage
permettant l'adaptation RS232-Minitel. Il met en oeuvre le circuit MAX232
permettant une parfaite adaptation des tensions.</footnote>
</itemize>
<sect1>
L'écran
<p>
Le minitel 1B est capable d'afficher 24 lignes de 40 ou 80
caractères et 8 couleurs (ou niveaux de gris).
Le mode 40 colonnes correspond au standard <it/Videotex/, le mode 80
colonnes au standard <it/télé-informatique/. C'est en
général celui-ci que l'on utilisera s'il sert de
terminal. Les séquences de touches permettant de passer d'un mode
à l'autre sont indiquées dans le tableau suivant dans lequel
on retrouvera également quelques séquences utiles :
<tscreen><verb>
+-------------+----------------------------------+
| Touches | Signification |
+-------------+----------------------------------+
| <Fcnt T> A | Mode tele-informatique americain |
| | (pas d'accents) |
| <Fcnt T> F | Mode tele-informatique francais |
| | accents (codage particulier) |
| <Fcnt T> V | Mode Videotex |
+-------------+----------------------------------+
| <Fcnt T> E | Valide/invalide l'echo local |
| | |
| <Fcnt E> P | Mode page (retour haut de page |
| | en fin d'ecran) |
| <Fcnt E> R | Mode rouleau (par defaut) |
| | |
| <Fcnt C> M | Verouillage minuscules (defaut |
| | en mode tele-informatique) |
+-------------+----------------------------------+
</verb></tscreen>
<sect1>
Le clavier
<p>
Il s'agit d'un clavier <it/AZERTY/ permettant la saisie de la plupart des
caractères courants pour un terminal. Il est notamment possible de
verouiller les minuscules grâce à la séquence
<Fcnt C> M. A noter une correspondance, dans le mode
télé-informatique, de certaines touches :
<tscreen><verb>
+-------------+-----------------------------------+
| Touches | Correspondance terminal classique |
+-------------+-----------------------------------+
| Sommaire | PF1 |
| | |
| Annulation | PF2 |
| | |
| Retour | PF3 |
| | |
| Repetition | PF4 |
| | |
| Envoi | Enter (Entree) |
+-------------+-----------------------------------+
</verb></tscreen>
La touche <it/Entrée/ correspond également à la
séquence de touches <Ctrl J>
<sect1>
Le modem
<p>
Le modem du minitel permet des débits de 300 à 4800 ou 9600
bits/s<footnote>Tous les modèles de minitel n'autorisent pas tous
ces débits.</footnote>. Il est associé à un coupleur
travaillant sur 7 bits de données, un bit de parité paire, un
bit de <it/start/ et un bit de <it/stop/, soit 10 bits par
caractère. Le tableau suivant donne les séquences de touches
permettant de configurer le modem à ces différents
débits.
<tscreen><verb>
+-------------+--------------+
| Touches | Debit |
+-------------+--------------+
| <Fcnt P> 3 | 300 bits/s |
| | |
| <Fcnt P> 1 | 1200 bits/s |
| | |
| <Fcnt P> 4 | 4800 bits/s |
| | |
| <Fcnt P> 9 | 9600 bits/s |
+-------------+--------------+
</verb></tscreen>
En standard V.23, il est possible de <it/retourner/ le modem (vitesse
émission-réception) avec la séquence
<Fcnt M> R.
<sect1>
Utilisation du Minitel comme simple terminal
<p>
D'après les conseils avisés de <it/Pierre Ficheux/, voici un
exemple de configuration permettant de connecter un Minitel :
<sect2>
Configuration de getty
<p>
Une méthode simple consiste à compiler un <it/getty/ un peu
particulier. Les sources se trouvent dans le paquetage
<bf/getty_ps-2.0.7h/, en général disponible par <it/ftp/
(ftp.ibp.fr) sous <bf>/pub/linux/tsx-11/sources/sbin</bf>. <p> Il s'agit
ensuite de modifier le fichier <it/tune.h</it> comme suit :
<tscreen><verb>
#ifdef V23
#define DEF_CFL (CS7|PARENB) /* Pour connexion V.23 */
#else
#define DEF_CFL (CS8) /* default word-len/parity */
#endif /* V23 */
</verb></tscreen>
Puis de compiler l'ensemble avec l'option -DV23 vous donnant un fichier
exécutable <it/uugetty/ que vous pourrez renommer <it/uugetty_v23/.
Ensuite, il faut ajouter quelques entrées au fichier
<it>/etc/gettydefs</it> :
<tscreen><verb>
#
# Pour la connexion V.23
#
9600v23# B9600 CS7 PARENB -PARODD CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S login: #4800v23
4800v23# B4800 CS7 PARENB -PARODD CLOCAL # B4800 SANE -ISTRIP CLOCAL #@S login: #2400v23
2400v23# B2400 CS7 PARENB -PARODD CLOCAL # B2400 SANE -ISTRIP CLOCAL #@S login: #1200v23
1200v23# B1200 CS7 PARENB -PARODD CLOCAL # B1200 SANE -ISTRIP CLOCAL #@S login: #1200v23
</verb></tscreen>
Enfin, vous modifiez le fichier <it/inittab/ de façon à
démarrer <it/uugetty_v23/ comme dans l'exemple ci-dessous :
<tscreen><verb>
d4:45:respawn:/sbin/uugetty_v23 ttyS1 9600v23
</verb></tscreen>
Une solution différente consisterait à seulement modifier
<it>/etc/gettydefs</it>. La méthode précédente ne
fait, finalement, que redéfinir l'option SANE qui ne comporte pas
moins de 16 paramètres, en modifiant l'un d'eux : DEF_CFL. Il
est possible de la redéfinir par configuration en la
remplaçant par l'ensemble des paramètres, sauf CS8 que l'on
remplacera par CS7 PARENB. Les entrées de
<it>/etc/gettydefs</it> sont à modifier comme l'exemple
ci-après :
<tscreen><verb>
#
# Pour la connexion V.23
#
9600v23# B9600 CS7 PARENB -PARODD CLOCAL # B9600 ISTRIP CS7 PARENB -PARODD (*)
CLOCAL BRKINT IGNPAR ICRNL IXON IXANY OPOST ONLCR CREAD HUPCL ISIG ICANON (*)
ECHO ECHOE ECHOK #@S login: #4800v23
(*) a continuer sur la meme ligne
[reste du ficher]
</verb></tscreen>
Bien que cela puisse paraître lourd, il est préférable
d'utiliser cette méthode. On a trop tendance à recompiler
des sources pour les adapter à trente-six situations alors qu'ils
fournissent généralement un niveau de configurabilité
extrêmement complet et puissant. C'est le cas ici. Les sources de
<it/getty/ prévoient d'analyser tous ces paramètres, et cela
fonctionne parfaitement.
<sect1>
Utilisation du Minitel pour un accès distant
<p>
Deux cas peuvent se présenter :
<itemize>
<item>
soit vous souhaitez dédier votre ligne aux seuls accès
Minitel, auquel cas il est souhaitable d'envisager de configurer votre
système comme ci-dessus. Il faut simplement modifier le fichier
<it>/etc/gettydefs</it> en remplaçant l'option CLOCAL par CRTSCTS
dans la première partie (options initiales) et par
CRTSCTS HUPCL dans le partie suivante (options finales) ;
<item>
soit vous souhaitez seulement <it>pouvoir</it> utiliser le Minitel comme
terminal distant, sans que ce soit un accès
dédié. Dans ce cas il n'y a rien à faire sur votre
système (rien de plus que la configuration que vous avez
déjà dû mettre en place : getty, gettydefs,
inittab, ...). Sur le Minitel, il sera préférable de le
configurer en mode télé-informatique
(<Fcnt T> F).
</itemize>
<sect>
Un modem particulier: le câble null-modem
<p>
Un câble <it/null-modem/ est tout simplement un câble inverseur
permettant de relier ensemble deux ETTD sans passer par
l'intermédiaire de deux ETCD. Il est conforme aux normes du
C.C.I.T.T., c'est à dire qu'il simule les différents signaux.
Son seul inconvénient est que la liaison ainsi
réalisée ne peut dépasser 250 mètres.
<p>
Voici le schéma du câble à réaliser :
<tscreen><verb>
+------+-------+---------------------------------+------+-------+
| Code | V.24 | Cablage (No de broche) | Code | V.24 |
+------+-------+---------------------------------+------+-------+
| 101 | TP | 1 o-------------------o 1 | 101 | TP |
| | | | | |
| 102 | TS | 7 o-------------------o 7 | 102 | TS |
| | | | | |
| 103 | ED | 2 o-------------------o 3 | 104 | RD |
| | | | | |
| 104 | RD | 3 o-------------------o 2 | 103 | ED |
| | | | | |
| 105 | DPE | 4 o-| |-o 4 | 105 | DPE |
| | | | | | | |
| 106 | PAE | 5 o-| |-o 5 | 106 | PAE |
| | | \ ,------' | | |
| | | -------(---------o 8 | 109 | DS |
| 109 | DS | 8 o---------' | | |
| | | | | |
| 107 | PDP | 6 o------------------o 20 | 108 | TDP |
| | | | | |
| 108 | TDP | 20 o------------------o 6 | 107 | PDP |
| | | | | |
+------+-------+---------------------------------+------+-------+
</verb></tscreen>
<sect>
Choix d'un modem
<p>
Si vous êtes sur le point d'investir dans un modem, il y a au moins
trois facteurs déterminants pour vous :
<descrip>
<tag/Le coût/
Ce facteur est généralement le plus important. Vous vous
êtes certainement fixé une somme que vous ne pourrez
dépasser que dans des limites raisonnables (moins de 500 francs
environ) et moyennant un service supplémentaire non
négligeable. On trouve à l'heure actuelle d'excellents modems
dans une gamme de prix de l'ordre de 1000 FF à 2000 FF.
<tag/Le débit/
La réponse pourrait être vague : tout dépend de
l'utilisation. En fait, il semble que la plupart d'entre vous se connectera
à Internet et la plupart des fournisseurs proposent désormais
des accès à 28800 bits/s. Il semble raisonnable d'investir
dans un tel modem, d'autant plus que leur coût est rarement
supérieur à 2000 FF. Vous pouvez d'ailleurs
espérer gagner un peu sur les temps de connexions lors de transferts
de fichiers ou de navigation <sq/WEB/.
<tag/Le type de modem : interne ou externe/
Pour répondre rapidement, on pourrait dire que le modem interne a,
en France, tous les défauts. Hors de France, il a beaucoup de
défauts. C'est un avis, il vaut ce qu'il vaut, mais il semble
partagé par bon nombre d'utilisateurs :
</descrip>
<itemize>
<item>
le premier défaut est qu'il est interne et occupe donc un
emplacement sur le <it/bus/. En externe le modem est de plus facilement
transportable d'un PC à un autre, par exemple ;
<item>
le deuxième est que notre opérateur national demande à
ce qu'un numéro soit <sq/brûlé/ lorsqu'un appel
échoue plusieurs fois. Une fois le numéro brûlé,
le modem refuse de le composer. La seule solution est alors
d'éteindre le modem et de recommencer. Au fait, comment
éteignez-vous un modem interne ?
<item>
le troisième est plutôt lié au confort. La plupart des
modems externes possèdent en effet des voyants indiquant
l'état de la connexion. Il est agréable de constater
rapidement que la connexion est perdue ou que le transfert est
perturbé.
</itemize>
Le seul inconvénient du modem externe est qu'il occupe un port
série. De plus il vaut mieux posséder un port série
rapide de type 16550A (les 16550 sont bogués). Notez cependant que
les ports série de type 8250 (les anciens) supportent des
débits pouvant aller jusqu'à 57600 bits/s. Contrairement
à ce que l'on dit, ils ne sont pas si mauvais que cela. Qui est
déjà monté à des débits
supérieurs ?
<sect>
Quelques chiffres
<p>
Beaucoup d'utilisateurs se posent des questions sur ce qu'ils peuvent
attendre de leur modem et du coût des communications. Bien souvent,
la facture surprend tous les deux mois.
<sect1>
Débit réel
<p>
Un petit tableau vaut mieux qu'un long discours, voici quelques valeurs de
débits réels. Evidemment, il n'est pas tenu compte des
problèmes de lignes, de disponibilité des serveurs qui
réduisent parfois les taux de transfert effectifs. De plus, les
valeurs sont indiquées sans compression logicielle. En cas de
compression, il faudra multiplier les valeurs par au plus 2, ce qui est
déjà optimiste.
Il faut savoir qu'en transmission asynchrone 8 bits, étant
donnés les bits de <bf/start/ et de <bf/stop/, le rendement est
d'environ 80%.
<tscreen><verb>
+---------------+--------------+-------------------+
| Debit affiche | Debit reel | Ko/s | Mo/heure |
+---------------+--------------+--------+----------+
| 9600 b/s | 7680 b/s | 0,96 | 3,4 |
| | | | |
| 14400 b/s | 11520 b/s | 1,44 | 5,2 |
| | | | |
| 19200 b/s | 15360 b/s | 1,92 | 6,9 |
| | | | |
| 21600 b/s | 17280 b/s | 2,16 | 7,8 |
| | | | |
| 26400 b/s | 21120 b/s | 2,64 | 9,5 |
| | | | |
| 28800 b/s | 23040 b/s | 2,88 | 10,4 |
+---------------+--------------+--------+----------+
</verb></tscreen>
<sect1>
Coûts de connexion
<p>
Le meilleur indicateur pour ce genre de calcul est bien entendu France
Télécom. Essayons ici de dégager quelques grands
chiffres. Les prix sont indiquées pour un appel à
Paris :
<tscreen><verb>
+---------------+---------------------------------+
| | Prix / heure de connexion |
+---------------+---------------------------------+
| Appel de : | Tarif plein | 50% | 65% |
+---------------+-----------------------+---------+
| Paris | 14,84 F | 7,42 F | 5,20 F |
| | | | |
| Proche | 22,26 F | 11,13 F | 7,79 F |
| Banlieue | | | |
| | | | |
| Province | 127,20 F | 63,60 F | 44,52 F |
+---------------+---------------------------------+
</verb></tscreen>
Prix de l'unité Télécom : 0,742 FF.
<p>
<sect>
Envisager d'écrire des applications
<p>
Vous avez sûrement plein d'idées d'applications
intéressantes, mais envisager de contrôler une jonction
série vous fait peur ? Voici quelques petites indications.
<sect1>
Et si c'était simple ?
<p>
Sous Unix, donc sous Linux, les seuls objets manipulés lors des
entrées/sorties sont les <it/fichiers/. (Tiens, au fait, on aurait
peut-être dû commencer par là ! Bon, vous le saviez
déjà, ce n'est pas un cours Unix). La jonction série
n'échappe pas à cette règle et le pilote vous la
présente ainsi. Ici, il s'agit d'un (ou plutôt deux comme on
le verra plus loin) fichier particulier, bien sûr, puisque se cache
derrière un pilote (<it/driver/) en mode caractère, mais la
façon de réaliser les entrées sorties est la
même : <bf/open, read, write, ioctl, close/. Il y a quand
même quelques petites choses à savoir.
<p>
Le pilote série s'est enregistré, à l'initialisation
du noyau, comme un <it/tty/. Il est donc géré comme un tty
classique. Il apporte bien entendu quelques caractéristiques
supplémentaires que nous verrons rapidement dans la section
concernant la commande <it/ioctl/. Toujours est-il que si vous savez
gérer un <it/tty/ sous Unix (commande <it/stty/), vous saurez sans
problème gérer ce pilote.
<p>
<sect2>
open, close
<p>
La méthode d'ouverture et de fermeture d'un port série est
classique. Néanmoins un mécanisme particulier se cache
derrière la primitive <bf/open/ qui est rapidement décrit
à la section <ref id="sec-appels" name="Appels entrants (Dial-in) et
appels sortants (Call-out) sous Linux">.
<sect2>
read, write
<p>
Rien à signaler de particulier.
<sect2>
ioctl
<p>
Le contrôle de tout système d'entrée/sortie se fait
avec la commande système <it/ioctl/. Elle est souvent masquée
par des commandes de haut niveau (setserial, stty, modemstat, ...), mais
elle est leur moteur.
<p>
Selon que vous souhaitez vous adresser aux fonctionnalités
classiques d'un <it/tty/ ou aux fonctions spécialisées du
pilote série, vous utiliserez deux sous-ensembles de commandes
différentes. Vous les retrouverez dans le fichier à inclure
<it>linux/termios.h</it>. Décrivons-les rapidement (on
déborde un tout petit peu du sujet <tt>:-)</tt>) :
<descrip>
<tag/TCGETS - TCSETS/
et quelques dérivés avec WAIT, FLUSH... Elles permettent de
récupérer (resp. positionner) les attributs standard <it/tty/
dans une structure <it/termios/ (voir le fichier <it>linux/termios.h</it>)
<tag/TIOCSTTY - TIOCNOTTY/
permettent de définir (resp. annuler) une session d'utilisation du
<it/tty/. Ceci est visible car, entre autres choses, une conséquence
est le changement des droits du fichier correspondant
<tscreen><verb>
Avant:
crw-rw-rw- 1 root tty 4, 64 Nov 26 20:47 ttyS0
Apres:
crw--w--w- 1 root root 4, 64 Nov 26 20:49 ttyS0
</verb></tscreen>
<tag/TCFLSH et compagnie/
positionnement d'indicateurs (voir la commande stty)
<tag/TIOCGSERIAL - TIOCSSERIAL/
permettent de récupérer (resp. positionner) les informations
générales dans une (resp. à partir d'une) structure
<it/serial_struct/ (voir le fichier <it>linux/serial.h</it>) : le type
de port série, la ligne, le port, l'irq le port utilisé... ni
plus ni moins ce que fait <it/setserial/.
<tag/TIOCMGET - TIOCMSET/
permettent de récupérer (resp. positionner) les informations
plus spécifiques à la jonction proprement dite (dans un
entier, sous forme de bits positionnés selon que l'indicateur
correspondant est vrai ou faux) :
</descrip>
<tscreen><verb>
+-------------------------------------------------------------------------------------------+
| // DSR RNG CAR CTS // // RTS DTR //|
| // (Data Set (Ring) (Carrier) (Clear To // // (Request (Data Terminal // |
| // Ready) Send) // // To Send) Ready) // |
+------+----------+-------+----------+-----------+----+----+-----------+---------------+----+
31 9 8 7 6 5 4 3 2 1 0
</verb></tscreen>
<sect1><heading><label id="sec-appels">
Appels entrants (Dial-in) et appels sortants (Call-out) sous Linux
<p>
<sect2>
Introduction
<p>
Le pilote série du noyau de Linux propose de gérer un
même port série à la fois pour les appels entrants et
pour les appels sortants exploitant ainsi pleinement leur
caractéristique bi-directionnelle. Il offre donc à
l'utilisateur deux types de fichiers :
<itemize>
<item>
<tt>/dev/ttyS<n></tt> : sont généralement
utilisés en entrée ;
<item>
<tt>/dev/cua<n></tt> : sont généralement
utilisés en sortie.
</itemize>
<sect2>
Gestion
<p>
Chaque port série est enregistré deux fois auprès du
gérant <it/tty/ : une fois en mode <it/entrée/ (ttyS,
majeur 4) et une fois en mode <it/sortie/ (cua, majeur 5).
Voyons rapidement comment le pilote gère ensuite les <sq/deux/
ports :
<itemize>
<item>
les ports séries <tt>/dev/cua</tt> sont gérés en mode
<it/non-bloquant/. Leur ouverture n'est possible que si la ligne
<tt>/dev/ttyS</tt> correspondante n'est pas ouverte et active (sinon
<tt/errno/ retourne EBUSY) ;
<item>
les ports séries <tt>/dev/ttyS</tt> sont gérés en mode
bloquant ou non-bloquant, c'est donc un peu plus compliqué. Si
l'indicateur CLOCAL est positionné, l'ouverture en mode
<bf/bloquant/ est effective si la ligne <tt>/dev/cua</tt> est libre. Si
l'indicateur CLOCAL n'est pas positionné, elle est effective si les
deux conditions suivantes sont réunies :
<itemize>
<item>
la ligne est libre (le <tt>/dev/cua</tt> correspondant n'est pas
utilisé),
<item>
la porteuse (circuit 109) a été détectée.
</itemize>
Dans ce mode et pendant que l'ouverture est bloquée, la ligne n'est
pas occupée, ce qui signifie qu'une application peut toujours
effectuer un appel sortant. Si le port est en cours de fermeture,
l'ouverture échoue (EAGAIN).
<p>
L'ouverture en mode non-bloquant, quant à elle, est effective si le
port n'est pas déjà ouvert et actif (sinon <tt/errno/
retourne EBUSY)<footnote> Les applications utilisent de plus le
mécanisme des fichiers de verrouillage garantissant l'unicité
d'utilisation de la ressource.</footnote>.
</itemize>
C'est le mode qu'utilisent beaucoup d'applications comme <it/getty/ qui
souhaitent dans un premier temps initialiser la ligne (pour éviter
des instabilités liées aux connexions
précédentes) voire ensuite pour initialiser
l'équipement (modem). Elles ne s'intéressent qu'au fait que
la ligne soit occupée, en fermeture ou libre. Si celle-ci n'est pas
libre, l'application se termine et le mécanisme du <it/respawn/ se
charge de les relancer.
<p>
Pour la gestion de la connexion proprement dite, l'application <it/getty/
(pour prendre un exemple courant) ouvre la ligne, soit en mode bloquant si
vous laissez le modem en réponse automatique, soit en mode
non-bloquant si vous souhaitez qu'elle gère activement la connexion.
Elle est alors en attente bloquante en lecture (sur <it/read/).
<sect>
Quelques applications intéressantes
<p>
<sect1>
Un numéroteur
<p>
Cette idée va faire plaisir à <it>Xavier CAZIN</it> :
c'est la sienne. Le mieux est de le laisser parler :
<quote>
En fait, je trouverais très utile de cliquer sur un bouton pour
appeler une personne retrouvée dans une base de données par
exemple. Surtout si elle se trouve à l'étranger (minimum 12
chiffres depuis ici). Donc, ce que j'aimerais, ce sont les renseignements
nécessaires au programmeur pour pouvoir construire un frontal qui
demande au modem de composer le numéro choisi, puis affiche un
message (si le poste n'est pas occupé) du style <sq>Le
téléphone sonne, prenez le combiné</sq>. Ces petites
choses toutes simples demandent de comprendre ce que signifie prendre la
ligne et la relâcher, pour un modem.
</quote>
Excellent exercice. Alors avec tout ce que l'on vient de dire, au
travail <tt>:-)</tt>. En laissant de côté la partie base
de données, l'algorithme à utiliser correspond à
<it>l'organigramme d'un appel</it> donné à titre
d'information au chapitre <ref id="sec-modems" name="Le modem">, auquel il
faut rajouter :
<itemize>
<item>
au préalable, ouvrir le port série
(<tt>/dev/cua<n></tt>), le configurer. Le mieux est de prendre
exemple sur ce que fait <it/getty/ ;
<item>
envoyer ensuite les commandes AT d'initialisation puis de
numérotation (utiliser la fonction chat()) qui fait ceci très
bien ;
<item>
enfin se mettre en lecture sur le port afin de détecter les messages
émis par le modem. Le seul problème ici est qu'il sera
difficile d'attendre certains d'entre-eux (NO ANSWER, TIMEOUT)
étant donné qu'il faut prévenir l'utilisateur qu'il
peut décrocher.
</itemize>
Par contre les messages NO DIALTONE (modem pas branché), et
BUSY sont fort intéressants et permettent d'informer l'utilisateur
immédiatement.
<sect1>
modemstat et compagnie
<p>
Vous trouverez sur les <it>serveurs ftp</it> habituels quelques petits
programmes permettant d'afficher l'état de la jonction. Vous pourrez
vous intéresser particulièrement à la façon de
récupérer les informations (plutôt que sur l'interface
utilisateur qui est l'exemple même de ce qu'il ne faut pas faire).
<tscreen><verb>
/pub/linux/sunsite/system/Serial/modem-stats-1.0.tar.gz
/pub/linux/sunsite/system/Serial/statserial-1.1.tar.gz
/pub/linux/sunsite/system/Serial/modemstat-0.2.tgz
</verb></tscreen>
Un bon point pour statserial aussi simple que bien présenté,
en mode texte.
<sect1>
Un détecteur de signal 109 (CD)
<p>
Lu dans <it/comp.os.linux.development.apps/ cette demande
<quote>
Existe-t-il un utilitaire que je pourrais utiliser dans un
<it/shell-script/ et retournant une valeur, disons 1, si le signal
<it/Détection de porteuse/ est monté et 0 sinon ?
</quote>
Le message ne dit pas quel en serait l'usage mais peu importe c'est un
excellent exemple d'utilitaire assez facile à réaliser. Voici
d'ailleurs un exemple de code source possible :
<code>
------------------------- debut de carrier.c -------------------------
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <stdio.h>
main(int argc, char *argv[])
{
char *whoami, *device;
int fd;
int modem_bits;
whoami = (whoami = strrchr(argv[0], '/')) ? whoami + 1 : argv[0];
if (argc != 2) {
fprintf(stderr, "Usage: %s device-file\n", whoami);
return(EXIT_FAILURE);
}
device = argv[1];
if ((fd = open(device, O_RDONLY | O_NDELAY)) < 0) {
fprintf(stderr, "%s: error opening \"%s\": %s\n", whoami, device,
strerror(errno));
return(EXIT_FAILURE);
}
if (ioctl(fd, TIOCMGET, & modem_bits) < 0) {
fprintf(stderr, "%s: error getting modem line statuses for \"%s\": %s\n",
whoami, device, strerror(errno));
return(EXIT_FAILURE);
}
if (modem_bits & TIOCM_CAR) {
printf("1\n");
return(EXIT_SUCCESS);
}
printf("0\n");
return(EXIT_FAILURE);
}
------------------------- fin de carrier.c -------------------------
</code>
On pourra ensuite l'utiliser dans un <it/shell/ de la manière
suivante :
<code>
if [ `carrier /dev/modem` -eq 1 ]; then
... choses a faire si la porteuse est detectee ...
else
... choses a faire s'il n'y a pas de porteuse ...
fi
</code>
<sect>
Remerciements
<p>
Ce document n'aurait vu le jour sans un certain nombre de gens fort
sympathiques et plein de bonnes idées appartenant pour la plupart
à la mailing list de traduction :
René COUGNENC,\\
Xavier CAZIN,\\
Bernard CHOPPY,\\
François AUDIBERT\\
Eric DUMAS,\\
Pierre FICHEUX, \\
Hervé MIGNOT, \\
Pierre VASSELLERIE, \\
Jacques LAVIGNOTTE, \\
et tous les autres.
</article>
