FPAC 4.2 : routes ROSE dynamiques et sessions White Pages au repos

Spécification, version de travail du 13/10/2026. Projet en cours : le démon fpacrtd est à l'essai sur trois nœuds ; son code n'est pas encore publié. English version

1. But

Aujourd'hui, un nœud FPAC ne connaît que les routes écrites à la main dans fpac.routes. Un DNIC ou un nœud oublié dans ce fichier est injoignable, même si un voisin direct sait l'atteindre.

Le but est que chaque nœud apprenne de ses voisins directs ce qu'ils savent joindre, installe les routes qui lui manquent, et les retire quand elles ne sont plus valables. Le fichier fpac.routes garde le dernier mot.

2. Ce que le mécanisme fait, et ne fait pas

Il fait :

• annoncer aux voisins directs les destinations que le nœud sait joindre, avec un coût en nombre de sauts ;
• installer dans le noyau les routes apprises qui manquent ;
• retirer une route apprise quand le voisin se ferme, cesse de l'annoncer, ou l'annonce comme perdue.

Il ne fait pas :

• remplacer une route écrite dans fpac.routes ;
• réparer un lien qui ne marche que dans un sens ;
• changer la règle du noyau qui préfère un voisin ouvert ;
• annoncer des préfixes intermédiaires (voir 4).

3. Architecture

Un nouveau démon, fpacrtd, lancé par myfpac.sh après les autres démons FPAC et arrêté avant eux, pour que ses routes soient retirées tant que fpad tourne encore.

• Il ouvre un circuit ROSE vers chaque voisin de fpac.nodes marqué Route = yes, à l'indicatif de service FPACRT, et écoute sur ce même indicatif. Le premier appel part 30 secondes après le démarrage, pour laisser aux voisins le temps de lancer leur démon.
• Il lit les routes du noyau (/proc/net/rose_nodes), les voisins (/proc/net/rose_neigh) et fpac.routes.
• Il ajoute et retire ses routes par SIOCADDRT / SIOCDELRT, comme le fait déjà fpacnode.
• Il tient la liste de ses routes dans /var/ax25/fpac/fpacrt.dat, pour les reconnaître et les purger.
• Un seul fpacrtd tourne sur un nœud. Le démon tient un verrou sur /var/ax25/fpac/fpacrtd.lock pendant toute sa vie ; un second le trouve verrouillé, écrit another fpacrtd is already running et sort. Sans cela, le second démon purgeait les routes du premier et tous deux appelaient les mêmes voisins.

Tout script local qui arrête AX.25 ou FPAC sans passer par myfpac.sh doit aussi arrêter fpacrtd, et en premier : le 11/10/2026, une relance d'AX.25 sur un nœud a laissé l'ancien démon en vie à côté du nouveau.

La même protection couvre les quatre autres démons depuis le 12/10/2026 : fpad, fpacwpd, fpacstat et fpacroute tiennent chacun un verrou sur /var/ax25/fpac/<nom>.lock et refusent de démarrer si une autre copie tourne. Ils contrôlent aussi leurs arguments avant toute action : -h ou -? affiche une aide courte, -V la version, et une option inconnue ou un argument isolé est une erreur. Jusque-là fpad et fpacroute ignoraient tout argument et démarraient : fpad -V, tapé sur un nœud en service pour lire sa version, a démarré un second fpad qui a vidé puis recréé les routes ROSE du nœud et écouté sur les mêmes adresses que le premier. Attention, fpacwpd -v reste le mode verbeux et démarre le démon.

Un fichier verrou qui ne peut pas être écrit (disque plein ou en lecture seule) est ouvert en lecture seule, ce qui suffit à tenir le verrou. S'il ne peut pas être ouvert du tout, le démon l'écrit au journal et démarre sans cette protection : un nœud qui ne remonte pas est pire qu'un verrou absent. Un démon compilé avant le verrou n'est pas vu par un nouveau ; la protection vaut une fois les nouveaux programmes en service.

Pourquoi un démon séparé et non fpacwpd : une version actuelle de fpacwpd ferme la session quand elle reçoit un type de message qu'elle ne connaît pas (wp_receive_pdu rend -1). Ajouter un message aux sessions White Pages casserait donc la synchronisation avec tout nœud non mis à jour. Un service séparé laisse les White Pages intactes.

L'indicatif de service est FPACRT, et non ROUTE : fpacroute, l'application de traceroute, écoute déjà sur ROUTE sur tous les nœuds FPAC (constaté au premier essai, le 08/10/2026).

Un nœud sans fpacrtd ne refuse PAS un appel vers FPACRT : son fpad le prend pour un appel d'utilisateur, inscrit l'appelant dans les White Pages et tente une connexion AX.25 vers une station nommée FPACRT. Un voisin n'est donc appelé que si son bloc Node porte Route = yes (voir 10).

4. Ce qui est annoncé

Deux sortes de destinations seulement :

Les préfixes intermédiaires (masques 5 à 9, par exemple 2080 44) ne sont ni annoncés ni appris. C'est avec eux que les boucles sont apparues ; ils restent du ressort de fpac.routes.

Origine d'une annonce :

• adresse de nœud : chaque nœud est l'origine de sa propre adresse et de ses adresses locales, au coût 0. Personne d'autre ne peut en être l'origine.
• DNIC entier : seul un nœud qui porte RouteOrigin = <dnic> dans son fpac.conf en est l'origine, au coût 0. C'est le sysop du nœud qui a le lien réel vers ce pays qui l'écrit.

Tout le reste est du relais : un nœud réannonce une destination apprise au coût reçu plus 1, et rien d'autre. Une route de fpac.routes ne donne jamais lieu à une annonce par elle-même : une ligne fausse ou périmée reste donc sans effet hors du nœud.

Un nœud ne relaie que ce que son propre RouteLearn lui fait retenir : avec RouteLearn = no il ne relaie rien, et avec RouteLearn = nodes il ne relaie aucun DNIC.

Un nœud qui déclare RouteOrigin = 5050 doit avoir lui-même une route vers ce DNIC dans fpac.routes. Sinon, fpacrtd le signale dans le journal et n'annonce pas ce DNIC.

Le DNIC n'est annoncé que tant que son lien de sortie est ouvert, c'est-à-dire tant qu'un voisin de cette route est « ouvert » dans rose_neigh. Quand le lien se ferme le DNIC est retiré (W), puis annoncé de nouveau quand il se rouvre ; l'état est contrôlé chaque minute et chaque changement est écrit au journal. Le lien avec le voisin à qui l'annonce est destinée ne compte pas : un DNIC n'est jamais annoncé à un nœud sur la foi du lien avec ce même nœud.

5. Échanges

Le dialogue est en texte, une ligne par message, pour rester lisible avec listen.

Rythme :

• table complète à l'ouverture du circuit ;
• table complète toutes les 30 minutes ;
• messages R ou W isolés environ 10 secondes après un changement (route apprise ou perdue) ; des changements rapprochés partent ensemble ;
• l'état des voisins (ouvert ou fermé) est contrôlé chaque minute.

6. Règles de réception

Pour chaque route reçue d'un voisin V, de coût c :

1. coût retenu = c + 1 ; au-delà de 6, la route est ignorée ;
2. si la destination est l'une des adresses du nœud : ignorée ;
3. si fpac.routes contient déjà cette adresse avec ce masque : la route n'est pas installée, la route manuelle reste en place ; la destination est quand même relayée aux autres voisins ;
4. si V n'est pas « ouvert » dans rose_neigh : pas installée ;
5. sinon, elle est installée si aucune route apprise n'existe pour cette destination, ou si son coût est strictement meilleur.

Une route que RouteLearn n'admet pas n'est pas retenue du tout : elle n'est ni installée ni relayée (voir 4).

Une seule route apprise par destination : la meilleure. Pas de voisin de secours en version 1.

7. Règles d'émission

• Horizon coupé : une destination n'est jamais annoncée au voisin par lequel le nœud la joint réellement, que ce soit par une route apprise ou par une route manuelle. C'est la protection contre la boucle à deux nœuds.
• Retrait empoisonné : quand une route apprise est perdue, un W part vers les autres voisins environ 10 secondes plus tard.
• Plafond : aucune route de coût supérieur à 6 n'est annoncée.

8. Durée de vie

Une route apprise est retirée du noyau quand :

• le circuit FPACRT avec le voisin se ferme, ou le voisin n'a plus envoyé de table depuis 90 minutes (voir plus bas) ;
• le voisin passe à « fermé » dans rose_neigh (contrôlé chaque minute) ;
• le voisin envoie W, ou envoie 3 tables complètes de suite sans elle (90 minutes au rythme normal) ;
• fpacrtd s'arrête : il retire toutes ses routes.

Au démarrage, fpacrtd retire d'abord les routes restées de sa dernière exécution, d'après fpacrt.dat. Chaque minute, il contrôle aussi que ses routes sont toujours dans le noyau et remet celles qui auraient disparu.

Un voisin qui se tait est traité lui aussi : quand un nœud détient des routes apprises d'un voisin et n'a reçu de lui aucune table complète depuis 90 minutes, il ferme le circuit. Les routes apprises de ce voisin sont retirées, et il est rappelé 30 minutes plus tard. Un voisin qui n'a jamais rien annoncé (RouteAnnounce = no) se tait par construction et n'est pas concerné.

9. Routes manuelles et routes apprises

• Une route de fpac.routes n'est jamais retirée ni modifiée.
• À adresse et masque égaux, la route manuelle gagne.
• Une route apprise plus précise qu'une route manuelle s'applique, comme toute route plus précise : une adresse de nœud apprise passe devant un 2080 = … manuel. C'est voulu (accord F6BVP, 08/10/2026), mais c'est un changement de comportement à connaître.

10. Configuration

Dans fpac.conf et fpac.nodes, quatre réglages, tous inactifs par défaut :

Sans ces lignes, un nœud en 4.2 se comporte comme en 4.1. Un voisin sans Route = yes n'est jamais appelé, et ses appels sont refusés.

Exemple pour f6bvp-8, qui a les liens réels vers l'étranger :

RouteAnnounce = yes
RouteLearn    = all
RouteOrigin   = 2020
RouteOrigin   = 2400
RouteOrigin   = 3020
RouteOrigin   = 3100
RouteOrigin   = 5050

et, dans fpac.nodes, une ligne de plus dans le bloc de chaque voisin qui fait tourner fpacrtd (ici f6bvp-12). Sans elle, rien n'est échangé :

Node = F6BVP-13
 ...
 Route = yes
End

11. Affichage

Prévu, pas encore codé. La commande Routes de fpacnode marquera les routes apprises (dyn), et une commande routes dyn listera les seules routes apprises, avec le voisin qui les annonce.

Aujourd'hui, les routes apprises se lisent dans le journal de fpacrtd (lignes « add route » et « del route ») et dans fpacrt.dat.

12. Compatibilité

• Un nœud en 4.1.x ne doit jamais être appelé sur l'indicatif FPACRT (voir 3) : Route = yes ne s'écrit dans un bloc Node qu'une fois que le sysop de ce voisin fait tourner fpacrtd. Les deux sysops se mettent d'accord d'abord.
• Un voisin marqué Route = yes qui ne répond pas est réessayé toutes les 30 minutes.
• Le noyau n'est pas modifié.
• Les White Pages ne sont pas modifiées.

13. Plan d'essai

1. Paire f6bvp-12 / f6bvp-8 (f6bvp-8 est le nœud le plus connecté) : f6bvp-8 en RouteAnnounce = yes avec ses RouteOrigin, f6bvp-12 en RouteLearn = all. Retirer d'abord de fpac.routes de f6bvp-12 un DNIC lointain, par exemple 5050 : il doit revenir seul. Vérifier aussi le retrait à la fermeture du voisin et la purge au redémarrage.
2. Activer l'annonce dans les deux sens sur la paire, puis ajouter f6bvp-10 en RouteLearn = all : il doit recevoir 5050, qui lui manque aujourd'hui.
3. Essai de boucle provoquée : couper le lien de sortie d'un DNIC et vérifier que la route disparaît partout en moins de 2 minutes, sans trame qui tourne (rose-controle.py).
4. Une semaine d'observation avant d'étendre aux autres nœuds.

État au 12/10/2026 : l'étape 1 est passée le 08/10/2026, y compris le retrait à l'arrêt du démon du voisin et la purge au redémarrage. Depuis le 09/10/2026, trois nœuds participent : f6bvp-8 annonce, f6bvp-12 et f6bvp-10 apprennent, chacun directement de f6bvp-8. Après chacun des quatre redémarrages nocturnes de FPAC, les sessions et les routes apprises sont revenues seules en moins de 50 secondes, et la table de 6 routes est reçue toutes les 30 minutes sans manque. L'annonce dans les deux sens (étape 2) n'est pas encore activée. Pas encore éprouvés en réel : le vieillissement, la règle des 90 minutes, le relais par un troisième nœud et un appel réel par une route apprise.

Les démons munis du verrou d'instance unique (voir 3) sont en service sur sept nœuds depuis le 12/10/2026, compilés à partir des sources de la 4.1.6-rc7 et de ce seul changement. Sur chaque nœud les verrous sont tenus et un second lancement de chaque démon est refusé.

14. Décisions prises et points ouverts

Décidé (F6BVP, 08/10/2026) :

• la porte de sortie d'un DNIC est déclarée par RouteOrigin ; une route manuelle seule ne suffit pas à l'annoncer ;
• une adresse de nœud apprise passe devant une route manuelle plus large ;
• plafond de 6 sauts et période de 30 minutes comme valeurs de départ ;
• premiers essais sur la paire f6bvp-12 / f6bvp-8.

Encore ouvert :

• faut-il un voisin de secours par destination en version 2 ?
• que faire si deux nœuds déclarent RouteOrigin pour le même DNIC : c'est permis (deux sorties réelles), chacun choisit la plus proche. À confirmer à l'usage.

Décidé (F6BVP, 13/10/2026) :

• un DNIC déclaré par RouteOrigin n'est annoncé que tant que son lien de sortie est ouvert, et retiré quand ce lien se ferme. Raison : le noyau ne fait sortir un appel en transit que par un voisin ouvert (un voisin fermé n'est essayé que pour un appel local), donc un DNIC annoncé sur une sortie fermée ne mène nulle part. La règle du noyau n'est pas changée. Codé le 13/10/2026 (voir 4) et à l'essai depuis sur le nœud qui annonce, dont la table est passée de 6 routes à 2 : quatre de ses cinq DNIC avaient une sortie fermée.

15. Numérotation

Cette nouveauté ajoute un démon, un protocole entre nœuds et des mots-clés de configuration : elle justifie FPAC 4.2. Ordre proposé :

1. sortir la 4.1.6 stable avec les correctifs de la rc7 ;
2. ouvrir la 4.2-rc1 avec fpacrtd et WpIdle (voir 16), tous deux inactifs par défaut, le changement des vecteurs (voir 17) et la commande QSl (voir 18).

Le code à l'essai est public : branche fpac-4.2 de https://github.com/f6bvp/fpac. Il est expérimental, ce n'est pas une version publiée.

16. Second chantier : sessions White Pages fermées au repos

Décidé par F6BVP le 08/10/2026. Rien n'est encore codé.

Aujourd'hui, fpacwpd garde ouvert en permanence un circuit ROSE avec chaque voisin (de WP-0 à WP-0), alors qu'il ne transporte qu'une fiche de temps en temps et un échange de vecteurs par heure.

Nouveau mot-clé dans fpac.conf :

Sans ce mot-clé, ou avec 0, rien ne change : la session reste ouverte comme en 4.1. Valeur recommandée : WpIdle = 10.

Comportement avec WpIdle = 10 :

• une session avec un voisin est fermée après 10 minutes sans aucune fiche ni vecteur échangé ;
• elle n'est rouverte qu'à la demande : quand une fiche doit être poussée vers ce voisin (modification locale ou relais), ou quand l'échange horaire de vecteurs est dû ;
• une session ouverte par le voisin est toujours acceptée ;
• le nouvel essai aveugle toutes les 30 minutes ne subsiste qu'après un échec de connexion, pas après une fermeture au repos.

Ce que le code demande :

• la liste des fiches en attente pour un voisin doit appartenir au voisin et non plus à la session, pour survivre à une fermeture ;
• le voisin doit être reconnu comme serveur WP (correctif de la 4.1.6-rc7) ;
• aujourd'hui, une session qui s'ouvre lance un échange de vecteurs complet ; en rouvrir une pour pousser une seule fiche ne doit pas le lancer à chaque fois.

Avec un voisin resté en 4.1, qui rouvre sa session toutes les 30 minutes et la garde, le circuit est refermé 10 minutes plus tard. C'est sans gravité, mais cela se voit dans les journaux.

Le noyau sait fermer seul un circuit ROSE au repos (option de socket ROSE_IDLE). Une fermeture décidée par fpacwpd est préférée, parce qu'il sait si un échange est en cours ; à trancher au moment du code.

Essai : sur une paire, vérifier qu'une session au repos se ferme, qu'une fiche modifiée par wpedit la rouvre et arrive chez le voisin, et que l'échange horaire de vecteurs a toujours lieu.

17. Troisième chantier : fiches supprimées obsolètes sorties des vecteurs

Constaté le 11/10/2026. Deux nœuds écrivaient Vectors still differ chaque heure alors qu'ils avaient la même version.

Une fiche supprimée de plus de 14 jours (WP_OBSOLETE) n'est ni envoyée ni acceptée entre nœuds, et une fiche supprimée d'un indicatif inconnu est refusée. Ces fiches comptent pourtant dans les vecteurs, dont la somme de contrôle couvre la date et l'adresse de chaque fiche. Quand deux nœuds marquent une fiche supprimée, ou l'effacent, à des jours différents, leurs vecteurs diffèrent et l'échange ne peut pas le réparer : les fiches qui régleraient l'écart sont justement celles qui ne s'échangent pas. Cela dure jusqu'à ce que les deux nœuds les aient effacées.

Ici, un nœud lançait chaque nuit wpmaint -d 100 quand les autres lançaient wpmaint -d 30 : il gardait 12 fiches supprimées que les autres avaient effacées, et deux fiches encore valides, supprimées ailleurs.

Décidé (F6BVP, 11/10/2026) : sortir de la somme de contrôle des vecteurs les fiches supprimées trop anciennes pour être échangées. Codé le 13/10/2026, pas encore en service.

Un nœud modifié et un nœud non modifié calculent des vecteurs différents et divergeraient sans fin. Décidé (F6BVP, 13/10/2026) : le numéro de version des vecteurs change avec la nouvelle somme de contrôle ; c'est son rôle.

fpacwpd jusqu'à la 4.1.6 ferme la session White Pages quand il reçoit un vecteur d'une autre version, et rappelle 30 minutes plus tard. Sans rien de plus, un nœud 4.2 et un nœud 4.1.6 ne garderaient plus de session. Décidé (F6BVP, 13/10/2026) : la 4.2 continue de parler l'ancienne version, avec l'ancienne somme de contrôle, à un voisin resté plus ancien ; la nouvelle version ne sert qu'entre nœuds 4.2. Un réseau peut ainsi être mis à jour nœud par nœud.

Tel que codé le 13/10/2026 : la nouvelle version des vecteurs est 0x112, l'ancienne 0x111. Un nœud répond à une demande de vecteur dans la version où elle est arrivée. Pour ses propres demandes, il prend d'abord chaque voisin pour un nœud 4.2 ; si le voisin raccroche avant de répondre, il lui parle ensuite dans l'ancienne version, avec une ligne au journal. Un vecteur en nouvelle version reçu de ce voisin prouve qu'il a été mis à jour. Comme une session peut aussi tomber pour une autre raison à ce moment précis, la nouvelle version est réessayée une fois par semaine. Le prix avec un voisin 4.1 : une session fermée au premier échange, puis une fois par semaine ; elle se rouvre dans les 30 minutes.

Non couvert : une fiche supprimée récemment, que l'autre nœud n'a jamais connue, y est refusée et compte encore dans les vecteurs, jusqu'à ce qu'elle devienne obsolète à son tour.

D'ici là : régler les mêmes délais de wpmaint sur tous les nœuds d'un réseau. L'écart est sans gravité - trois tours de vecteurs par heure au plus depuis la 4.1.6-rc7 - mais il remplit le journal.

18. Quatrième chantier : la commande QSl du nœud

Demandée le 13/10/2026 : une carte QSL qui confirme une connexion au nœud, à la manière de la carte envoyée après un contact radio.

Un utilisateur tape QSl (QS suffit). Le nœud affiche la carte en texte dans la session : le titre « FPAC node confirming connection with », l'indicatif de l'utilisateur, la date et l'heure en UTC, l'heure de début de la session, puis ce que montre la commande Status jusqu'à la version de FPAC.

Une session ne transporte que du texte : l'image de la carte ne peut pas y passer. Décidé (F6BVP, 13/10/2026) : le nœud fabrique l'image et donne un lien pour la télécharger avec un navigateur ; pas de courriel. L'image est un seul fichier JPEG, l'image du nœud au-dessus (recto) et le texte en dessous (verso).

Il faut pour cela un serveur web sur le nœud ; c'est donc facultatif :

Ils s'écrivent dans fpac.conf, ou dans un fichier fpacqsl.conf placé à côté. Sans QslDir et QslUrl, le nœud ne donne que la carte en texte. L'image du recto est par défaut le fichier QSL_fpac.jpg déposé par le sysop à côté de fpac.conf ; sans lui la carte n'a que sa face de texte.

L'image est dessinée par un programme à part, fpacqsl, écrit en Python : le nœud lui-même ne gagne aucune dépendance. Il lui faut le paquet python3-pil.

Limites : les cartes de plus de QslKeep jours sont effacées ; un utilisateur qui redemande dans les 10 minutes reçoit la carte déjà fabriquée ; aucune image n'est fabriquée tant que le dossier contient 500 cartes. Chaque demande est inscrite dans fpac/qsl.log.

État au 13/10/2026 : codé, et à l'essai sur un nœud, qui sert les cartes sous http://f6bvp.org/qsl/. Le mode d'emploi est le fichier doc/qsl.txt des sources.