TL;DR;
Script de contrôle de la prise IQSocket d'IQTronic disponible ici :
https://github.com/nanawel/iqsocket-control
Orange, ô désespoir
Je suis passé à la fibre en 2016 (youhou) mais je n'ai pas eu le choix du FAI (oh...) et me suis donc retrouvé avec Orange et sa Livebox. Historiquement j'en avais pas une super image, surtout de leur matos qui - par expérience - était d'une fiabilité médiocre.
J'ai malgré tout opté pour la Livebox Play, et, même si j'aurais pu la remplacer par un routeur plus classique (au prix de la perte - relative - du téléphone fixe) j'ai décidé de lui donner une chance. Et ça a marché. Quelques semaines.
Puis, un beau jour, oh, plus de connexion. Et la Livebox ne répond plus par Ethernet. Alors reboot forcé.
Une fois. Puis deux. Puis d'autres. Sauf que je ne suis pas toujours sur place pour la rebooter, et la situation commence à me peser un peu car mon serveur tourne derrière, et c'est bien beau d'avoir 10Mo/s en upload mais ça ne sert à rien si de manière impromptue la connexion lâche et nécessite une intervention manuelle.
IQSocket, IQ so cool
Je commence à me dire qu'il me suffirait d'avoir une prise pilotable contrôlée par mon serveur pour que le problème soit réglé : un script teste régulièrement la connexion Internet, et si elle est down, on envoie un signal à cette prise pour qu'elle reboote méchamment la box. Dans l'idée c'était ça.
Mais en cherchant sur le Net une telle prise, je tombe sur a priori bien mieux que ça : la IQSocket de IQTronic. Une prise pilotable qui est déclinée en plusieurs interfaces : RS232, Ethernet, GSM, Bluetooth.
La version qui m'intéresse ici est bien sûr celle pilotable par Ethernet (appelée LAN). Et pourquoi est-ce "bien mieux que ça" ? Parce que cette prise intègre directement une fonction de watchdog utilisant le PING vers un ou plusieurs hôtes, et déclenchant automatiquement un redémarrage de la prise dans le cas où cette commande échouerait.
Même plus besoin d'un script qui tourne sur le serveur, magnifique ! me dis-je, naïf que j'étais.
IQTS-IP200
Le prix est clairement un peu élevé (60 €), mais je me dis que c'est un appareil assez générique et qu'il aura toujours une place à un endroit ou un autre même s'il n'est plus nécessaire à terme pour l'usage initial. Et puis je n'ai pas d'alternative et ma box continue de freezer régulièrement ce qui me gonfle franchement. Alors banco.
Une fois la prise reçue, la configuration est simplissime. Il faut juste penser à changer temporairement la configuration réseau du PC qui va accéder à l'interface web car la prise prend par défaut l'adresse 192.168.0.100/24 (donc inaccessible par le réseau 192.168.1.0/24 configuré par défaut sur la box).
Une fois ceci fait on peut accéder à l'interface web tournant sur le port 80. Et on y trouve une série de pages au design... heu, un peu soviétique, mais efficace.
On peut notamment définir les règles de surveillance qui vont contrôler l'état de la connexion et déclencher les reboots si nécessaire.
La page de configuration des règles
Ici je suis allé au plus simple : la règle 1 définit un PING de 64 octets de données vers l'adresse 8.8.8.8 (le DNS de Google), avec un timeout de 1 seconde et une limite de perte de 50%.
Plus bas, on précise également quelques options communes à toutes les règles :
- Envoi d'un paquet toutes les 5 secondes
- Garde du restart de 120 secondes
- Annulation possible par SNMP
- Temps de coupure de la prise de 5 secondes
- Nombre de paquets à évaluer : 10
Ce qui signifie, si je ne dis pas de bêtises, que la prise va envoyer un PING de 64 octets vers l'adresse 8.8.8.8 toutes les 5 secondes, que la réponse devra arriver en moins de 1 seconde, qu'elle va évaluer le taux de succès des 10 derniers paquets glissants et que dans le cas où ce taux passerait sous les 50%, alors elle va se mettre en mode "conservation" (préparation de restart) pendant 120 secondes.
Si durant cette période le taux de succès repasse au-dessus de 50% ou si une annulation SNMP est reçue, elle va sortir du mode "conservation" et aucune action ne sera déclenchée, le processus continuera comme précédemment.
Si à l'inverse, à l'issue de ce délai le taux est toujours en dessous de 50%, alors le restart est déclenché, ce qui coupe l'alimentation de tous les appareil connectés à la prise (ici, la box) pendant 5 secondes, puis le rétablit. La prise attend ensuite 4 minutes pour recommencer à tester l'état de la connexion. Et le cycle reprend.
Le principe est très bien décrit dans le manuel fourni par le fabricant (§ Diagram of rules evaluation).
Une fois en place, le système a bien fonctionné et il ne m'a pas fallu attendre longtemps pour que les premiers reboots forcés se déclenchent. Ce qui était mauvais signe d'un côté (perte de connexion Internet) mais bien de l'autre (la prise le détecte et agit).
Mais c'était sans compter sur un nouveau problème (sur l'air de "Et là, c'est le drame")
Ping et pong sont sur un bateau
Je me rends rapidement compte que la prise reboote souvent plusieurs fois d'affilée la box, alors que de mon PC ou du serveur je ne détecte pas de coupure Internet. Au mieux ce sont 2 reboots, au pire cela peut prendre 5 à 6 reboots avant que la prise ne détecte la connexion comme rétablie et stable. Alors que ce n'est jamais nécessaire et qu'un seul reboot suffirait !
Avec les timeouts et délais choisis, cela signifie que pendant parfois 30 minutes, la connexion va être régulièrement coupée pendant 2-3 minutes pour cause de reboot intempestif de la box.
En regardant les compteurs visibles sur l'interface web de la prise, je constate bien que le comportement est logique car des PING sont bien envoyés mais aucune réponse ne semble reçue. Jusqu'à ce qu'à un moment ça "retombe" en marche, par le truchement de je ne sais quel facteur.
Je tente des ajustements de config, l'augmentation des timeouts, etc. mais rien n'y fait. La plupart du temps après un restart déclenché automatiquement par la prise, les PING suivants ne reçoivent aucune réponse.
Je décide de contacter le support, dans l'espoir qu'un nouveau firmware corrige ce comportement. Mais après plusieurs échanges très sympathiques (mais un peu basés sur le classique "Have you tried turning it off and on again?") aucune solution n'est finalement trouvée.
SNMP, si, c'est possible
Finalement, je me dit qu'il serait peut être plus simple de désactiver complètement la fonctionnalité de watchdog de la prise et de la déporter sur une machine du réseau, au hasard mon serveur Usul. Car oui, cette option semble possible grâce à l'interface SNMP fournie par la prise.
Détail de l'interface SNMP fournie
Mais finalement je trouve un compromis plus intéressant, qui ne nécessite pas que le serveur soit absolument disponible et permet de continuer à surveiller en mode dégradé la connexion directement depuis la prise seule :
- La prise conserve sa configuration et son watchdog, ce qui garantit l'autonomie du couple prise+box, même si sa fiabilité n'est pas satisfaisante seul.
- Un script tourne en permanence sur le serveur et surveille le surveillant (à savoir la prise).
- Dans le cas où le script détecte que la prise passe en mode "conservation", donc prête à lancer un restart, il teste lui aussi le PING vers le même hôte.
- Si le PING réussit, il envoie la commande CANCEL RESTART à la prise qui annule donc le restart, mais continue à surveiller la connexion.
- Si le PING échoue, aucune commande n'est envoyée et la prise rebootera la box si la connexion n'est pas revenue dans les 2 minutes. Pendant ce temps, le script continue de tester la connexion aussi de son côté ce qui peut entraîner l'exécution du point 4. Tout ça n'a demandé qu'une poignée d'heure d'implémentation grâce à Symfony et l'extension SNMP de PHP. Le tout est packageable dans un container Docker pour, à la fois éviter de dépendre de PHP sur l'hôte, et gérer plus élégamment le redémarrage automatique en tâche de fond au boot.
Le repo est disponible sur Github :
https://github.com/nanawel/iqsocket-control
Si ça peut servir !