EDIT : Archive.org n'a eu le temps de mirrorer qu'une version obsolète de siproxd_orange souffrant d'un bug bloquant au login. Ce n'est pas la peine d'essayer de le faire marcher et je ne répondrai pas aux mails ou commentaires à ce propos.

C'est avec peine et regret que j'ai pris la décision de suspendre pour une durée indéterminée tous les liens de téléchargement de siproxd_orange, ainsi que l'accès à son dépôt BitBucket.

Je fais en effet l'objet de pressions de la part d'Orange visant à me faire cesser le développement et la diffusion de siproxd_orange. Après avoir consulté plusieurs personnes dont un avocat spécialisé en droit d'auteur, j'ai estimé plus prudent d'abandonner la diffusion de ce projet.

Je tiens d'abord à remercier toutes les personnes qui ont manifesté leur intérêt pour siproxd_orange, que ce soit en le téléchargeant, en postant des liens vers ce blog sur d'autres sites, en commentant sur les nombreux billets à ce sujet ou en rapportant des bugs. Mais je tiens aussi à ajouter que cela ne signifie aucunement la fin de l'aventure.

Ma motivation : l'interopérabilité

Ma motivation principale était celle d'utiliser un PBX Asterisk sous Linux sur ma ligne Livebox.

La solution la plus simple était d'utiliser l'interface analogique en enfichant une carte FXO/FXS dans la machine, mais cette solution n'est pas sans lacunes. En effet, la Livebox ne signale pas l'état décroché ou raccroché de la ligne à l'aide de signaux électriques. Ce défaut peut entraîner des problèmes potentiellement graves : par exemple, sans hacks à base de « busydetect », le PBX maintient la ligne occupée indéfiniment lorsque la personne à l'autre bout de la ligne raccroche en premier.

En voulant écrire des scripts de supervision Livebox pour Nagios, je suis tombé sur une interface qui exposait une partie des paramètres SIP utilisés par la box : proxy SIP sortant, login, etc., mais bien évidemment pas de mots de passe.

J'ai ensuite constaté que l'application Livephone pour Windows s'enregistrait directement auprès des serveurs SIP d'Orange, à condition de lui fournir les identifiants de l'espace client Orange.

J'ai alors décidé de creuser plus loin afin de savoir quels étaient les identifiants SIP utilisés pour s'authentifier auprès du proxy SIP Orange. Il s'avère que le client SIP officiel n'utilise aucun mot de passe, mais obtient un des secrets nécessaires pour l'échange RFC 2617 (authentification HTTP Digest) par une méthode totalement propre à Orange. Ces secrets étaient impossibles à obtenir sans décompiler l'application d'origine. Impossible donc d'exploiter sa ligne SIP sans autre chose que les applications proposées par Orange.

C'est en modifiant le processus d'authentification qu'Orange cassait l'interopérabilité avec les autres implémentations SIP conformes à la RFC 3261, empêchant ceux-ci de s'enregistrer directement auprès de l'infrastructure d'Orange.

Je m'inscrivais donc dans une double démarche d'interopérabilité : la possibilité d'utiliser un terminal SIP « RFC 3261 » avec ma ligne téléphonique comprise dans l'abonnement que je paye d'une part, et la réimplémentation des extensions propriétaires d'Orange sous Linux et FreeBSD d'autre part.

L'exception de décompilation

C'est dans cette démarche d'interopérabilité que j'estimais être en droit de me prévaloir des dispositions de l'article L122-6-1 du Code de la propriété intellectuelle, qui dispose entre autres que :

IV. La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes :

1° Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ;

2° Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1° ci-dessus ;

3° Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité.

Les informations ainsi obtenues ne peuvent être :

1° Ni utilisées à des fins autres que la réalisation de l'interopérabilité du logiciel créé de façon indépendante ;

2° Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante ;

3° Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.

Le seul aspect qui posait vraiment problème, c'était la question de savoir si j'avais le droit de mettre à disposition le code source de siproxd_orange, qui contenait du coup des informations d'interopérabilité obtenues par décompilation. J'étais en outre obligé de diffuser le code source, car siproxd est sous licence GPL et son système de plugins fonctionne par édition de liens dynamiques. Mais les jurisprudences autour de l'exception de décompilation sont rares et il incomberait à moi de prouver que mon travail satisfaisait toutes les conditions pour me prévaloir de cette exception, ce qui n'est pas certain. L'article de François Pellegrini à ce propos est une lecture intéressante.

J'avais donc prédit avec justesse que la réalisation de ce plugin pour siproxd était « à la limite de la légalité ». La question de savoir si mon travail était licite ou illicite était ténue.

J'ai pris des risques en proposant siproxd_orange ici. J'aurais pu faire le choix de continuer malgré les pressions et, si nécessaire, me défendre au tribunal. Mais dans le pire cas, je risquerais de perdre plus que juste la mention « néant » dans mon casier judiciaire.

Conclusion

Je suis vraiment triste de devoir prendre ce genre de décisions. Je suis triste à l'idée de décevoir le grand nombre de personnes qui semblaient intéressés par ce projet. Mais je suis surtout triste de devoir prendre des décisions contraires à mes valeurs de curiosité scientifique et de partage du savoir.

Il s'agissait de mon plus gros projet de rétroingénierie jusqu'à maintenant. Même en mettant hors ligne les archives des sources de siproxd_orange, je n'accepterai pas l'idée d'avoir sacrifié tous ces week-ends, toutes ces soirées et toutes ces pages de mon cahier de brouillon en vain.

L'étape d'après serait d'obtenir les informations nécessaires à l'interopérabilité par une autre voie que la décompilation, par une méthode qui m'autoriserait à les publier. Je n'en dirai pas plus ; je sais désormais que des salariés d'Orange ouvertement hostiles à ce projet me lisent.

En tout cas, je n'ai pas dit mon dernier mot.

Mise à jour : RIP siproxd_orange :(

En cette veille de journée de deuil national, la version 0.2.1 de siproxd_orange est désormais disponible au téléchargement.

Cette version est une release "hotfix", corrigeant plusieurs bugs dont un bloquant. Orange a en effet décidé à partir d'aujourd'hui d'interdire l'accès au client Livephone sous Windows, qui était en téléchargement jusqu'à il y a quelques mois. Or siproxd_orange se faisait encore passer pour le client Windows, d'où une impossibilité de s'authentifier.

D'autres bugs plus ou moins importants ont également été résolus dans la foulée ; l'un d'entre eux empêchait encore une fois le bon fonctionnement des appels entrants dans certaines situations.

Téléchargements

Vous pouvez télécharger les archives à l'une des adresses suivantes :

• siproxd_orange-0.2.1.tar.bz2
• siproxd_orange-0.2.1.tar.gz

x0r.fr en deuil

J'ai décidé d'habiller x0r.fr en noir pour les journées du 7 et 8 janvier 2015, afin d'exprimer toute mes pensées et mes condoléances aux victimes de l'attentat abject survenu dans les bureaux de Charlie Hebdo. J'ai du mal à trouver les mots qui traduiraient le mieux ce que je ressens en ce moment.

J'évite habituellement toute polémique sur ce site Web ; une de ses grandes lignes éditoriales est d'être neutre, encyclopédique et factuel dès que possible. Néanmoins, il me paraît opportun de se rappeler qu'il a parfois fallu verser du sang afin d'obtenir les libertés dont nous jouissons aujourd'hui et qu'il est nécessaire de les défendre à tout prix pour que nous puissions continuer à faire ce que nous aimons dans la vie en toute sérénité.

En tant que blogueur, même si j'ai toujours publié des billets purement techniques ici, je me sens particulièrement concerné par cette grave atteinte à la liberté de la presse. Une chose est sûre selon moi : les conséquences politiques de cet acte seront lourdes, et ces conséquences toucheront sans aucun doute tout le monde, d'une manière ou d'une autre.

J'avais déjà théorisé dans un post précédent les raisons pour lesquelles l'autohébergement pourrait peut-être revenir en vogue parmi les personnes les plus curieuses ou les plus sensibilisées aux problématiques sous-jacentes.

L'une des considérations principales et là où se font les choix techniques les plus importants est le choix du matériel serveur ; j'entends dans ce cas par « serveur » toute machine remplissant la fonction de serveur, fournissant des services accessibles à des postes dits « clients », et non pas le matériel spécialement dédié à cette fonction (type Dell PowerEdge ou HP ProLiant pour ne citer que quelques-uns).

L'autohébergement ne consiste pas nécessairement à transformer son domicile en datacenter avec des dizaines de serveurs et une climatisation qui tournent à fond les ballons. Dans la plupart des cas, il n'y en a absolument pas besoin. Le but est simplement d'héberger ses propres services informatiques tout en gardant la maîtrise totale sur l'infrastructure. Les exemples de services autohébergés sont nombreux :

• consulter et stocker ses e-mails sur un serveur mail chez soi au lieu de dépendre d'un prestataire externe ;
• héberger un site Web ;
• centraliser le stockage de fichiers multimédia ;
• déployer de la voix sur IP chez soi pour des besoins spécifiques en téléphonie...

Je ne parlerai pas des avantages et des inconvénients de l'autohébergement, car je suppose que le choix a déjà été fait ; cet article s'adresse surtout à ceux qui s'interrogent sur les choix matériels. Néanmoins, il convient de rappeler qu'un des avantages principaux de l'autohébergement est celui de la maîtrise intégrale du matériel réseau et serveur chez soi, et qu'il est donc possible de choisir le matériel adapté parmi une gamme très large de possibilités.

Avant de commencer, je précise que mes prises de position dans cet article sont le fruit de choix que j'ai moi-même faits face à mes propres besoins et à ma propre situation, et que les meilleurs choix pour moi ne sont pas forcément les meilleurs pour vous.

Le matériel serveur

Comme je le disais, on dispose d'une large gamme de possibilités quant à la machine jouant le rôle de serveur, mais il est possible de les diviser en trois catégories :

• le matériel dit "embarqué" : par exemple, un Raspberry Pi, ou une plateforme matérielle comme celles de Soekris. Ces matériels ont l'avantage d'être minimalistes, silencieux, très peu encombrants et de consommer très peu (quelques watts), mais les pièces de rechange risquent d'être difficiles à trouver ou d'être onéreuses ;

• les PC de bureau : une machine neuve construite à cet effet, ou un vieux PC de bureau d'un âge compris entre 6 et 10 ans dont on a peut-être augmenté le stockage ou la RAM, font l'affaire selon les besoins. Les pièces de rechange sont très faciles à trouver, relativement peu chères, et de telles machines tiennent aisément des uptimes tout à fait respectables qui se comptent en centaines de jours.

• les matériels dédiés « serveur » : si on a un peu plus de budget, la possibilité de s'isoler du bruit, et des colocataires complaisants, un serveur d'occasion pourrait être une option. Il s'agit de matériel vendu aux entreprises, donc moins sujet à l'« obsolescence programmée », ayant comme atout principal la fiabilité et laisse la possibilité de se procurer des pièces détachées pendant longtemps.

Personnellement, j'ai fait le choix de partir sur un PC de bureau, autant par opportunisme que par manque d'argent (il s'agissait d'une machine qu'un voisin voulait mettre aux encombrants alors qu'il suffisait de remplacer l'alimentation et ajouter des disques durs et une carte graphique, et j'étais étudiant à l'époque), mais cette machine a été très fiable jusqu'à maintenant et a déjà dépassé 400 jours consécutifs d'uptime.

Le matériel réseau

J'entends par matériel réseau tout l'équipement nécessaire pour la mise en réseau de ses machines, c'est-à-dire les commutateurs (switchs) et les routeurs. Il faut au moins un routeur et, dans la plupart des cas, au moins un switch.

Le routeur doit permettre la redirection de ports, ou un "mode DMZ". Je suis parti sur un TP-Link TL-WR1043ND, étant donné qu'il propose du wifi N et un routage NAT IPv4 en gigabit tout en restant tout à fait abordable, et marche assez bien avec la toute dernière version d'OpenWRT. Je préfère reflasher mes routeurs avec OpenWRT, car cela permet parfois de débloquer des fonctionnalités absentes du firmware initial, comme la prise en charge de VLANs ou la prise en charge d'IPv6. Il y a cependant peut-être de meilleurs choix possibles en ce moment.

J'ai personnellement horreur du Wi-Fi parce que j'ai le sentiment que ça ne marche jamais de manière robuste, donc je préfère tout câbler. Pour cette raison, j'avais pris deux switchs TP-Link SG-1008D complètement passifs, qui sont bon marché et font bien leur travail, mais je les ai depuis remplacés par des TP-Link TL-SG3210 qui sont administrables, ont plus de fonctionnalités et gèrent les VLAN.

Heureusement, la plupart du matériel réseau, aussi bien ceux destinés au grand public que certains destinés aux PME, fonctionne sans ventilateur et se fait relativement discret.

Le matériel que je mentionne suffit largement pour un réseau "simple", mais comme je suis en train de mettre en place de la VoIP, j'ai envie de jouer avec des VLAN séparés pour la voix et les données notamment. Mais l'essentiel reste de retenir que pour héberger des services chez soi, il n'y a nul besoin de mettre 2 000 € dans du matériel réseau.

Étant donné l'obsolescence du protocole IPv4, je choisis si possible du matériel compatible IPv6, même si Orange ne le propose pas encore aux particuliers au moment où j'écris ces lignes. Les deux exceptions notables chez moi sont mes téléphones IP et mon imprimante réseau, mais ceux-là seront remplacés à un moment opportun.

Le facteur d'acceptation conjugale

J'ai déjà entendu l'histoire d'un collègue qui s'est retrouvé devant le dilemme suivant : jeter le contenu entier d'une baie 42U qu'il possédait chez lui, ou se retrouver divorcé de son épouse. Il avait alors choisi de jeter sa baie 42U, mais cela n'a pas pu empêcher le divorce.

On sort ici peut-être du cadre strictement technique, mais il s'agit d'un sujet qui peut aussi bien stimuler que tuer dans l'œuf tout projet d'autohébergement.

Le Spousal Acceptance Factor (que je traduirais par « facteur d'acceptation conjugale ») est le terme généralement utilisé pour exprimer la probabilité de l'approbation d'un projet de bricolage par les autres personnes du foyer. Cela ne s'applique pas qu'à l'autohébergement, mais à n'importe quel projet, comme de la domotique ou la mise en place de téléphonie IP. Le terme le plus répandu est Wife Acceptance Factor, mais je préfère employer un terme non genré.

Il est tout à fait regrettable de voir que certaines personnes utilisent ce terme sans le définir de manière précise (ou retiennent des critères entièrement subjectifs), voire de manière méprisante. C'est pourquoi je souhaite aller un peu plus loin que de basses considérations sexistes qui masqueraient le vrai problème.

Le point commun de toutes les sources évoquant ce facteur que j'ai pu lire montre que cela peut se résumer à une liste de critères dont une partie est mesurable. Cette liste de critères semble hélas être établie de manière purement empirique. Une partie des critères que j'ai retenue moi-même pour mes achats de (nouveau) matériel est la suivante :

• pas trop de LEDs trop lumineuses, afin de pouvoir dormir la nuit (en particulier lorsqu'on habite dans un appartement à une seule pièce, ce qui était mon cas pendant mes études) ;

• bruit négligeable en fonctionnement nominal (pas plus de 30 dB(A) à un mètre), donc minimiser les ventilateurs et leur vitesse de rotation, et privilégier le matériel sans ventilateurs si possible, afin de ne pas subir le bruit permanent des ventilateurs et pouvoir dormir la nuit ;

• emprise au sol la plus petite possible, pour pouvoir être posé discrètement dans la pièce de son choix ;

• de manière générale, une esthétique discrète ;

• en dernier, mais pas des moindres : une « bonne » fiabilité (i.e. un taux de disponibilité d'au moins 99,8%) du matériel et des services fournis, pour que cela reste intéressant. En deux ans et malgré un déménagement l'année dernière, mon serveur a su tenir un taux de 99,5%, et je dois approcher les 99,9% rien que cette année.

Conclusion

Il est donc tout à fait possible d'opter pour du matériel discret, relativement peu onéreux et suffisamment performant pour la plupart de ses projets d'autohébergement.

Même si la question du matériel est essentielle, ce n'est pas le seul problème à résoudre lorsqu'on met en place un tel projet. L'étape suivante reste la conception du réseau et les choix logiciels, qui feront peut-être l'objet d'un autre article dans le futur.

Mise à jour : RIP siproxd_orange :(

La version 0.2 de siproxd_orange est maintenant disponible !

Cette version est le fruit de beaucoup de reverse engineering, cette fois de l'application Android. D'importants bugs ont été résolus dans cette version : une étape de l'authentification qui change, et l'algorithme (censuré), également nécessaire pour l'authentification, qui comportait des erreurs. La chasse à ces deux bugs, et plus particulièrement le second, était loin d'être de tout repos.

D'autres bugs plus ou moins importants ont également été résolus dans la foulée ; l'un d'entre eux empêchait le bon fonctionnement des appels entrants dans certaines situations.

Téléchargements

Vous pouvez télécharger les archives aux adresses suivantes :

• siproxd_orange-0.2.tar.bz2
• siproxd_orange-0.2.tar.gz

Étant donné qu'Orange a déjà cessé de mettre à disposition l'application Livephone sur PC et envisage de couper le service sur PC, je croiserai les doigts pour que siproxd_orange continue de fonctionner quoi qu'il arrive.

Je vous ai déjà expliqué comment relier son Minitel comme terminal Linux, ou alors comment le relier à un Raspberry Pi. Mais s'arrêter là, ce serait oublier que le Minitel est initialement conçu pour consulter des pages Vidéotex avec son modem 1200/75 bauds intégré.

À une époque où le terme « Minitel 2.0 » est utilisé de manière péjorative et où la plupart des terminaux Minitel que l'on trouve sont sur eBay, LeBonCoin, à la déchetterie ou oubliés dans un grenier, quelle idée plus saugrenue que de mettre en place, justement, son propre serveur Minitel ? Après tout, les plus jeunes d'entre nous n'ont pas connu le Minitel. En ayant tenu un stand lors de l'événement « 3615 au revoir », j'ai pu me rendre compte que beaucoup de personnes, même plus âgées que moi, n'ont pas eu l'opportunité de voir fonctionner un Minitel, et de ce fait voir comment on faisait dans les années 80-90 pour réserver un billet de train. Outre le désir de préservation ou de fascination pour les technologies obsolètes, faire cela pour la pure prouesse technique me paraît de surcroît tout à fait justifié.

Le schéma de principe est celui utilisé pour pouvoir tester facilement le montage chez soi sans avoir à dépenser des montants indécents en factures téléphoniques. L'avantage d'utiliser un PBX maison réside aussi dans le fait de pouvoir utiliser une ligne SIP (comme celles d'OVH ou d'Ippi, au hasard) pour que les utilisateurs puissent appeler directement le numéro. Si on ne tient pas à tester, il suffirait juste de brancher le modem 56k à la ligne téléphonique d'Orange, mais nous partirons ici du principe que nous disposions de tout l'équipement du schéma ci-dessus.

Il nous faut donc plusieurs éléments :

• une application (ncurses ou minicurses) exécutée sur le serveur et qui s'occupe de la présentation des informations sur le Minitel de l'utilisateur ;
• un serveur sur laquelle tourne cette application ;
• un modem 56k (ou tout autre modem qui sache gérer le mode V.23bis) compatible avec le jeu de commandes Hayes, branché en série sur le serveur applicatif. Ce modem servira à recevoir les appels téléphoniques des utilisateurs et le serveur décrochera automatiquement pour établir la liaison de données avec le Minitel appelant ;
• un commutateur téléphonique (aussi appelé PBX) pour le routage des appels et pour la mise en place d'un plan de numérotation interne, ce qui nous permet de tester tranquillement le montage ;
• un téléphone analogique (oui, analogique) parce que le modem du Minitel ne sait pas numéroter par lui-même (du moins celui des Minitel 1, 1B et 2) ;
• enfin, vous l'aurez deviné, un Minitel.

Il n'est pas obligatoire d'avoir deux machines physiquement séparées pour le PBX et le serveur applicatif. On peut utiliser la même machine pour les deux rôles. Cela me permettait juste de rendre le schéma plus intelligible.

En ce qui concerne le PBX, rien de compliqué : une machine munie d'une carte OpenVox A400p et d'Asterisk fait largement l'affaire. Prévoir dans ce cas au moins deux interfaces FXS et la possibilité de faire sonner le modem depuis le téléphone analogique (en lui attribuant son propre numéro, comme par exemple 4001 pour le téléphone et 4002 pour le modem).

Branchements matériels

Câblez le montage de la manière suivante :

1. Branchez la prise T du téléphone en aval de la prise T du Minitel.

2. Branchez la prise T du Minitel sur le PBX. Il y a de grandes chances que le PBX n'accepte que des prises RJ11 ; on peut alors brancher un câble RJ11 côté PBX sur un adaptateur T vers RJ11 et brancher l'ensemble dessus. C'est certes peu élégant, mais ça marche.

3. Branchez la prise téléphonique du modem 56k sur le PBX et le câble série sur le serveur applicatif.

Configuration logicielle

De la même manière que lorsqu'on utilise le Minitel comme terminal série, il vous faudra installer mgetty(8).

La configuration de mgetty(8) fait que ce sera a priori impossible d'utiliser en même temps une application depuis le modem sur un Minitel, ou comme console série comme précédemment. Il vous faudra choisir, ou alors faire ces manipulations sur une autre machine.

Dans cette section, subsituez le nom de votre port série à /dev/ttyUSB0 (j'ai fait mes tests en branchant mon modem sur un convertisseur USB-série).

Dans /etc/mgetty+sendfax/mgetty.config, ajouter une section comme celle-ci :

port ttyUSB0
  speed 1200
  direct no
  data-only yes
  toggle-dtr yes
  need-dsr yes
  port-owner root
  port-group wheel
  port-mode 0660
  login-prompt ''
  login-time 60
  term minitel1b-80
  login-env-ttyprompt-hack yes
  init-chat "" "ATM0E0B2\r" "OK"
  gettydefs 1200v23

Le init-chat est probablement à adapter selon vos besoins et selon votre modem. Renseignez-vous dans la documentation de votre modem. Mon Olitec Self Memory Pro nécessite ATB2 pour forcer la vitesse de ligne à 1200/75 baud. Ajouter également E0 pour désactiver l'écho local et M0 pour désactiver le haut-parleur et expérimenter en silence.

Dans /etc/mgetty+sendfax/login.config, remplacez la dernière ligne par :

*       toto     toto     /chemin/vers/application

où la deuxième colonne représente l'utilisateur sous lequel est exécuté l'application, et la troisième colonne représente l'entrée à ajouter dans utmp(5) (la laisser égale à la deuxième colonne marche bien aussi).

Dans /etc/gettydefs, ajouter (oui, toujours en une seule ligne) :

1200v23# B1200 CS7 PARENB -PARODD GLOBAL #B1200 ISTRIP CS7 PARENB
-PARODD GLOBAL BRKINT IGNPAR ICRNL IXON IXANY OPOST ONLCR CREAD HUPCL
ISIG ICANON ECHO ECHOE ECHOK #@S login: #1200v23

Dans /etc/inittab, ajouter :

s0:12345:respawn:/sbin/mgetty -D ttyUSB0 1200v23

Configuration du PBX

Je ne vais pas vous apprendre comment configurer un plan de numérotation sur Asterisk, mais vous aurez seulement besoin d'une configuration qui permette de faire "sonner" le modem. En d'autres termes, il faut brancher le modem sur une des interfaces FXS de votre PBX, attribuer un numéro de téléphone à ce port (par exemple 4002) et faire en sorte de pouvoir composer ce numéro depuis un autre téléphone branché sur ce même commutateur. C'est vraiment pas plus compliqué que ça !

Lorsque votre modem "sonne", il réagira sûrement en faisant clignoter une ou deux LEDs. Pour en être sûr, connectez-vous directement sur le modem via le port série et vérifiez que le modem envoie des messages RING sur le terminal lorsque vous l'appelez.

Exemple d'application

En guise d'application, n'importe quel programme qui écrit du texte sur stdout et lit des frappes de touches sur stdin fait l'affaire.

#!/bin/bash

stty 1200 istrip cs7 parenb -parodd brkint \
    ignpar icrnl ixon ixany opost onlcr cread hupcl -isig icanon \
    echo echoe echok

# vider l'écran
echo
printf "\x0c"

# mettez le chemin vers votre binaire ici, ou rédigez votre programme
# en shell ci-dessous

# écrire du lorem ipsum à l'écran
# (sans oublier qu'on n'a que 40 caractères par ligne)
echo "Lorem ipsum dolor sit amet, consec-
tetur adipiscing elit. Donec a diam
lectus. Sed sit amet ipsum mauris. 
Maecenas congue ligula ac quam 
viverra nec consectetur ante 
hendrerit. Donec et mollis dolor. 
Praesent et diam eget libero egestas
mattis sit amet vitae augue. Nam
tincidunt congue enim, ut
porta lorem lacinia consectetur."

sleep 10

Libre à vous d'utiliser autre chose qu'un script shell, bien entendu. Il faut juste penser à faire le stty(1) correspondant afin de forcer l'observation du bit de parité paire (dans le cas contraire, la moitié des caractères seront remplacés par des carrés blancs).

L'instant de vérité

Après avoir ajouté la configuration qui va bien dans /etc/inittab, n'oubliez pas un petit init q pour qu'init tienne compte de votre configuration.

Allumez votre Minitel. Composez le numéro correspondant au modem. Si tout se passe bien, vous entendrez peut-être quelques bruits (bips), puis, le plus important, une tonalité aiguë continue (2 100 Hz, plus exactement) que vous reconnaîtrez sûrement si vous avez déjà utilisé un Minitel avant.

Au moment où vous entendez le 2 100 Hz, appuyez sur la touche Connexion/Fin de votre terminal. Le F en haut à droite est alors remplacé par un C clignotant, qui devient fixe au bout de quelques secondes. Enfin, si tout est bien configuré, votre Minitel affiche votre Lorem Ipsum (ou toute autre application que vous y aurez mise à la place). Et c'est exactement comme ça que cela se passait en 1982.

Conclusion

Étant donné que le service Minitel n'existe désormais plus, c'est une partie du patrimoine français qui est en voie de disparition si nous ne trouvons pas le moyen d'archiver, voire reproduire, ce que l'on pouvait faire sur Minitel entre 1982 et 2012.

Mettre en place un serveur Minitel reste donc bien entendu une idée saugrenue, mais le challenge technique derrière reste particulièrement intéressant. Je salue particulièrement ceux qui, dans les années 80 et 90, ont mis en place leur propre serveur privé, sachant qu'ils disposaient à l'époque de machines beaucoup moins puissantes.