Introduction

Depuis le 1er août 2026, le réseau MeshCore belge change la façon dont il traite les messages flood qui n’ont pas de scope de région (les messages dits « unscoped »). L’objectif annoncé par les gestionnaires du réseau, réunis autour de la communauté Radio-Actief, est simple : limiter le trafic « unscoped » (sans identification géographique) qui arrive massivement de nos voisins, en particulier du Royaume-Uni, et qui sature une partie du réseau belge sans apporter d’information utile aux utilisateurs.

Toutes les recommandations techniques de ce changement sont détaillées sur cette page meshcore-repeater-flood-instellingen, et un outil de configuration rapide des relais est disponible sur meshmap.radio-actief.be/configurator.

Sur le papier, l’idée est bonne. Sur le terrain, à la mi-août 2026, le résultat me semble plus mitigé : une bonne partie des relais belges tourne encore en firmware 1.15, peu d’admins ont configuré une table de régions complète, et certaines recommandations appliquées de façon isolée créent, à mon avis, plus de dégâts collatéraux qu’elles n’apportent de bénéfice pour l’instant. Voici ce que j’observe et une piste de séquencement qui me semblerait plus progressive sans prétendre détenir la solution définitive.

Problématique : des bonnes commandes, au mauvais moment

Ce que propose Radio-Actief

La page de leur site propose un ensemble de recommandations plus large que ce qui suit. Pour comprendre où se situe le blocage sur le terrain, je me concentre ici sur les commandes qui, combinées entre elles, posent problème :

set path.hash.mode 1
region put eu
region put bx eu
region put be bx
region home be
region save
set flood.max.unscoped 5
region denyf *

Le configurateur en ligne, lui, va un peu plus loin et ajoute automatiquement :

region default be

Chacune de ces commandes fait quelque chose de précis :

• set path.hash.mode 1 — Active l’encodage 2 bytes pour l’identifiant que le relais utilise dans ses propres adverts. Cette commande ne bloque et ne filtre rien : elle ne joue aucun rôle dans la réduction du trafic étranger. Elle améliore juste la fiabilité d’adressage sur un réseau qui grossit (256 identifiants possibles en 1-byte contre 65 536 en 2-byte).
• region put / region def — Construisent la table de régions du relais : quelles zones géographiques (eu, bx, be…) il reconnaît et accepte de relayer.
• region home — Actuellement, la home region est essentiellement une information de contexte. La documentation MeshCore précise qu’elle est réservée pour des utilisations futures et qu’une région définie comme home n’a pas encore d’effet sur le routage des paquets.
• region save — Sauvegarde cette table de régions, pour qu’elle survive à un redémarrage du relais.
• flood.max.unscoped 5 — limite à 5 le nombre de sauts autorisés pour les messages qui n’ont aucun scope de région.
• region denyf * — Bloque purement et simplement tout message sans scope, sans limite de sauts : c’est un couperet total. C’est cette commande précise qui, à mon avis, mériterait d’être remplacée par une approche différente (j’y reviens plus bas).
• region default be — Scope automatiquement tous les messages que ce relais lui-même envoie (ses propres adverts) avec la région « be ».

Comment ces commandes se marchent sur les pieds entre elles

Le firmware applique une règle simple mais impitoyable : un relais ne relaie pas un message qui porte un scope de région s’il n’a pas cette région dans sa propre table. Un relais sans configuration de région (aucune table de région définie. Exemple : juste après avoir flashé le firmware sur un relais vierge) ne matche donc pas grand-chose, et jette tous les messages scopés qui lui arrivent.

Sur le terrain aujourd’hui, ça donne quatre situations qui se télescopent :

• Les messages sans scope sont limités en portée (flood.max.unscoped) ou carrément arrêtés (region denyf *) par les relais qui ont suivi la page flood-instellingen à la lettre.
• Les messages avec un scope se font arrêter net par les relais qui n’ont pas (ou peu) configuré de table de régions. Il me semble, sans avoir fait de relevé exhaustif, qu’ils sont actuellement majoritaires.
• Les relais qui ont suivi le configurateur de Radio-Actief envoient leurs propres adverts scopés (region default be) « be »… qui meurent au premier relais rencontré qui n’a pas de table de région configurée, ce qui arrive souvent dans l’état actuel du réseau. Ceci a par exemple pour conséquence, une disparition du relais de la carte officielle map.meshcore.io puisque l’advert est « tué » avant d’avoir pu rejoindre un observer.
• Les relais restés en configuration par défaut (region default <null>) envoient des adverts non scopés, qui eux se font limiter ou bloquer par les relais ayant appliqué un flood.max.unscoped sévère ou carrément un region denyf *.

Résultat : Selon la combinaison de réglages rencontrée en cours de route, un message peut se faire bloquer dans les deux cas. Le réseau belge perd, me semble-t-il, en portée effective par rapport à la situation d’avant le 1er août, pour une partie des utilisateurs. Et la présence de region denyf * chez certains gestionnaires aggrave particulièrement le problème : contrairement à une limite de sauts, elle ne laisse littéralement aucune chance à un message non scopé, y compris celui d’un nouvel utilisateur qui n’a encore rien configuré sur son compagnon.

Pourquoi un déploiement en une seule phase pose question

Le problème de fond n’est pas dans les commandes elles-mêmes, mais dans l’ordre et le rythme d’adoption. Faire cohabiter, au même instant sur le même réseau :

• une minorité de relais avec table de régions + scope activé,
• une majorité de relais sans configuration de région, ou avec une configuration réduite,
• et des restrictions actives sur le trafic non scopé,

… ça crée trois populations de nœuds qui ne se comprennent plus vraiment entre elles. C’est un schéma assez classique des migrations de protocole en réseau décentralisé : une adoption partielle est souvent plus pénalisante que pas d’adoption du tout, tant qu’un seuil critique n’est pas atteint. La page de radio-actief reconnaît elle-même que cette partie est encore un « work in progress ». Mais sans séquence de déploiement ni seuil d’adoption clairement définis, la phase de transition risque de s’éterniser.

Proposition d’un déploiement en deux temps

Phase 1 : Construire la table de régions, sans rien casser

L’idée de cette première phase serait d’équiper les relais pour qu’ils sachent relayer du trafic scopé « be », sans encore rien changer à leur propre comportement d’émission ni au trafic non scopé.

region put eu
region put bx eu
region put be bx
region home be
region save
set path.hash.mode 1

Ce qu’on laisse en l’état :

region default <null>   (ne rien configurer, laisser tel quel)
region allowf *         (le trafic non scopé reste autorisé, comportement par défaut)
flood.max.unscoped 64   (valeur par défaut, pas de restriction)

Plutôt que region denyf *, qui coupe tout net, je préconiserais de garder region allowf * : le trafic non scopé continue à être autorisé, sans restriction de sauts particulière à ce stade.

Ce que ça permet concrètement :

• Le relais devient capable de relayer correctement le trafic scopé « be », « bx », « eu » : on construit progressivement l’épine dorsale du réseau.
• Les adverts du relais restent non scopés, donc ils continuent à traverser sans problème les relais qui n’ont pas encore de tables de régions configurées. Pas de perte de couverture pendant la transition.
• Le trafic non scopé (les newbies, les companions non configurés) continue à circuler normalement, sans restriction supplémentaire.
• Côté companion, je ne changerais rien pour l’utilisateur moyen : on reste en configuration par défaut (non scopé), avec éventuellement quelques tests volontaires pour les plus curieux qui veulent essayer le « Default Region Scope » dans les réglages expérimentaux.
• Le passage en 2-byte (path.hash.mode 1) peut se faire dès cette phase : c’est une bonne pratique de fiabilité, indépendante du reste, qui ne présente pas de risque particulier (à condition que les voisins directs soient en firmware 1.14 ou plus récent).

Quel seuil viser avant de passer à la phase 2 ?

Plutôt que de deviner, la carte officielle du réseau belge propose une page de statistiques à l’adresse meshmap.radio-actief.be/stats, qui suit l’évolution du nombre de relais actifs dans le temps. Ce serait l’endroit idéal pour fixer un seuil concret avant de déclencher la phase 2. Les statistiques de cette page devraient mesurer d’une manière ou d’une autre, l’adoption d’une table de régions par les relais. Une fois qu’une majorité franche de ceux-ci aurait confirmé disposer d’une table de régions valide, on pourrait basculer en phase 2. Mais tant que ce seuil n’est pas atteint, scoper les adverts ou durcir le trafic non scopé me semble prématuré, pour les raisons expliquées plus haut.

Comment vérifier sa propre configuration

Avant de passer à l’étape suivante, un petit contrôle s’impose. Toujours via l’écran « Command Line » du relais :

region
get path.hash.mode
get flood.max.unscoped
get flood.max
region home

• region — Liste toutes les régions actuellement définies sur ton relais et leur statut d’autorisation (allow/deny). C’est la commande la plus utile pour vérifier que ta table est bien construite avant de passer à la phase 2.
• get path.hash.mode — Confirme que tu es bien passé en 2-byte (la réponse doit être « 1 »).
• get flood.max.unscoped — Affiche la limite de sauts actuellement appliquée au trafic non scopé.
• get flood.max — Affiche la limite globale de sauts pour tout le trafic flood, scopé ou non.
• region home — Confirme la région « domicile » configurée pour ton relais.

Phase 2 : Une fois un seuil d’adoption suffisant atteint

Cette deuxième phase ne démarrerait que lorsqu’une masse critique de relais belges disposerait déjà de la table de régions construite en phase 1. À ce moment, on pourrait activer :

set region default be
region allowf *
set flood.max.unscoped 3

On garde region allowf * (on ne bascule pas vers region denyf *) mais on vient cette fois limiter fermement le nombre de sauts des messages sans scope avec flood.max.unscoped. Une valeur assez sévère, entre 3 et 5, me semble suffisante pour assainir le réseau, tout en laissant une vraie chance aux nouveaux utilisateurs.

C’est seulement à ce stade qu’on communiquerait la recommandation suivante aux utilisateurs de companion :

(dans les réglages expérimentaux du companion)
Default Region Scope = be

Ce que ça change :

• region default be devient enfin utile : les adverts du relais sont désormais scopés « be », et comme la majorité des relais voisins savent déjà relayer ce scope (grâce à la phase 1), ces adverts ont une vraie chance d’atteindre le reste du réseau au lieu de mourir au premier saut.
• flood.max.unscoped entre 3 et 5 limite le trafic non scopé sans jamais le couper totalement. Un newbie qui n’a rien configuré sur son companion garde une portée locale utile pour ses premiers messages, alors que le trafic parasite venant de loin (typiquement le trafic UK, qui a déjà consommé plusieurs sauts avant même d’arriver chez nous) se fait éliminer plus facilement par cette même limite. C’est un compromis, pas un mur.
• Recommander le scope « be » sur les companions seulement à ce moment-là évite de pénaliser les premiers utilisateurs qui l’auraient activé trop tôt : leurs messages auraient subi le même problème que les adverts scopés des relais pionniers, mais côté messagerie personnelle. C’est plus gênant pour l’expérience utilisateur qu’un simple souci de portée d’advert.

Envie d’en discuter ?

Si vous gérez un relais du réseau #BEmesh, ma suggestion serait de commencer par construire la table de régions (phase 1), sans toucher à region default ni durcir flood.max.unscoped pour l’instant, et en gardant region allowf * plutôt que region denyf *. La communauté Radio-Actief se coordonne sur ses médias repris en bas de la page d’accueil de son portail officiel. Il donne accès au forum et au serveur Discord où se discutent ces réglages au jour le jour. N’hésitez pas à partager votre avis là-bas, et à comparer nos configurations respectives une fois qu’un nombre suffisant de relais aura fait cette même démarche.

Un exemple de configuration pour Bruxelles

Valeurs non défaut :
set radio 869.618,62.5,8,8
set flood.advert.interval 47
set advert.interval 0
set path.hash.mode 1
set dutycycle 10
set loop.detect minimal

Valeurs par défaut usine :
set repeat on
set txdelay 0.5
set direct.txdelay 0.2
set flood.max.unscoped 64
set flood.max 64
set flood.max.advert 8
set radio.rxgain on
set int.thresh 0
set agc.reset.interval 0
set multi.acks 0
gps advert prefs

Régions :
region put eu
region put bx eu
region put be bx
region put be-bru be
region put be-vbr be
region put be-wbr be
region put nl bx
region put lu bx
region put fr eu
region put de eu
region put uk eu

Ou en une seule ligne :
region def eu bx nl|bx lu|bx be be-bru|be be-vbr|be be-wbr|eu fr|eu de|eu uk

region allowf *
region default <null>
region home be-bru
region save

reboot

clock sync