(page 272 (juste pour sauvegarde où j'étais!))

=> je vais surement souscrire à Orange FTTH 1000/300 en .. Pologne

à voir si je peux y mettre mon ONT SFP

Merci

Pour ceux que ça intéresse, la ligne est fournie avec une Funbox 6 https://www.orange.pl/omnibook/orange-funbox-6
Je n'ai pas idée si le matériel est partagé avec les dernières LB en France mais ça sera intéréssant à décortiquer.
Aussi il y'a un ONT intégré. Parfois il y'a un ONT externe. A voir ce qui sera fourni ou si je peux demander à avoir un ONT externe.

L'ONT externe est le boitier classique qu'on voit partout, je dois avoir le même modèle dans mes cartons d'ailleurs !

/etc/optic/.goi_recovered est toujours un fichier vide : il signale simplement que le script /etc/init.d/recover_goi.sh a été exécuté : les fichiers de calibration ne sont donc extraits de la variable "goi_config" du bootloader qu'une seule fois, au premier boot.
Effacer /etc/optic/.goi_recovered permet donc de restaurer les fichiers de calibration propre à votre ONT au prochain boot.

J'ai regardé l'image mtd2.bin de https://raw.githubusercontent.com/akhamar/orange-2500mbps-G010SP/master/CarlitoxV1.zip.
Elle correspond à un dump fait d'un ONT ayant booté au moins une fois, et n'a pas été nettoyée.
Il est probable que beaucoup d'images dumpées depuis un ONT Lantiq (sauf G-010S-A) aient le même problème.

Une image OpenWrt classique de ce type contient plusieurs éléments :
 - entêtes et kernel
 - rootfs (squashfs) : c'est l'ensemble des fichiers du firmware, en lecture seule
 - overlay (jffs2) : c'est l'ensemble des modifications faites sur le rootfs (configuration, ...)

Ici l'overlay n'est pas vide, en flashant on récupère tous les réglages de l'ONT Carlitoxx qui a été dumpé, y compris sa calibration !
C'est pour ça qu'après l'avoir flashée, il est nécessaire d'effacer le /etc/optic/.goi_recovered pour retrouver la bonne calibration.

Une autre solution est de faire un factory reset pour effacer tout l'overlay : "firstboot", puis "reboot".

Idéalement, la personne publiant les images aurait dû les nettoyer en effaçant la partie JFFS2 (simplement en la remplissant de 0xFF, l'ONT l'aurait formatée au premier boot).

Merci pour toutes ces explications pourrait-tu nous indiquer les valeur nominal que doit avoir l'ONU et ou les visualisé ?

Voilà les test de débit depuis mon PC et en CLI avec Speedtest depuis mon DS218+

Les valeurs sont dans la plage acceptable, en revanche l'écart entre les deux RxPower semble élevé.

Est-ce que c'est avec les données de calibration de l'image Carlitoxx, ou est-ce que tu as effacé /etc/optic/.goi_recovered et rebooté ?

Je possède, en cas de panne du premier, un deuxième ONU MA5671A toujours flashé en Calitoxx, pour ce dernier les valeurs obtenues avec otop sont les suivantes :

    RSSI 1490 power : -19,00 dBm
    tx power : 1,18 dBm

Les deux ONU ont été identiquement configurés, avec en particulier la suppression du fichier /etc/optic/.goi_recovered, suivi d'un reboot. Surprenant de constater de tels écarts non ? Les deux ONU sont parfaitement fonctionnels avec des débits de 235 MB/s et d'une grande stabilité dans le temps : uptime supérieur à un mois hormis les reboot dus aux essais divers et variés.

D'autre part, pour des raisons "historiques" de numérotation de mes sous-réseaux, l'IP par défaut de l'ONU 192.168.1.10 ne me convenait pas. J'ai donc modifié l'IP est utilisant la commande fw_setenv ipaddr 192.168.x.x et reboot. Dans un message en date du 25/11/2020 hwti exprimait des doutes sur la manipulation, ils n'ont pas lieu d'être j'en confirme le bon fonctionnement, il est également possible de modifier les variables  gatewayip et netmask pas de problèmes ni au reboot ni à la connexion SSH. Cependant même après ajout de la route adéquate dans l'ONU, j'arrive à pinguer depuis l'ONU mon routeur Debian sur lequel est branché l'ONU, mais impossible de pinguer le reste du réseau, donc pas d'interface web de l'ONU depuis un client du sous-réseau. La commande route sur l'ONU semble fournir les bonnes routes, j'ai vérifié le firewall du routeur mais rien... Pas même la trace d'un paquet sniffé avec un tcpdump depuis le routeur Debian. Je loupe peut-être une évidence, mais là je sèche... Toutes les suggestions sont les bienvenues.