Hello,

As tu essayé de force la vitesse a 1g dans l'interface?

Il mets bien 2min a boot

Dac.

J'espère que vous aurez plus de chance que moi. Pour le moment bug omci de mon côté.

J'ai acheter le module twingig de Cisco pour pour souder les fils pour mon ttl. Je suis en attente de sa réception

Un petit résumé de ma journée concernant le G-010S-A version 3FE47111AFGB89.
J'ai compris que seul le daemon omcid fonctionnait sur nos équipements. La version du firmware que j'ai ne l'a pas.

Qu'a cela ne tienne, j'ai flashé une 3FE46398BFGA06 disponible sur le github de hwti : ici (merci pour ce repo)
Changement d'image, la procédure est simple et expliquée sur le repo... vérifications, checksums et reboot... Parfait ! Le fameux vieux daemon est bien ici : /opt/lantic/bin/omcid

Un petit tour dans /etc/init.d/omcid.sh, je décommente les lignes de lancement de "l'ancien" qui doit marcher : OMCID_BIN, ${OMCID_BIN}, killall -q omcid.
Je commente celles qui lancent le "nouveau" qui marche pas : #${PORT_MGR_BIN}, #${OMCI_MGR_BIN}, #${OMCI_PARSER_BIN}.

Allez !!! j'y vais : /etc/init.d/omcid.sh stop && /etc/init.d/omcid.sh start pour relancer et... paf ! plus rien  .

En fait non, l'onu reboot tout simplement et les modifications que j'avais faites ne sont pas gardées au reboot. Bon, je refais et m'aperçoit qu'il y a un chien de garde (applé deamon, pas daemon ) qui surveille si les processus /sbin/omciMgr, /sbin/parser, /sbin/portmgr et /webs/thttpd sont actifs et dans le cas contraire, pour les trois premiers: reboot.

Bon, je dois virer ce chien de garde : le fichier de config est /sbin/deamon_sfp.cfg ( pourquoi là ?) en readonly, grrr.
Je le copie dans /etc, vire les lignes concernant le "nouveau" et relance le chien de garde : kill -9 (chien_de_garde_pid) &&  /sbin/deamon /etc/deamon_sfp.cfg &
Je relance l'omcid : /etc/init.d/omcid.sh stop && /etc/init.d/omcid.sh start, ça tient, je surveille le passage en O5, je branche la fibre : ça passe  et en plus, je garde la main en ssh ! cool, je vais pouvoir logguer tout ça et il y a gtop qui fournit pas mal d'infos : je vois bien un(e) "gem" de l'arbre : Whaou c'est trop beau, je peux sentir le déplacement d'air de la connection à très haute vitesse !!!

Bon, après recoiffage, je n'obtient toujours pas d'ip publique (la livebox non plus) et il est dejà temps de remettre tout en ordre avant l'arrivée de mes petits ultra-superviseurs.
Mais j'ai quand même une autre idée que je vais tenter de mettre en œuvre demain : Je vais voir si je peux garder la main avec le "nouveau" firmware pour pouvoir debugguer le passage en O5, on sait jamais, ça pourrait servir... Au passage, mais je n'en suis pas encore là, il faudra trouver une idée pour que les modifications soient permanentes.

Bonne soirée à tous

Bon, je dois virer ce chien de garde : le fichier de config est /sbin/deamon_sfp.cfg ( pourquoi là ?) en readonly, grrr.
Je le copie dans /etc, vire les lignes concernant le "nouveau" et relance le chien de garde : kill -9 (chien_de_garde_pid) &&  /sbin/deamon /etc/deamon_sfp.cfg &
Je relance l'omcid : /etc/init.d/omcid.sh stop && /etc/init.d/omcid.sh start, ça tient, je surveille le passage en O5, je branche la fibre : ça passe  et en plus, je garde la main en ssh ! cool, je vais pouvoir logguer tout ça et il y a gtop qui fournit pas mal d'infos : je vois bien un(e) "gem" de l'arbre : Whaou c'est trop beau, je peux sentir le déplacement d'air de la connection à très haute vitesse !!!

merci beaucoup pour cette info!!! j'avais modifié le firmware pour avoir les modifications permanentes mais ce watchdog explique les reboots 

je vais essayer tout ça ce soir!!

PS:
en bas du fichier omcid.sh il y a :
#killall -q omcid
killall -q omciMgr
killall -q parser
je pense qu'il faut aussi modifier ces lignes mais ce n'est pas très grave parce que ça correspond juste à la fonction stop.

A+

Quand j'avais tenté d'utiliser un omcid tiers, j'avais tué plus de processus : deamon, omciMgr, parser, portmgr, msgmgr, diagnosis.

Si on arrive à faire fonctionner omcid, je pense que le mieux sera de rajouter un paramètre qui permette de choisir entre les deux.

Je viens d'ajouter un système de modification de firmware sur le github, avec une mise à jour du démon SSH pour avoir une config plus moderne, l'authentification par clé privée possible (pratique si on veut faire des scripts), et un boot plus rapide.

deamon sert de aussi watchdog pour l'interface web avec restart du process uniquement en cas de plantage, je me suis dit que ça ne coûtait rien de le garder.

Une fois qu'il a été lancé au boot, on n'a pas le choix : il a amorcé un watchdog dans le kernel, donc si on ne le relance pas on a aussi un reboot.

Génial ça ! et pourquoi pas faire une branche dev avec justement un custom firmware, on pourrait faire des pull requests 

Pour l'instant ça fonctionne comme un patch de l'image de départ, qu'on peut choisir.
C'est plus simple, car on ne peut pas stocker tous les fichiers directement sous git (au moins /dev).