Pourquoi vos tickets WiFi n'expirent plus jamais (et comment le réparer)
Si vos hotspots MikroTik tournent en RouterOS 7.10 ou plus récent, il y a de fortes chances que vos tickets Mikhmon laissent passer des clients gratuitement sans que vous le sachiez. Voici la cause exacte, comment la vérifier sur votre propre routeur, et trois façons de la corriger.
1. Le symptôme
Un client achète un ticket WiFi d'une heure, deux heures, ou une journée. L'heure passe. Le ticket ne se déconnecte jamais. Il continue à naviguer gratuitement, parfois pendant des jours, et l'opérateur ne s'en rend compte qu'en regardant son chiffre d'affaires baisser sans explication.
Ce n'est pas un piratage, ni un bug aléatoire. C'est un changement silencieux fait par MikroTik lui-même, qui casse un maillon précis de la chaîne utilisée par Mikhmon (et par beaucoup d'autres scripts de gestion de hotspot) pour calculer les dates d'expiration.
2. La cause réelle
Avant RouterOS 7.10, la commande interne qui donne la date du routeur retournait un texte du type jul/06/2026 — mois abrégé, jour, année, séparés par des barres obliques. À partir de RouterOS 7.10, MikroTik a changé ce format pour suivre le standard ISO 8601 : 2026-07-06 — année, mois, jour, séparés par des tirets.
Ce changement a été confirmé et documenté publiquement par la communauté MikroTik : un fil du forum officiel, intitulé en anglais « RouterOS v7.10+ va casser tous les scripts basés sur la date système », explique que le format est passé de may/10/2023 à 2023-05-10, et que cela touche toute commande qui renvoie une date : horloge système, journaux, certificats, planificateur de tâches, etc.
Le problème, c'est que la plupart des scripts d'expiration de tickets — dont ceux utilisés par Mikhmon — ne « comprennent » pas vraiment une date. Ils lisent simplement des caractères à des positions fixes dans le texte, en supposant l'ancien format. Par exemple, le script s'attend à trouver le jour aux positions 4 et 5, et l'année aux positions 7 à 11 — ce qui fonctionne pour jul/06/2026, mais tombe sur n'importe quoi avec 2026-07-06.
Résultat concret : le script extrait des fragments de texte qui ne correspondent à aucune date valide, le calcul de la date d'expiration échoue silencieusement, et RouterOS ne reçoit jamais l'ordre de couper l'accès. Le ticket reste actif tant que le hotspot tourne.
3. Vérifier si vous êtes concerné
Deux minutes suffisent pour savoir si vos hotspots sont exposés. Sur chaque routeur, ouvrez le terminal MikroTik (Winbox, WebFig, ou SSH) et tapez :
/* Vérifier la version RouterOS installée */ /system resource print
Regardez la ligne version. Si le numéro est 7.10 ou supérieur (7.11, 7.12, 7.13, 7.14, 7.15, 7.16.x, 7.17, 7.18…), passez à l'étape suivante. Ensuite, vérifiez directement le format renvoyé par l'horloge :
/* Afficher la date telle que la lisent vos scripts */ /system clock print
Si le champ date ressemble à 2026-07-06, votre routeur est bien passé au nouveau format — et si votre version de Mikhmon n'a pas été mise à jour pour le gérer, vos tickets sont probablement en train de ne plus expirer en ce moment même.
| Version RouterOS | Format de date | Compatible ancien script Mikhmon |
|---|---|---|
| 7.9 et antérieures | mmm/jj/aaaa | Oui |
| 7.10 et supérieures | aaaa-mm-jj | Non, sauf script mis à jour |
4. Trois façons de corriger le problème
Option A — Rétrograder RouterOS (rapide, mais temporaire)
Réinstaller une version antérieure à 7.10 restaure immédiatement l'ancien format de date, sans toucher au script. C'est la solution la plus rapide pour arrêter l'hémorragie aujourd'hui, mais ce n'est pas viable à long terme : vous vous privez des correctifs de sécurité et des nouvelles fonctionnalités de RouterOS, et le jour où vous devrez remettre à jour, le problème reviendra.
Option B — Corriger le script pour qu'il gère les deux formats (recommandé)
La solution durable consiste à modifier le script d'expiration pour qu'il détecte automatiquement le format avant de lire la date, au lieu de supposer un format fixe. Le principe, utilisé par plusieurs scripts open source de la communauté MikroTik pour ce même problème :
/* On regarde si le premier caractère est un chiffre */
/* -> chiffre = nouveau format aaaa-mm-jj */
/* -> lettre = ancien format mmm/jj/aaaa */
:local rawDate [/system clock get date];
:if ([:len [:tonum [:pick $rawDate 0 1]]] > 0) do={
/* Nouveau format ISO : aaaa-mm-jj, on l'utilise tel quel */
:local year [:pick $rawDate 0 4];
:local month [:pick $rawDate 5 7];
:local day [:pick $rawDate 8 10];
} else={
/* Ancien format : mmm/jj/aaaa */
:local month [:pick $rawDate 0 3];
:local day [:pick $rawDate 4 6];
:local year [:pick $rawDate 7 11];
}
Une fois cette détection en place, le calcul de la date d'expiration redevient fiable, quelle que soit la version de RouterOS installée sur le hotspot — y compris les futures mises à jour.
Option C — Passer par l'éditeur de Mikhmon
Comme ce changement de format touche tous les opérateurs utilisant RouterOS 7.10+, il est probable qu'une version corrigée du script Mikhmon existe déjà ou soit en cours de développement. Avant de patcher vous-même en production, vérifiez le changelog de Mikhmon ou contactez son éditeur : une mise à jour officielle vous évite de maintenir un script modifié par vous-même sur chaque routeur.
5. Pour aller plus loin
- Auditez tous vos hotspots un par un : la version RouterOS varie souvent d'un site à l'autre selon la date d'installation.
- Ne mettez plus jamais à jour un routeur de production sans tester d'abord le script d'expiration sur un routeur de test.
- Si vous gérez plusieurs dizaines de hotspots, envisagez un script de vérification centralisé qui remonte la version RouterOS et le format de date de chaque routeur.
- Gardez une trace écrite de la version de script Mikhmon installée sur chaque site, pour savoir lesquels ont déjà reçu le correctif.
Le fond du problème n'est pas un bug isolé : MikroTik a délibérément standardisé ses dates au format ISO 8601, ce qui est une bonne décision à long terme pour l'écosystème. Le vrai enjeu, c'est de s'assurer que les scripts métier — comme ceux qui font tourner votre activité de vente de tickets — suivent ce genre de changement d'infrastructure avant qu'il ne vous coûte de l'argent.
Sources consultées pour cet article :
- Forum communautaire MikroTik — fil d'alerte sur le changement de format de date en RouterOS 7.10+ : forum.mikrotik.com
- Forum communautaire MikroTik — discussions de scripts cassés par le nouveau format ISO (hotspot, PPPoE, sauvegardes) : forum.mikrotik.com
- Dépôts publics de scripts RouterOS gérant la détection ancien/nouveau format de date (GitHub, projets communautaires)
