Diagnostic et réparation du portail captif — pour le moteur de l’application

Note destinée au système de détection d’erreurs de configuration et de réparation automatique de l’application mobile. Chaque panne est décrite par : le symptôme côté client, la commande de détection, la règle de décision, la réparation, et son risque.

⚠️ L’application pose ces commandes depuis le LAN. Le backend, lui, ne peut pas : plusieurs de ces chemins sont dans routerWriteGuard et refusés côté serveur. C’est le même partage que pour l’Anti-Restriction.

Ordre de contrôle

Du plus fréquent et du moins cher au plus rare. Arrêtez-vous à la première panne trouvée : elles se masquent entre elles, et réparer la seconde sans la première ne rend rien au client.

1. Le serveur hotspot tourne-t-il ?
2. Les clients peuvent-ils résoudre un nom ?        ← la panne la plus fréquente
3. Une règle passe-t-elle devant le saut hotspot ?
4. Le dossier HTML du portail est-il complet ?
5. Le walled-garden laisse-t-il passer le paiement ?

1. Le serveur hotspot tourne-t-il ?

Symptôme : rien du tout, pas même une redirection.

:put [:len [/ip hotspot find where !disabled and !invalid]]

Ne tentez jamais de recréer un serveur hotspot depuis l’application : il dépend du pool d’adresses, du bridge et du profil. Une recréation à l’aveugle produit un hotspot qui répond mais n’authentifie personne — pire que pas de hotspot.

2. Les clients peuvent-ils résoudre un nom ? — LA PANNE LA PLUS FRÉQUENTE

Symptôme exact : les appareils déjà connus entrent normalement (mac-cookie), mais tout nouveau client reste devant un écran vide. Le portail « ne s’affiche pas ».

Pourquoi : le hotspot redirige les requêtes DNS des clients non authentifiés vers le routeur. Si le DHCP désigne le routeur comme seul serveur DNS et que le routeur refuse de répondre, aucun nom n’est résolu — donc aucune requête HTTP ne part, donc aucune redirection vers le portail.

Détection

:put [/ip dns get allow-remote-requests]
/ip dhcp-server network print
/ip address print where !dynamic

Règle de décision

repond        = (allow-remote-requests = true)
dns_distribue = liste dns-server du réseau DHCP du hotspot
adresses_du_routeur = adresses statiques du routeur

seul_lui_meme = dns_distribue ⊆ adresses_du_routeur

Un DNS distribué qui n’est ni le routeur ni joignable depuis le réseau du hotspot (exemple relevé : 192.168.1.1 distribué sur un LAN en 192.168.254.0/24) est 🟠 dégradé : le client bascule sur le suivant après un délai. À signaler, pas à réparer d’urgence.

Réparation

/ip dhcp-server network set [find] dns-server=1.1.1.1,8.8.8.8

Puis renouveler le bail des clients, ou attendre son expiration.

[!WARNING] Ne posez PAS allow-remote-requests=yes. C’est la réparation qui vient à l’esprit, et c’est un piège : sur les routeurs sans règle de rejet par défaut en chaîne input — c’était le cas des deux routeurs cassés trouvés le 2026-08-29 — cela ouvre le résolveur DNS depuis Internet et fabrique un amplificateur d’attaque. Corriger le pare-feu ensuite demanderait de toucher /ip firewall filter, chemin sensible.

Distribuer des DNS publics résout la panne sans rien ouvrir. C’est ce que font déjà 14 routeurs sains du parc.

Le proxy DNS du hotspot continue d’intercepter les clients non authentifiés : il n’a pas besoin du résolveur du routeur.

3. Une règle passe-t-elle devant le saut hotspot ?

Symptôme : le portail affiche WebFig (l’interface du routeur) au lieu de la page de connexion, ou ne répond pas sur le port 80.

Pourquoi : dans chain=dstnat, l’ordre décide. Une règle de redirection placée avant action=jump jump-target=hotspot et qui accepte in-interface-list=all capture le trafic des clients avant que le hotspot ne le voie. Incident vérifié le 2026-08-24.

Détection

/ip firewall nat print where chain=dstnat

Repérez la position du jump-target=hotspot. Toute règle avant lui qui ne restreint pas son in-interface à une interface de gestion est suspecte.

La forme CORRECTE, déjà déployée sur le parc

chain=pre-hotspot action=redirect to-ports=8081 protocol=tcp in-interface=HOTSPOT dst-port=8080
chain=pre-hotspot action=redirect to-ports=8081 protocol=tcp in-interface=HOTSPOT dst-port=8081
chain=dstnat     action=redirect to-ports=8081 protocol=tcp in-interface-list=JS-MGMT dst-port=8080

Deux choses la rendent sûre : la chaîne pre-hotspot (que le hotspot traverse lui-même, sans court-circuiter sa redirection), et un in-interface nommé au lieu de all.

Réparation

Remettre les règles de gestion dans cette forme. N’inventez pas de règle : reprenez celle ci-dessus en substituant le nom réel du bridge hotspot.

⚠️ Une correction manuelle sur ce point était réécrite en 6 minutes par l’ancienne synchronisation. Vérifiez 10 minutes après, et si la règle fautive est revenue, remontez-le au support au lieu de la reposer en boucle — c’est un écrivain concurrent, pas une erreur ponctuelle.

4. Le dossier HTML du portail est-il complet ?

Symptôme : redirection correcte mais page blanche, ou erreur 404 du hotspot.

Détection

/ip hotspot profile print detail    → lire html-directory
/file print where name~"<html-directory>"

Le dossier doit contenir au minimum : login.html, alogin.html, error.html, logout.html, md5.js, status.html.

Le suffixe (2) est le signe d’un téléversement répété. Relevé en production : un profil pointant sur hotspot-pro (2) — complet dans ce cas, mais la forme mérite une alerte.

Réparation

Ne réparez pas automatiquement. Retéléverser un portail depuis l’application demande les bons fichiers pour ce gérant : proposez-lui le renvoi du portail plutôt que de choisir à sa place.

5. Le walled-garden laisse-t-il passer le paiement ?

Symptôme : le portail s’affiche, mais la page de paiement reste blanche — le client voit le formulaire et ne peut pas payer.

Détection

/ip firewall nat print where chain=hs-unauth

Doivent figurer, en action=return : les adresses de *.fedapay.com (cdn, checkout, api, live, process), celles de *.jmoai.net, et l’adresse du portail local.

Réparation

C’est le rôle du docteur walled-garden côté backend (cron, toutes les 30 min). L’application ne doit pas poser ces règles elle-même : deux écrivains sur la même liste produisent des doublons et des retraits croisés. Signalez, laissez le backend faire.

6. Ce que l’application doit remonter

Pour chaque contrôle, remontez au support : le contrôle exécuté, le verdict, et si une réparation a été posée, laquelle. Sans ça, personne ne saura plus tard si une configuration a été corrigée par l’application ou modifiée à la main — et c’est exactement ce qui rend les diagnostics suivants impossibles.

7. Les trois règles à ne pas enfreindre

1. Une seule panne à la fois. Réparez, vérifiez, puis recontrôlez depuis le début. Les pannes se masquent : un DNS mort cache un mauvais ordre de NAT.
2. Ne réparez jamais ce que vous n’avez pas mesuré. Un html-directory que vous n’avez pas listé, un DNS que vous n’avez pas lu : le refus vaut mieux que la supposition.
3. Ne touchez pas au pare-feu. /ip firewall filter est un chemin sensible : une règle malheureuse rend le routeur muet, et il n’y a pas de deuxième essai.

Annexe — relevé du parc au 2026-08-29

Balayage de 60 allocations connectées, en lecture seule :

Les 16 injoignables peuvent porter le même défaut sans qu’on puisse le voir : le contrôle depuis l’application, sur le LAN, est le seul moyen de les couvrir.