J'avance doucement car je ne peux bricoler mon ONU que tard le soir quand tout le monde est couché ! ;-)
exact.
il faut bien que l'image sur laquelle tu boot soit l'image avec la version de firmware la plus récente. Sinon l'OLT risque de pousser en boucle un update du firmware...
fw_setenv onu_serial XXXX (SN en ASCII)
fw_setenv onu_ploam XXX (SLID en ASCII)
fw_setenv image0_version 3FE7SW04040022
fw_setenv image1_version 3FE7SWS04040018
fw_setenv image1_is_valid 1
fw_setenv mib_file data_1g_8q_us1280_ds512.ini
la commande fw_setenv image1_is_valid 1 va mettre la version passive en active et inversement, pour booter sur la 022 c'est fw_setenv image1_is_valid 1 pour la 018 fw_setenv image0_is_valid 1
C'est bien la version 3FE7SW04040022 qui est la plus avancée à ce jour ? (désignée "Version principale" par l'interface d'administration web de la NB6VAC)
Si je définis l'image0 sur cette version, ne devrais-je pas définir l'image0 comme étant "valid" ? (fw_setenv image0_is_valid 1)
Autrement je ne comprends pas la logique !
d'ailleurs je ne vois pas ce qui poserait problème si on mettait la version 0022 sur les 2 images
fw_setenv image0_version 3FE7SW04040022
fw_setenv image1_version 3FE7SW04040022
Quoi qu'il en soit, en cherchant ce soir à m'assurer que j'avais bien démarré sur une image en version 3FE7SW04040022, à coup de fw_setenv, de reboot et de fw_printenv, j'ai remarqué que fw_printenv renvoyait le numéro de version original FS.com (débutant par 6BA1896…) pour l'image1, sans tenir compte de la commande fw_setenv image1_version 3FE7SWS4040018 exécutée précédemment.
Au gré des reboots :
1° J'ai ainsi remarqué qu'exécuter fw_setenv image1_is_valid 1 ne basculait pas automatiquement image0_is_valid à 0. J'avais donc à la fois image0_is_valid 1 et image1_is_valid 1.
2° Sans chercher à déterminer par d'autres moyens avec laquelle des 2 images le SFP fonctionnait, j'ai voulu de nouveau repartir à zéro avec les commandes firstboot puis reboot. Il a fallu plus de temps que d'habitude pour que l'ONU redémarre, puis PuTTY m'a signalé que l'empreinte SSH avait changé, ce qui laissait entendre que la remise à zéro avait (de nouveau ?) fonctionné, mais finalement un fw_printenv renvoyait mes variables personnalisées ! (onu_serial, onu_ploam, image0_version…)
3° Faute de parvenir à le remettre à zéro via la commande firstboot prévue à cet effet, j'ai commencé à supprimer des variables superflues : par exemple en exécutant fw_setenv image00_version (pour supprimer une variable image00_version apparue je suppose quand j'ai exécuté fw_setenv image0_version 3FE7SW04040022 alors qu'elle était déjà définie ?), puis fw_setenv image1_is_valid, puis fw_setenv nSerial et fw_setenv nPassword, car l'une des deux semblait encodée en héxadécimal et car elles me paraissaient en conflit avec les variables onu_serial et onu_ploam. Puis j'ai exécuté "reboot". Mais j'ai bien peur d'avoir brické le SFP : dans le convertisseur de média UMC-GA1F1T, le voyant FX/LNK du logement SFP reste désormais éteint, et dans mon MikroTik hEX S, le voyant SFP reste éteint aussi ! :-/
Avez-vous donc des idées :
1° Pour ressusciter mon ONU ?
2° Sur mes autres déboires ? (fonction firstboot qui ne fonctionne pas, problème de version, d'image…)
Je reste optimiste car j'ai découvert ce soir des erreurs et problèmes dans ma configuration, ce qui me donne espoir qu'après les avoir corrigés ça pourrait enfin fonctionner !
Merci par avance !