Je suis en gardes successives. Mon prochain jour de repos sera mercredi.  Que voulez-vous que je poste?

Je suis en gardes successives. Mon prochain jour de repos sera mercredi.  Que voulez-vous que je poste?

Alors, pour pouvoir en profiter en un ou deux reboot, j'ai fait une petite liste :
avant de perdre la main :

• le modèle de l'olt : cat /configs/oltInfo
• dans les logs "persitants" : /logs/omci.log et /logs/omci.log.bak : Ils sont crées automatiquement par omciMgr à interval régulier et survivent au reboot (avec sûrement une limite de taille - il peut-être intéressant de les purger avant ?)
• ritool dump
• uci show
• fw_printenv

jusqu'à ce que tu perdes la main :

• celui "temps réel" : /tmp/omci.log

Le tout en virant ton serial en "clair" et en hexa

Bon courage pour les gardes ![/list]

Oui je comprends, mais d'un autre coté ca serrait peu etre utile d'avoir des recap complet des commandes a utiliser ?

Pour le nombre de caractère du Serial j'ai pas compter c'était juste pour illustrer la démarche.

Bon sinon pour la petite histoire j'écris se message depuis mon G-10S-A brancher sur un TP-Link MC220L lui même branché coté réseau sur la LB5 (Port 4).
Ca a l'air de sentir bon j'ai l'impression.

Le convertisseurs MC220L se connecte tout seul sans besoin de le rebooter.
La LB5 a besoin d'un reboot je pense, en tout cas ca na pas l'air de bouger sans ca (j'ai pas attendu 5min non plus)
La LB5 met 8min avant d'être opérationnel lorsque l'on passe de la fibre a un convertisseur Fibre/Reseau.

On voie rapidement de l'agitation coté MC220L, les voyant de la LB5 clignotant selon une certaine séquence.
On distingue ce qui semble être 2 opération via les LED : 5min pour la 1ere (La fin de la 1er Opération La 1ere LED clignote et 2+3 Fixe dur 2min40 environ)
Après ce qui est peu etre un redemarrage a environ 5min (La 1ere LED clignote seule puis la 2 va s'ajouter, ensuite la 3)

Oulà ! ce n'est pas encore une science exacte pour y aller du récap
En tous cas, si tu écris depuis l'onu, tu viens de valider l'étape 1 !!!

Bravo !!!



Pour l'instant, nous sommes à ma connaissance 3 à avoir inscrit un G-010S-A sur infra orange (Gnubyte, toi et moi).
Sinon, oui, le convertisseur est un convertisseur, il a besoin de rien, par contre, la LB a besoin de 2 reboots pour passer de l'ont interne à l'ethernet, sinon, il faut attendre des plombes...

Bravo encore.

Si tu as toujours la main (en ssh ou telnet) peux tu nous dire quel est ton olt (cat /configs/oltInfo) ?

edit : voire même si tu peux poster tes logs quelque part (voir 2 posts au dessus)
edit 2 : avec le convertisseur, ça plafonne vers 600Mbps, c'est normal, c'est pas super performant...

Oulà ! ce n'est pas encore une science exacte pour y aller du récap
En tous cas, si tu écris depuis l'onu, tu viens de valider l'étape 1 !!!
...
Si tu as toujours la main (en ssh ou telnet) peux tu nous dire quel est ton olt (cat /configs/oltInfo) ?

Félicitation filou59 !!! J'enrage :p

Je prédit un Alcatel dans oltInfo 

Félicitation filou59 !!! J'enrage :p
Je prédit un Alcatel dans oltInfo 

allez, si ça pouvait-être un huhu...

Long ago I setup an unlocked MA5671A as a replica of my ISP MA5671A but I've retraced my steps and dumped the omci log to try to assist the Orange brethren.

The differences between the replica are sfp_a2_info offsets 0x121 to 0x162 due to the amount of bytes that ethtool -m can acquire, image1_version being V8R017C00S202 rather than V8R017C00S207 due to time and updates by the ISP, and obviously goi_config as it's tuned for the laser hardware.

From the i2c dump provided by ethtool, I modified the u-boot environment variables sfp_a0_low_128 and sfp_a2_info.

scp sfp_a0_low_128 root@192.168.1.10:/tmp/
scp sfp_a2_info root@192.168.1.10:/tmp/
ssh root@192.168.1.10

fw_setenv sfp_a0_low_128 `cat /tmp/sfp_a0_low_128 | uuencode -m sfp_a0_low_128 | tr '\n' '@'`
fw_printenv -n sfp_a0_low_128 | tr '@' '\n' | uudecode -o - | hexdump -Cv
fw_setenv sfp_a2_info `cat /tmp/sfp_a2_info | uuencode -m sfp_a2_info | tr '\n' '@'`
fw_printenv -n sfp_a2_info | tr '@' '\n' | uudecode -o - | hexdump -Cv
reboot

# u-boot env vars gserial and ethaddr will update to those found in sfp_a2_info
# correct nSerial for authenticity

ssh root@192.168.1.10
fw_setenv nSerial 'value @ offset 0x60 in sfp_a0_low_128'

Everything works fine with it being a 90% clone. I changed /etc/init.d/omcid.sh to include -d1 and -l/tmp/omci.log

https://gist.githubusercontent.com/up-n-atom/99260bfafd5cd285a3a77ecaaadd125b/raw/afc3ca31b4d9c11ba34b43d9a37f2d2a665815c4/omci.log

I've added comments ';' to some of the TX packets so you can get an idea where the values come from, ie. env vars or files.

[omcid] 03:35:36 CORE  PRN: 131@0 set OLT vendor id             = 48 57 54 43 "HWTC"
[omcid] 03:35:36 CORE  PRN: 131@0 set Version                   = 31 30 00 00 00 00 00 00 00 00 00 00 00 00 "10            "
OLT is HWTC10 which I believe is the troublemaker for ya'll. I know it's an apples to oranges comparison between a MA5671A and G-010S-A but some differences might present themselves. I've noticed for example that the OMCC version used by the MA5671A is 0xA0 while the G-010S-A is 0x86.

0x80 ITU-T G.984.4 (06/04)
NOTE – For historical reasons, this code point may also appear in
ONUs that support later versions of [ITU-T G.984.4].
0x81 ITU-T G.984.4 2004 Amd.1 (06/05)
0x82 ITU-T G.984.4 2004 Amd.2 (03/06)
0x83 ITU-T G.984.4 2004 Amd.3 (12/06)
0x84 ITU-T G.984.4 2008 (02/08)
0x85 ITU-T G.984.4 2008 Amd.1 (06/09)
0x86 ITU-T G.984.4 2008 Amd.2 (2009). Baseline message set only,
without the extended message set option
0x96 ITU-T G.984.4 2008 Amd.2 (2009). Extended message set
option, in addition to the baseline message set.
0xA0 ITU-T G.988 (2010). Baseline message set only, without the
extended message set option
0xA1 ITU-T G.988 Amd.1 (2011). Baseline message set only
0xA2 ITU-T G.988 Amd.2 (2012). Baseline message set only
0xA3 ITU-T G.988 (2012). Baseline message set only
0xB0 ITU-T G.988 (2010). Baseline and extended message set
0xB1 ITU-T G.988 Amd.1 (2011). Baseline and extended message set
0xB2 ITU-T G.988 Amd.2 (2012). Baseline and extended message set
0xB3 ITU-T G.988 (2012). Baseline and extended message set

Nuances in the mibs or even software version might be the ticket.