Pour permettre le bon fonctionnement de testconnec, il doit connaître l'état de la connexion.
Le mieux est de passer par un diagramme d'état pour modéliser un automate d'état permettant de prévoir les changements d'états à traiter et éviter que startadsl, stopadsl, la connexion au démarrage et testconnec se marchent sur les pieds...
Cela permet aussi de définir la stratégie de testconnec : maintenir la connexion sauf demande d'arrêt de l'utilisateur...

Je propose de coder l'état comme étant l'agglutination de plusieurs informations : état du modem (= eaglestat), module chargé (= lsmod), connexion lancée (=$SYSCONF_FILE), connexion active (=ping), autres ?
Et je ne sais pas s'il faut mettre le de type de connexion dans l'état. Comme on ne devrait pas en changer dynamiquement, il est raisonnable de considérer que cette information paramètre le programme. Mais ce n'est peut-être pas plus simple à coder.-- mcoolive

Quelques réalisations : TestConnec1 TestConnecTux?

Objectif de testconnec

S'il faut maintenir la connexion, testconnec doit faire en sorte de la restaurer (avec quelques traces pour faire un état des lieux)

S'il ne faut pas maintenir la connexion, se rendormir

Contexte

Ici on parle de startadsl / stopadsl, indépendemment de l'implémentation (fctStartAdsl, fctStopAdsl, eu_dsp...) au sens de démarrage / arrêt de l'adsl demandé par l'utilisateur.
Cela permet d'éviter le cas particulier des impacts sur EagleConnect et autres outils qui utilisent les briques de base de eagle-usb : permet de distinguer la prise d'action de "qui" (au sens script implémenté) prend l'action.

Les connexions Free dégroupé (routed ip) / Free non dégroupé (pppd/pppoa) / DeutschTelecom? (pppd/pppoe) ont des critères voire des stratégies différentes... dont il faut tenir compte

• pppd inclut une reconnexion automatique (notamment pour la coupure des 24h...) => valable en pppoe / pppoa, attention nb de reconnexions limité et ne peut fonctionner que si modem operational
• idem pour dhcpcd ? dhclient ?
• en static seul testconnec peut restaurer la connexion
• si eaglestat ne donne pas modem operational c'est un peu plus compliqué (pb d'urb, module en vrille, ...) => peut nécessiter de décharger/recharger le module, voire décharger/recharger l'usb (avec les conséquences du hotplug...), certains se contentent d'un reboot brutal (déjà vu...)
• autres cas ? (passage de Free non dégroupé à Free dégroupé, ...)

Limites

Lorsque LOS defect ou 97th, c'est le module qui gère tout seul, comment traiter ?
Si le site servant de ping tombe, peut-être prévoir un 2ème test sur autre site indépendant pour valider que la connexion est vraiment tombée ?
Si l'utilisateur a mal configuré sa connexion, ya peut-être rien à faire (exemple de clamp mss si la connexion est utilisée par une gateway ?) => yaura des déconnexions, réglées par une bonne configuration et non par un "contournement" comme testconnec
Pour faire simple, on ne va prendre que le cas ou modem operationnal, sinon c'est d'autres actions qui doivent être prises... (un peu plus compliqué on verra après)

Critères

• testconnec opérationnel : peut-être intéressant pour startadsl / stopadsl
• pppd opérationnel et modem operationnal : peut-être laisser pppd travailler ?
• messages dans /var/log/messages ?
• résultat de eaglestat (modem operationnal)
• hotplug utilisé ou non (ça complique...)
• connexion au démarrage ou non

Etats pour Free dégroupé sans hotplug sans connexion au démarrage en IP fixe (sans dhcpcd ni dhclient)

ça doit être le cas le plus simple ?

Les cas identifiés sont :

• on a modem operationnal (cf. limites)
• START_CONNECT_UP (au sens startadsl) => testconnec doit restaurer la connexion si elle n'est plus présente
  • TEST_CONNEC_UP "la connexion est ok"=> rien à faire
  • TEST_CONNEC_DOWN "la connexion est ko" => relancer la connexion
• START_CONNEC_DOWN (stopadsl demandé) => testconnec ne doit rien faire
  • TEST_CONNEC_UP "la connexion est ok" => ne devrait pas arriver... testconnec ne fait rien ?
  • TEST_CONNEC_DOWN "la connexion est ko" => normal, testconnec ne fait rien

Il y a le cas (tordu) où un 2ème testconnec se lance (genre ça met plus de 2mn à se reconnecter...), si un 1er testconnec travaille encore il faut savoir le déterminer (prévoir l'état intermédiaire ou testconnec travaille déjà à reconnecter, le 2ème ne doit rien faire)

faire la table de vérité (dans un tableau...)

Etats pour Free non dégroupé

Histoire de prendre un autre type de connexion, regardons Free non dégroupé = pppd / pppoa

• on a modem operationnal (cf. limites)
• pppd gère une reconnexion 10 fois (par défaut) => faut-il le laisser travailler ?oui, pppd est plus rapide pour détecter l'état de la connexion. On y gagne en transparence.
  
• en fait c'est pareil qu'au dessus : quand pppd n'est plus actif, testconnec relance la connexionProblème: quand pppd est en train d'essayer de se connecter (juste après un startadsl) et que testconnec se lance à ce moment: testconnec considère que la connexion ne fonctionne pas et tue pppd. Ce n'est pas trop grâve mais on perd quelques secondes. Il faut règler un timing (2 minutes aujourd'hui) pas trop agressif : peut-être imposé un règlage en minutes.

Méthode de relance de la connexion

• parfois un stopadsl ; startadsl est plus efficace que d'essayer de relancer la connexion ? (j'ai même pas encore regardé ce que fait testconnec ;-) )méthode employée par TestConnecTux?
  
• prévoir un petit diagnostic quand même quand la connexion est down : essayer de savoir ce qui s'est passé (déco 24h, déco impromptue) via quelques tests...

(à compléter)

---