Vu que je n'ai pas de supervision humaine sensible chez moi, j'ai pu faire le test avec un g-010s-a que j'ai

Avec le hardwareversion à SMBSSGLBF115 sans padding ça passe !
Je n'ai pas encore réussi à le faire fonctionner avec HWTCA17C6A (avec ou sans padding)

Pas sûr que les \0 fonctionnent pareil avec ritool.
Peut-être que le padding n'est pas fait, et que ritool n'écrit que les caractères qu'on lui donne (avec donc des caractères des anciennes valeurs plus longues qui restent à la fin).
Les dumps de /dev/mtd8 "ri" pourraient donner la réponse.

Quelle est la différence entre le SLID disponible dans ri et le SLID de la config web ?

Normalement c'est la même valeur.
Tu as un problème particulier ?

Vu que je n'ai pas de supervision humaine sensible chez moi, j'ai pu faire le test avec un g-010s-a que j'ai

Avec le hardwareversion à SMBSSGLBF115 sans padding ça passe !
Je n'ai pas encore réussi à le faire fonctionner avec HWTCA17C6A (avec ou sans padding)

Veinard 
Oui, SMBSSGLBF115 tout court passe avec le G-010S-A et omciMgr sur olt ALCL : ça tourne chez moi depuis le 11 janvier sans absolument aucun soucis.
C'est dingue que HWTCA17C6A tout court ne passe pas !
j'essaierai les mêmes tests sur le G-010S-P la semaine prochaine (j'ai pas encore réussi à l'authentifier celui-là mais j'ai pas vraiment insisté)

En fait en regardant les binaires, c'est plus compliqué, il y a une couche de configuration supplémentaire !

Le page web appelle /webs/gpon_config.cgi, qui :
 - fait deux appels set_cfg_node (libconf_api.so) pour SLID et SLIDMode
 - donne la valeur à /dev/onu0 (donc comme si on avait appelé onu en ligne de commande)

/lib/libconf_api.so communique par socket avec /sbin/lcfgmgr, qui enregistre les deux valeurs dans /configs/cfg.conf (dans /dev/mtd6, "configfs").

Donc je suppose qu'au boot, soit lcfgmgr, soit omciMgr (ou une combinaison des deux) doivent lire la valeur /configs/cfg.conf et si elle n'est pas présente dans ri, puis la donner à /dev/onu0.

Le /etc/init.d/onu.sh lit la config uci gpon.ploam.nPassword et initialise onu avec, mais je pense que c'est un reste du SDK Lantiq, et que sur le G-010S-A c'est surchargé ensuite (du moins tant qu'on utilise omciMgr, si on arrive à utiliser omcid ce sera peut-être différent).

Excellente piste. Suivre le fil des processus d'initialisation. Dénouer, comprendre, clarifier, puis reprendre.
Comprendre autant que possible tout le périmètre de la configuration des sticks, de la meilleure façon de l'adapter à nos besoins.
Continuons à libérer nos fibres de cet obscurantisme inutile.
Donnez moi 8 heures d'absolue totale absence d'interaction avec ces trucs de virus et de masques, que je participe !
8 heures pas jour.
Pleins de jours de suite.
Confinez moi !!!

Pour BT, je l'ai renseigné via l'interface web, c'était pris en compte, même si de mémoire ritool m'affichait lui une valeur générique, pas ce qui était rentré dans l'interface web.

Hello,

En comparant les fichiers omci.log de mon G-010S-A avec ceux de SteveRush j'ai remarqué deux trucs étranges. Il semblerait que tous les VLANS soient mappés sur le bridge port nbr 0.


-> Mes logs sur OLD Huawei
$ cat omci-huawei.log | grep -i bridge |grep FVID
EVTOCD : Getting the PQMapper for FVID: 832 TVID: 832 bridge_port_nbr: 0
EVTOCD : Getting the PQMapper for FVID: 835 TVID: 835 bridge_port_nbr: 0
EVTOCD : Getting the PQMapper for FVID: 838 TVID: 838 bridge_port_nbr: 0
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 0
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 851 bridge_port_nbr: 0
EVTOCD : Getting the PQMapper for FVID: 4096 TVID: 1 bridge_port_nbr: 0


-> SteveRush sur OLT ALcatel
$ cat omci-pub.log  | grep -i bridge | grep FVID
EVTOCD : Getting the PQMapper for FVID: 832 TVID: 2800 bridge_port_nbr: 2
EVTOCD : Getting the PQMapper for FVID: 835 TVID: 835 bridge_port_nbr: 3
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
rcvd_vlan_opr_table.value = f8 00 00 00 EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 851 TVID: 852 bridge_port_nbr: 4
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 5
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 5
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 5
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 5
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 5
EVTOCD : Getting the PQMapper for FVID: 840 TVID: 840 bridge_port_nbr: 5
EVTOCD : Getting the PQMapper for FVID: 838 TVID: 838 bridge_port_nbr: 6


Par ailleurs si on grep sur "delete_Flow" on à l'impression que les flows sont deletés. Je ne sais pas trop à quoi cela correspond.

Pour finir j'ai trouvé comment chargé dans Wireshark l'ensemble des messages OMCI du fichiers omci.log sur la base de ces deux sites:


et ce site pour comment patcher le plugin wireshark.
https://ask.wireshark.org/question/4557/bindechexlua-error-bad-argument-to-module-packageseeall/