La Livebox d'Orange comporte, outre les connexions réseau et Wi-Fi habituelles, une prise FXS à l'arrière conçue pour y brancher un téléphone analogique. Comme je le disais auparavant, il s'agit là d'une des manières les plus simples d'exploiter la ligne fixe fournie avec toute connexion Internet Orange.

Sur la prise FXS et lorsque la Livebox détecte un problème sur la ligne téléphonique, elle substitue à la tonalité un message en boucle comme : « Un problème a été détecté sur votre ligne téléphonique. Veuillez redémarrer la Livebox. Si le problème persiste, veuillez contacter le service client Orange ». Puis la tonalité classique revient lorsque la ligne est à nouveau opérationnelle.

Seulement, dans certaines circonstances, cela allait de pair avec des sonneries intem­pestives  : la première lorsque la ligne était en dérangement et la seconde lorsque le pro­blème disparaissait. De plus, il s’agissait souvent de problèmes transitoires pendant que la Livebox se resynchronisait en PPPoE. Par conséquent, j’ai régulièrement été réveillé à 3 h du matin par cette box.

Étant donné, de plus, que j'avais déjà mis en œuvre Asterisk chez moi et que je supervisais déjà moi-même l'état des services Orange avec Icinga, je considérais donc que je disposais des outils pour filtrer ces sonneries intempestives. Ce billet propose donc de vous montrer comment j'ai fait.

L’idée

Ces sonneries intempestives prennent la forme d’appels anonymes et surviennent seulement lorsque la box considère que la ligne téléphonique est en dérangement. L’idée est donc de programmer Asterisk pour reconnaître ces deux caractéristiques.

Reconnaître un appel masqué dans Asterisk est facile. Déterminer la disponibilité du téléphone du point de vue de la Livebox est en revanche une autre histoire. Heureusement, mes scripts Nagios pour la Livebox remplissent exactement cette fonction ; il est donc possible de l’utiliser dans mon test. Nous allons également nous aider de l’interface AGI pour réaliser ce test.

Le script AGI

AGI, ou Asterisk Gateway Interface, est en effet une interface pour faire exécuter des scripts par Asterisk. Ces scripts accomplissent des tâches impossibles ou trop fastidieuses à mettre en œuvre via extensions.conf ou extensions.ael. Le principe est le même que celui de l’interface CGI dans le monde du Web : on peut utiliser n’importe quel langage de program­mation (C, Perl, Python…) du moment qu’on puisse écrire sur stdout, lire sur stdin, accepter des arguments de ligne de commande et que le fichier soit exécutable.

Les scripts AGI doivent être placés dans un répertoire spécifique qui dépend de votre installation Asterisk. Sous FreeBSD, il faut les placer dans /usr/local/share/asterisk/agi-bin et les rendre exécutables avec la commande chmod +x. J’ai appelé ce script stfu-livebox.agi. Voici son code source :

#!/usr/bin/env perl

use strict;
use warnings;

$| = 1;

use Asterisk::AGI;
use LWP::UserAgent;

my $AGI = new Asterisk::AGI;
my %input = $AGI->ReadParse();

my $replacement_name = $ARGV[0];
my $replacement_number = $ARGV[1];

$replacement_name ||= 'Livebox';
$replacement_number ||= 'Livebox';

$AGI->verbose("Run stfu-livebox.agi", 1);

sub is_trunk_alive {
    my $ret = system('/usr/local/libexec/nagios/check_livebox_phone', '-H', '192.168.1.1');
    $ret >>= 8;

    return ($ret == 0);
}

sub is_anon {
    return ($input{'callerid'} eq 'unknown');
}

sub main {
    if (is_anon() && !is_trunk_alive()) {
        $AGI->set_variable('CALLERID(name)', $replacement_name);
        $AGI->set_variable('CALLERID(name-pres)', 'allowed_not_screened');
        $AGI->set_variable('CALLERID(number)', $replacement_number);
        $AGI->set_variable('CALLERID(num-pres)', 'allowed_not_screened');
    }
}


main();

Le principe du script est le suivant : à chaque appel anonyme, il exécute le plugin Nagios check_livebox_phone, qui détermine l’état de la ligne téléphonique vue par la Livebox. Si la ligne est hors service, il positionne un numéro et un nom spécifiques.

Le nom et le numéro présentés sont « Livebox » par défaut, mais il est possible d’utiliser autre chose. Par exemple, sur mon installation, je lui fais présenter un numéro qui a peu de chances de m’appeler depuis l’extérieur : mon propre numéro.

Intégration dans le dialplan d’Asterisk

Maintenant que nous avons le script AGI, il ne reste plus qu’à l’appeler depuis le dialplan d’Asterisk au moyen de l’application AGI :

AGI(stfu-livebox.agi,Livebox,0199998765);

Il suffit ensuite de préparer le reste du dialplan, et notamment les instructions qui bloquent ces sonneries la nuit. Dans mon installation, j’en ai profité pour renvoyer les appels masqués immédiatement vers la messagerie vocale entre 23 h et 6 h et de complètement bloquer ces sonneries si elles proviennent de la Livebox durant cette même plage horaire. En AEL, cela donne :

Set(ALLOW_RINGING=1);
Set(ALLOW_VOICEMAIL=1);

// Traitement spécifique pour les appels anonymes
if ("${LEN(${CALLERID(number)})}" = "0") {
        Set(CALLERID(name-pres)=unavailable);
        Set(CALLERID(num-pres)=unavailable);

        AGI(stfu-livebox.agi,Livebox,0199998765);

        // Autoriser les appels anonymes de 6 h à 23 h seulement
        ifTime(06:00-22:59|*|*|*) {
                Verbose(1,Appel masqué autorisé le jour);
        } else {
                Set(ALLOW_RINGING=0);
                if ("${CALLERID(name)}" = "Livebox") {
                        Verbose(1,Sonnerie de la Livebox refusée la nuit);
                        Set(ALLOW_VOICEMAIL=0);
                } else {
                        Verbose(1,Appel masqué la nuit, renvoi vers répondeur);
                }
        }

} else {
        // Continuer normalement
}

// Faire sonner tous les téléphones
if ("${ALLOW_RINGING}" = "1") {
        Dial(${ALL_PHONES},25,xt);
}

// Si non-réponse ou rejeté, rediriger vers le répondeur
if ("${ALLOW_VOICEMAIL}" = "1") {
        Answer();
        VoiceMail(BoiteCommune);
} else {
        Hangup(21);
}

Hangup();

Vous remarquerez que j’utilise deux variables, ALLOW_RINGING pour déterminer si l’appel entrant peut accéder aux téléphones chez moi (c’est-à-dire les faire sonner) et ALLOW_VOICEMAIL pour déterminer si l’appelant peut enregistrer un message vocal. Ceci permet de gérer facilement les trois cas qui se présentent à nous dans ce dialplan.

Conclusion

Ces modifications à Asterisk font exactement ce que je voulais, c’est-à-dire ne plus être réveillé la nuit lorsque la Livebox se resynchronise. En pratique, seule la première des deux sonneries intempestives est effectivement filtrée : au moment où survient la seconde sonnerie, le script check_livebox_phone indique que la ligne téléphonique est à nouveau opérationnelle.

J’aurais pu résoudre ce problème en apportant une petite modification : lorsqu’Asterisk bloque la première de ces deux sonneries, qui est facile à reconnaître, on pourrait positionner une valeur dans la base de données AstDB pour bloquer l’appel anonyme qui suit immédiatement cette première sonnerie.

Mais en pratique, depuis qu’Orange a cessé d’utiliser PPPoE, ces resynchronisations hebdomadaires n’arrivent quasiment plus jamais, donc c’est plus difficile à tester.

Enfin, en cherchant un peu, ma solution était peut-être complètement excessive : d’après une poignée de forums, ces sonneries intempestives seraient dues à la notification visuelle de messages ; une fonction qui est seulement prise en charge par certains téléphones (mais pas Asterisk) et que je suis sûr de ne pas utiliser, parce que mon répondeur est déjà géré par Asterisk. Cela reste néanmoins un bon exercice de programmation AGI que je souhaitais partager.

Le 15 janvier 2016, le Ministère de la Culture annonçait que la disposition AZERTY n’est pas adaptée à la langue française et qu’il fallait donc trouver ou inventer une meilleure disposition de clavier.

J’ai été agréablement surpris, tout d’abord, qu’ils mentionnaient dans le document intitulé « Repère claviers » une disposition déjà existante et qui pourrait parfaitement convenir : la disposition bépo.

C’est donc par curiosité que j’ai voulu essayer la disposition bépo. J’en avais déjà beaucoup entendu parler, mais c’est cette publication du Ministère qui m’a poussé à franchir le pas.

Ce billet est mon compte-rendu de six mois d’apprentissage, de perfectionnement et de pratique de cette disposition de clavier. J’espère ainsi en convaincre d’autres de l’essayer et de l’adopter.

Origines du bépo

Le bépo a été le résultat de travaux datant du milieu des années 2000. L’idée principale est de placer les lettres les plus fréquemment utilisées en français sur les touches les plus facilement accessibles : celles de la rangée du milieu.

Des travaux similaires avaient été faits dans les années 1930 par August Dvorak, donnant le clavier simplifié Dvorak ou tout simplement le clavier Dvorak.

Cependant, à la différence des travaux de Dvorak, le corpus de textes utilisé pour la mise au point de la disposition bépo était non seulement constituée de textes littéraires, mais aussi d’extraits de code source, d’e-mails et de conversations de messagerie instantantée. Ce qui confère au bépo déjà de nombreux avantages par rapport à l’AZERTY et au QWERTY.

Avantages du bépo

En plaçant les lettres les plus fréquentes sur les touches les mieux accessibles, cette disposition est plus confortable et moins fatigant pour les mains. Elle tient également compte des besoins plus spécifiques liés à la programmation : par exemple, les symboles courants comme { } < > [ ] sont tapés en appuyant sur AltGr combiné avec une touche sous la main gauche. Sur QWERTY, ces symboles sont sur le côté droit du clavier en accès direct ou via la touche Maj, mais en AZERTY, la saisie de ces symboles demande souvent au typiste de se contorsionner les mains. Ceux qui ont déjà fait du LaTeX sur clavier AZERTY sauront de quoi je parle !

Mais le plus important, c’est que le bépo comporte tous les symboles et tous les caractères nécessaires pour écrire correctement en français. Les concepteurs du bépo ont d’ailleurs aussi tenu compte des besoins des langues régionales (occitan, breton…) et de nombreuses autres langues européeennes s’appuyant sur l’alphabet latin (y compris, au passage, l’espéranto).

Le bépo prévoit notamment :

• les majuscules accentuées, comme dans le mot « État » (l’omission de l’accent constitue d’ailleurs une faute d’orthographe) ;
• les caractères « e dans l’o » et « e dans l’a », comme dans « sœur » ou « curriculum vitæ » ou encore « Œdipe » ;
• les guillemets français de premier niveau « » et de second niveau “ ” ;
• une disposition unique et complète : il n’y a aucune « variante » entre les différents constructeurs de matériel ou les fabricants de systèmes d’exploitation (par exemple, pour taper une barre verticale « | », la combinaison est différente sur PC ou sur Mac en AZERTY mais pas en bépo) ;
• en dernier mais pas des moindres : un apprentissage bien plus simple grâce à une disposition qui paraît « logique » grâce à de nombreux petits raffinements. Par exemple, tous les symboles de ponctuation devant être précédés d’un espace insécable sont sur la touche Maj, qui permet également de taper l’espace insécable (Maj + Espace).

Apprendre le bépo comme une deuxième disposition constitue également une opportunité pour apprendre à taper au clavier correctement avec une méthode de dactylographie, c’est-à-dire entre autres sans jamais regarder les touches.

 Installation du bépo

Je ne détaillerai pas la marche à suivre pour pouvoir taper en bépo sur votre système : cela ne ferait que dupliquer les instructions qui existent déjà sur le site bepo.fr. Je note cependant que la plupart des OS libres (sauf Android) intègrent déjà le bépo.

Mon apprentissage du bépo

Maintenant que j’ai traité les raisons pour lesquelles j’ai été tenté d’essayer le bépo, je vais détailler un peu les différentes phases par lesquelles je suis passé dans mon apprentissage puis de ma maîtrise du bépo.

Tout d’abord, changer une habitude qu’on a depuis des années (voire des décennies) peut paraître extrêmement difficile. En réalité, c’est à la portée de tous, du moment qu’on s’accorde les moyens. En outre, en quatre mois, j’avais déjà quasiment atteint la vitesse de frappe que j’avais mis vingt ans à acquérir en QWERTY, en sachant que je pourrais probablement faire encore mieux au fur et à mesure que je continue à taper en bépo. N’est-ce pas là un retour sur investissement intéressant ?

En tout cas, voici comment j’ai procédé : tout d’abord, par des exercices quotidiens pendant trois à quatre semaines, sans dépasser quinze minutes par jour. Ensuite passer en bépo par défaut sur toutes mes machines, en profitant d’un moment « creux » sans deadlines ou quoi que ce soit à terminer dans l’urgence. Le tout est de mettre l’accent non pas sur la vitesse de frappe mais sur la précision.

Les trois premières semaines : exercices quotidiens

Les trois à quatre premières semaines sont les plus importantes et c’est un temps d’apprentissage pendant lequel j’ai fait des exercices et uniquement des exercices.

J’avais failli commettre l’erreur de passer immédiatement en bépo comme disposition du clavier par défaut. Mais le but est a contrario d’apprendre la disposition petit à petit, pour se donner le temps tout d’abord d’acquérir les réflexes et entraîner sa « mémoire musculaire ». On commence par taper des suites de « e t e t et te ette » mais on a le sentiment de progresser vite : on finit très vite déjà par savoir taper des phrases simples comme « tu essaies un instant et tu es saisi ».

Ensuite, j’ai aussi failli être tenté de me précipiter pour « ré-étiqueter » son clavier en bépo, mais je n’ai pas cédé à cette tentation. Je n’aime pas les autocollants et cela incite de plus à regarder le clavier alors que le but est justement d’éviter cela.

Enfin, il est également contreproductif de faire des sessions de plus de quinze minutes. L’acquisiton de nouveaux réflexes nécessite de s’exercer à tête reposée et cela demande beaucoup d’effort mental.

J’ai fait pendant plusieurs semaines des exercices sur l’outil en ligne Bépodactyl. Certains recommanderaient Klavaro pour s’entraîner mais Bépodactyl a l’avantage de n’exiger l’installation d’aucun autre logiciel.

J’ai profité de l’opportunité pour acheter un TypeMatrix étiqueté en bépo (pour le style et pour m’assurer que mes collègues n’y touchent pas) afin de m’aider à apprendre la disposition et en espérant que ce clavier serait plus confortable pendant l’apprentissage.

Le grand saut

Au bout de quatre semaines, j’étais prêt à passer toutes mes machines en bépo. Sous X11 cela n’est pas très difficile :

Section "InputClass"
    Identifier "evdev keyboard catchall"
    Option "XkbLayout" "fr"
    Option "XkbVariant" "bepo"
    Option "XkbOptions" "kpdl:commaoss"
EndSection

J’en profite également pour positionner l’option Xkb pour que l’appui sur la touche « point » du pavé numérique insère une virgule au lieu d’un point (avec le point en AltGr).

Au moment du grand saut, j’étais à 20 mots par minute. Trop peu pour avoir une bonne répartie sur IRC mais suffisant pour des mails, même si j’étais certes un peu plus lapidaire.

Les deux mois suivants : perfectionnement

Néanmoins, pendant deux mois, ma vitesse de frappe augmentait rapidement et de façon régulière : je gagnais peu ou prou cinq mots par minute chaque semaine. Pour ça, je n’ai fait que deux choses : taper le plus possible d’une part, et faire des exercices sur Dactylotest d’autre part pour mesurer ma vitesse et ma précision.

À 35 mots par minute, je commençais déjà à pouvoir reprendre mes activités habituelles impliquant le clavier, que sont le boulot, le code et IRC, mais toujours à une vitesse bien en-deçà de ce dont j’avais l’habitude.

À environ 50 mots par minute, la progression de ma vitesse de frappe commençait à ralentir, mais entretemps je gagnais lentement mais sûrement en précision. Cette vitesse de frappe est déjà largement suffisante dans la plupart des situations. Quoi qu’il en soit, j’avais alors passé pas moins de trois mois pour regagner les deux tiers d’une vitesse de frappe que j’avais accumulée pendant vingt ans.

Le bépo dans la vraie vie

En plusieurs mois, j’ai eu suffisamment le temps de constater à quel point le passage au bépo a bouleversé mes habitudes.

Tout d’abord, je m’efforce désormais de n’utiliser que les guillemets français lorsque j’écris, y compris sur IRC ; je m’efforce également d’utiliser le « signe moins » (AltGr + « - ») au lieu du trait d’union devant les nombres négatifs ou en parlant d’une soustraction, et j’en passe.

Mais la seule raison qui m’avait retenue de passer au bépo était le fait que l’éditeur de texte Vim, que j’utilise tous les jours et dont je ne peux plus me passer, est conçu pour le QWERTY. De mon côté, j’ai pu résoudre le problème en m’inspirant de cette page et en partant sur une configuration qui échange les rôles des touches C, T, S, R avec H, J, K, L respectivement.  J’estime que repasser entièrement en QWERTY en mode commande est trop bouleversant, et cette solution me sied tout à fait.

Quoi qu’il en soit, je me souviens que du fait de mon travail, je souffrais régulièrement de débuts de tendinite dus à la frappe au clavier et ce malgré le fait que je m’installais correctement à mon poste de travail ; ces maux ont disparu au bout de deux à trois semaines après mon passage intégral au bépo. J’étais peut-être encore loin du syndrome du canal carpien, mais on s’accordera à dire qu’il vaut mieux prévenir que guérir et que dans cet aspect-là, le bépo a ses vertus en matière de santé publique.

Cependant, je sens que j’ai beaucoup régressé en QWERTY : ma vitesse de frappe et mon aisance en QWERTY et en AZERTY ont considérablement baissé. Il me faut parfois cinq à dix minutes pour me réhabituer à la frappe sur ces dispositions de clavier pendant que je combats ma tentation de vouloir taper en bépo (par exemple sur la machine d’un collègue).

Conclusion

Pour moi, l’expérience du passage au bépo a été un franc succès et une décision que je ne regrette pas. Je ressens un confort de frappe nettement amélioré et des mains moins endolories, qui sont des petits plus fort intéressants qui peuvent achever de convaincre autrui à tenter la même expérience que moi.

Le samedi 16 avril 2016, la RATP a officiellement fait ses adieux au plus ancien matériel roulant du RER A après près de cinquante ans de bons et loyaux services : il s’agit du MS 61, un matériel roulant qui avait plus une carrure de « super-métro » que d’une rame de RER comme on en voit de nos jours.

Le dernier MS 61 à Boissy Saint-Léger

C’est ainsi que ce jour-là, la RATP a décidé de faire une dernier service voyageurs avec cette rame : elle était stationnée voie A à la gare de La Défense – Grande Arche et partait à 14 h 47 pour Boissy Saint-Léger, pour ensuite faire le voyage retour jusqu’à Saint-Germain-en-Laye.

J’ai moi-même répondu présent, et j’ai profité du voyage de La Défense jusqu’à Boissy puis de retour jusqu’à La Défense. J'ai notamment eu l'occasion de prendre des photos détaillées du poste de conduite.

Je vous laisse donc admirer les photos que j’ai prises durant cette journée dans ma galerie photo, dans l’album intitulé « Le dernier MS 61 ».

Je poursuis donc avec un autre billet à propos de la mise en place d'un serveur Minitel, un sujet que j'avais déjà traité en détail dans un billet précédent.

Dans ce billet-là, je n'avais traité que du système d'exploitation Linux et lorsque j'avais tenté l'expérience à nouveau sous FreeBSD, je me suis rendu compte que la mise en place d'un tel serveur était radicalement différente par rapport à Linux et que ces différences justifiaient selon moi un nouveau billet. J’en profiterai également pour ajouter quelques informations sommaires à propos de la gestion des ports série.

La principale différence par rapport à Linux est la façon dont le serveur attend des appels entrants au moyen du modem branché dessus : sous Linux, il est en effet nécessaire d'utiliser mgetty(1) du fait des limitations des autres « getty » qu'on peut trouver installés par défaut sous Linux. Le résultat est une série d’immondes bidouilles.

Sous FreeBSD, nul besoin d'installer quoi que ce soit : avec les outils du système de base et une bonne configuration de son modem, on peut obtenir un résultat propre et fonctionnel. En particulier, on obtient un écran de login sans erreurs de parité.

J'ai aussi été contraint de changer mon Olitec Self Memory Pro pour un US Robotics Sportster Flash (pour une poignée d'euros sur Leboncoin) car mon Olitec ne parvenait pas toujours à terminer le handshake lorsque je l'appelais. J'ai eu d'excellents résultats avec ce modem US Robotics. La gamme Courier de chez US Robotics était à une époque utilisée par les fournisseurs d'accès à Internet, mais un modem de cette gamme coûte aux alentours de 200 € sur eBay.

Les signaux importants d'un port série

L'écrasante majorité des modems externes communiquent avec leur hôte à l'aide d'une liaison série RS-232 (que ce soit encapsulé par USB ou non). L'interface RS-232 PC, comme on le sait, utilise des connecteurs DB-9 (9 broches). Ce qui paraît un peu moins évident, en revanche, c’est qu’un modem nécessite une signalisation assez spécifique pour fonctionner correctement dans notre configuration.

En terminologie RS-232, les périphériques peuvent assumer l'un des deux rôles suivants : le Data Terminal Equipment ou DTE d'une part et le Data Circuit-terminating Equipment ou DCE d'autre part. En règle générale, on relie toujours un DTE à un DCE (ou l'inverse) à l'aide d'un câble série.

Généralement, les modems sont des DCE et les équipements qui y sont connectés (comme un PC) sont donc des DTE.

Le brochage d'un connecteur DB-9 n'est pas non plus le même selon le rôle (DTE ou DCE) du périphérique.  La figure ci-dessous illustre le brochage DB-9 côté DTE.

Parmi ces signaux, les plus importants pour nous sont :

• TD (resp. RD) pour la transmission (resp. réception) de données proprement dite ;
• DCD (« détection de porteuse de données »), qui est mis au niveau haut lorsque le modem a reçu un appel entrant, a terminé le handshake avec le modem distant et a établi une connexion ; concrètement, cela correspond au moment où la lettre C en haut à droite de l'écran du Minitel devient fixe. Le signal DCD repasse au niveau bas lorsque l'un des modems raccroche ;
• DTR (« terminal de données prêt ») est mis au niveau haut par le DTE pour signaler au DCE qu'il est prêt. En cours d'une communication, si ce signal passe au niveau bas, alors le modem raccroche.

Ces signaux sont utilisés de la manière suivante dans notre configuration :

1. Le serveur FreeBSD ouvre le port série et passe DTR au niveau haut ;
2. Un utilisateur compose le numéro du modem, qui décroche et débute le handshake (dont le début correspond au son strident au bout de la ligne). L'utilisateur appuie sur Connexion/Fin sur le Minitel pour poursuivre le handshake.
3. Une fois le handshake terminé (i.e. la connexion établie), le modem met DCD au niveau haut.
4. Le serveur FreeBSD réagit à la montée de DCD et affiche l'invite de login UNIX, ou tout autre programme éventuellement configuré.

S'y ajoutent éventuellement les signaux DSR, RTS et CTS servant au contrôle de flux matériel.

Contrairement à ce qu'on pourrait croire, le signal RI (« indication de sonnerie ») ne nous intéresse pas. Dans notre configuration, le modem décroche automatiquement à la réception d'un appel, établit la connexion puis signale à l'aide de DCD le moment où le serveur doit démarrer getty(1) sur la ligne.

On peut désormais rentrer dans le vif du sujet. Il est en effet nécessaire de configurer à la fois le modem et le serveur FreeBSD.

Configuration du modem

La plupart des modems comprennent un jeu de commandes dit « jeu de commandes Hayes » (de l'entreprise qui l'a introduit pour la première fois). Ces commandes permettent notamment de configurer un modem pour être autonome et si placer dans un mode « réponse automatique ».

Tout d'abord, sur la machine FreeBSD, ouvrir le port série en 1 200 bauds, parité paire (cuaU0 dénotant un port série USB) :

# cu -e -s 1200 -l /dev/cuaU0

Une fois la connexion établie, saisir les deux commandes :

AT&F1E0M0Q1&N2 S0=1 S7=30 S13=1 S27=16
AT&W0

Taper ensuite ~. pour se déconnecter. Le modem est alors configuré.

La première commande, qui peut paraître absconse au premier abord, se décompose de la manière suivante :

AT
  &F1         Charger configuration usine (préréglage 1)
  E0          Désactiver l'écho local des commandes
  M0          Désactiver le haut-parleur
  Q1          Désactiver les messages d'état
  &N2         Vitesse 1 200 baud
  S0=1        Décrocher automatiquement à la 1ère sonnerie
  S7=30       Abandonner le handshake après 30 s
  S13=1       Réinitialiser le modem à la chute du signal DTR
  S27=16      Activer le mode « fallback » V.23

AT
  &W0         Sauvegarder la configuration dans le registre 0

À noter que ces deux commandes sont spécifiques à ce modèle particulier de modem et qu'il faudra impérativement consulter la documentation de votre modem pour constituer une commande qui fasse la même chose que celle montrée ci-dessus.

Le mode « fallback » V.23, qui est spécifique au modem que j'utilise, semble nécessaire pour que celui-ci fonctionne avec un Minitel en face. Tous les autres paramètres sont nécessaires pour des raisons de confort (par exemple parce que je n'ai pas envie d'entendre les bruits du handshake) ou exigés par FreeBSD (par exemple la réinitialisation à la chute de DTR). Enfin, on sauvegarde ces paramètres pour qu'ils soient chargés à l'allumage du modem et à chaque réinitialisation.

Configuration de FreeBSD

Avant de poursuivre, il faut noter que FreeBSD gère les ports série un peu différemment par rapport à Linux. FreeBSD crée deux fichiers de périphérique par port série : un périphérique « /dev/cuaX » et un périphérique « /dev/ttyX ». Le périphérique « tty » bloque tant que le signal DTR est au niveau bas ; en revanche, le périphérique « cua » ne tient pas compte de ce signal. Autrement dit : on ouvre un périphérique « tty » lorsque nous attendons une connexion d'un modem externe et le périphérique « cua » lorsque nous sommes nous-mêmes à l'origine d'une connexion.

En outre, et comme je l’avais déjà dit précédemment, contrairement à Linux où il fallait compiler une version patchée de mgetty pour espérer un fonctionnement à peu près correct, ici il n'y a besoin que de quelques ajouts dans deux fichiers de configuration.

Pour commencer, le getty(1) de FreeBSD intègre sa propre base de données « à la termcap », ce qui permet d'expliquer à getty qu'un Minitel est une drôle de bestiole nécessitant 1 200 bauds, 7 bits de données, parité paire, 1 bit d'arrêt, derrière un modem. C'est dans le fichier /etc/gettydefs (cf. gettydefs(5)) que ça se passe et il suffit d'ajouter la section suivante :

#
# Entries for Minitel communicating through their built-in modems
#

minitel.dialup|Minitel through dialup:\
        :hw:ec:ep:rw:sp#1200:

Le fichier permet même de définir un « auto-login » ou un programme de login alternatif. Enfin, dans /etc/ttys (cf. ttys(5)), ajouter :

# Minitel (par modem)
ttyU0   "/usr/libexec/getty minitel.dialup"     minitel on      insecure

Bien entendu, substituez dans le premier champ le vrai nom de votre port série. Ce sera ttyu0 pour le premier port série (l'équivalent de ttyS0 sous Linux) ou ttyU0 pour le premier port série USB (l'équivalent de ttyUSB0 sous Linux). Enfin, appliquez les changements en tapant la commande init q en tant que root).

Si tout se passe bien, les LEDs « AA » (réponse automatique), « TR » (terminal prêt) et « CS » (prêt à envoyer) seront allumés. Testez ensuite en suivant les instructions que j'ai déjà détaillés avant et vous aurez normalement une invite de connexion. Testez donc votre login et votre mot de passe !

Conclusion

Je suis agréablement surpris de voir que grâce à FreeBSD, il est encore plus facile de mettre en place le nécessaire pour héberger des serveurs Minitel. Mais outre la possibilité de monter un tel serveur, c'est en réalité une sorte de point d'accès qu'on met en place. Il suffit alors de substituer le programme de son choix à login(1) sur la ligne série concernée.

Bien que ce sujet semble susciter encore un peu d'intérêt parmi les bidouilleurs de tous les âges, je doute cependant qu'un serveur Minitel recevrait aujourd'hui beaucoup d'appels. Mais parfois, ce n'est pas toujours pour l'utilité pratique qu'on bidouille mais simplement pour la pure prouesse technique.

Mise à jour du 4 mars 2016 : ajout d'une capture tcpdump d'un paquet RA de la Livebox.

Mise à jour du 7 mars 2016 : ajout de quelques détails sur les changements de préfixes IPv6.

Cela fait maintenant quelques mois qu'une mise à jour du firmware de la Livebox fournit une vraie connectivité IPv6 à ses clients.

Chez moi, cette bascule a eu lieu le 25 novembre 2015 en pleine nuit. Ce passage à IPv6, qu’on nous avait promis depuis quelque temps, a introduit un certain nombre de changements techniques dans la connectivité à Internet, que je détaillerai également dans ce billet.

Avant de poursuivre, je souhaite souligner que les observations décrites ci-après ont été faites avec la version SG30_sip-fr-5.15.8.1 du firmware.

Des adresses IPv4 enfin fixes !

Tout d'abord, ce nouveau firmware initie une connexion sur le VLAN 832 et non plus sur le VLAN 835. On perd de plus le PPPoE ; du point de vue de la box, elle dialogue directement par Ethernet.

Cela a eu une autre conséquence, et non des moindres : l'adresse IPv4 est désormais fixe. Finies, donc, les déconnexions hebdomadaires qui faisaient changer d'adresse IPv4 et cassaient IRC et les jeux en ligne. Cette adresse IPv4 reste fixe même après plus de cinquante jours d'uptime de la box et un redémarrage de celle-ci.

Et peut-être bientôt aussi les préfixes IPv6

Bien que les adresses IPv4 soient désormais fixes, on ne peut malheureusement pas en dire autant pour les préfixes IPv6. Ce qui est, encore une fois, particulièrement gênant pour les utilisateurs envisageant de mettre en place des serveurs derrière leurs Livebox, à moins d'utiliser un mécanisme de DNS dynamique similaire à ce que j'avais déjà évoqué auparavant.

Cependant, il semblerait que ces changements de préfixes se font de plus en plus rares. Il est donc probable que les préfixes IPv6 seront fixes eux aussi. Seul le temps nous le dira.

Heureusement, lors d'une bascule d'un préfixe à l'autre, l'ancien préfixe reste encore valable pendant quelque temps, contrairement à un changement d'adresse IPv4 qui casse tout.

Quoi qu'il en soit, Orange fournit un préfixe de 56 bits à chaque client (ce qui ouvre normalement la possibilité de le segmenter en 256 réseaux /64), mais mes tests montrent qu'il n'est pas encore possible d'exploiter l'entièreté de cet espace d'adressage.

Par exemple, la capture d'écran ci-dessus montre que je dispose du préfixe 2a01:cb04:d5:9500::/56. Mais en réalité, la Livebox ne routera que le préfixe 2a01:cb04:d5:9500::/64, ce qui ne correspond qu'à 1/256^e de l'espace d'adressage qu'Orange fournit.

De surcroît, bien que mon routeur OpenWRT implémente la délégation de préfixes telle que décrite dans la RFC 3633, cela ne semble pas encore être le cas de la box. C'est bien dommage, car cette fonction est indispensable pour pouvoir profiter de son /56 comme il se doit. J'aurais bien aimé isoler mes machines dans un sous-réseau de préfixe 2a01:cb04:d5:9501::/64 (par exemple) où toutes les connexions entrantes seraient bloquées par défaut, et d'avoir un autre préfixe pour ma DMZ.

En conclusion, pour le moment, ça ne marchera que chez les clients qui ont une architecture réseau à la « madame Michu », c'est-à-dire ceux qui n'ont pas d'autre routeur que leur Livebox.

Dissection

La Livebox semble embarquer son propre petit serveur DHCPv6, car la configuration des clients IPv6 sur le réseau se fait en « stateful » (voir à ce sujet la RFC 3315).

Ci-dessous, un paquet ICMPv6 Router Advertisement tel qu'envoyé par le box.

13:45:29.529976 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58)
payload length: 104) fe80::7e03:d8ff:fec0:4120 > ff02::1:
[icmp6 sum ok] ICMP6, router advertisement, length 104
        hop limit 64, Flags [other stateful], pref high, router
    lifetime 180s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2a01:cb04:5b3:8700::/64,
      Flags [onlink, auto], valid time 900s, pref. time 300s
            0x0000:  40c0 0000 0384 0000 012c 0000 0000 2a01
            0x0010:  cb04 05b3 8700 0000 0000 0000 0000
          rdnss option (25), length 24 (3):  lifetime 60s, addr: fe80::7e03:d8ff:fec0:4120
            0x0000:  0000 0000 003c fe80 0000 0000 0000 7e03
            0x0010:  d8ff fec0 4120
          dnssl option (31), length 16 (2):  lifetime 60s, domain(s): home.
            0x0000:  0000 0000 003c 0468 6f6d 6500 0000
          mtu option (5), length 8 (1):  1500
            0x0000:  0000 0000 05dc
          source link-address option (1), length 8 (1): 7c:03:d8:c0:41:20
            0x0000:  7c03 d8c0 4120

Conclusion

Il était largement temps que les FAI français passent à l'IPv6, et c'est une excellente nouvelle de voir qu'Orange emboîte le pas lui aussi. Mais certains aspects de la mise en œuvre de ce protocole chez Orange me fait encore froncer un peu les sourcils, et pour les raisons que j'ai citées dans ce billet, je ne suis pas encore en mesure de passer tout mon réseau interne en IPv6. J'attends cependant avec impatience la résolution du problème de la délégation de préfixes.

Je suis conscient que j'aurais également pu utiliser ndppd comme je l'avais fait pour Free, mais je considère que je ne devrais pas avoir à faire ce genre de « hacks » quand on est censé disposer d'un /56.

Enfin, une autre possibilité aurait été de substituer un routeur différent à la box, mais c'est une option que je ne peux envisager car j'utilise beaucoup la ligne téléphonique. Mes efforts consistant à ne plus dépendre de l'interface FXS de la box m'avaient d'ailleurs apporté quelques ennuis.