IC-prog levert 256 byte SFP-dump, maar de tweede helft is een kopie van de eerste, pagina A2 niet leesbaar (HP 2530-24G)
Ik beheer het netwerk van een kleine operator en flash regelmatig goedkope modules om als HP te werken. De taak is standaard: een image van een merkmodule naar Chinese 1,25G WDM-modules schrijven, zodat de switch ze zonder gemopper accepteert. Donor is de J4859C, doelapparaat is de HP 2530-24G J9776A.
Wat op tafel ligt:
- switch HP 2530-24G J9776A
- modules OptiCin en Fiberstore, 1,25G WDM
- mini-USB-programmer NAG
- IC-prog onder Windows, ik lees en schrijf ermee
De dump wordt als 256 byte uitgelezen, maar de tweede helft komt byte voor byte overeen met de eerste:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedWat al geprobeerd is:
- module verwijderd en opnieuw geplaatst, contacten in de socket gereinigd, klem vervangen
- drie modules uit verschillende partijen getest, zelfde beeld
- USB-poort, kabel en machine gewisseld, niets veranderd
Ik heb de tweede pagina nodig, waar DDM en de service-bytes staan, en die zie ik gewoon niet. Is dit een beperking van IC-prog, een kromme programmerplaat, of gedragen de modules zelf zich zo?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 7
Hier zitten twee onafhankelijke fouten, en geen van beide zit in de modules.
Eerste: IC-prog zelf. Het heeft een lineair adresseringsmodel, kan niet van pagina wisselen en komt in principe niet bij A2. Wat je in de tweede helft van de dump ziet, is dezelfde A0, een tweede keer uitgelezen. Een foutmelding krijg je niet, want vanuit zijn eigen oogpunt gaat alles eerlijk.
Tweede: de plaat. Op deze mini-USB-programmer staat VccR (pin 15) vast op +5 V, terwijl hij volgens SFF-8431 vrij moet blijven, en voeding en aarde zijn zo bedraad dat een deel van de modules niet in de normale modus komt. Vandaar
No Acknowledge received- niet bij allemaal, maar bij de modules die deze bedrading niet lusten.Wat wel gewoon werkt:
i2cdump -y 3 0x50eni2cdump -y 3 0x51, er is een open Python-script dat beide pagina's leest en schrijft.Het criterium is simpel: zodra 0x51 begint te antwoorden, is de rest gewoon werken met het geheugen van de module, geen gevecht met het gereedschap meer.
Scheid software en hardware, anders zit je tot vanavond te gokken. Pak een willekeurige Linux-bak en kijk of de module überhaupt op het tweede adres antwoordt:
Vul je eigen busnummer in. Leest 0x50 wel en blijft 0x51 stil, dan gaat de vraag niet meer over waarmee je de dump bekijkt, maar over of er wel normale voeding bij de module komt. En zeg erbij wat diezelfde programmer geeft bij een gegarandeerd levende donor-J4859C: opent bij die ook de tweede pagina niet, dan hebben de goedkope modules er niets mee te maken en moet je in de combinatie software plus plaat graven.
De donor heb ik als eerste getest: een levende J4859C in dezelfde socket en dezelfde IC-prog geeft precies hetzelfde beeld - 256 byte, de tweede helft herhaalt de eerste. Dus het ligt niet aan de goedkope modules. Nog even gecontroleerd onder Linux via de adapter:
De originele tool geeft op dezelfde module
No Acknowledge received, terwijl IC-prog zwijgend een kopie van de eerste pagina toont en doet alsof alles in orde is. De doelmodules zijn OptiCin, de image haal ik net van deze J4859C.Over het schrijven zelf nog dit. In de 256-byte dump doen de eerste 128 byte ertoe, daarna komt de zone van de fabrikant, die je meestal helemaal niet hoeft aan te raken. Voor HP flashen we images van de J4858C en J4859C, voor WDM was een gewone LX-image een paar keer al genoeg: de switch accepteerde de module en keek niet naar de golflengte.
Maar lang niet alles laat zich schrijven. Op de 3Com 3CSFP91 en 3CSFP92, net als op gebrande Allied Telesis-modules, lukte schrijven helemaal niet: lezen gaat prima, maar schrijven wordt niet toegepast - WP zit op slot. Dus als na het wisselen van programmer A2 wel leesbaar is maar het schrijven stilletjes in het niets verdwijnt, zoek de oorzaak dan niet in de software.
Kleine kanttekening bij "daarna is het gewoon werken met het geheugen". Gewoon is het niet overal. Een deel van de modules is helemaal geen EEPROM: in de Medick SFP-10G-BX zit een microcontroller C8051F392 die A0/A2 emuleert en een wachtwoord kan eisen of op een challenge kan reageren. Van buiten ziet het eruit als normaal geheugen, precies tot het moment van schrijven. Het zwaarste geval dat ik ben tegengekomen is de interactieve EEPROM bij HP/Aruba met sleutels, daar kun je zonder kant-en-klare tool niets beginnen.
En als je zelf een adapter bouwt, verwissel de pinnen niet: TX_Disable is pin 3, Mod_Abs is pin 6, VeeR is pin 9. Bij kennissen bleek de helft van de "onleesbare" modules gewoon een scheef gemonteerde socket te zijn, geen vendorbeveiliging.
Van wat nu in gebruik is: SNR SFP Writer, de SFPTotal Plus-serie en zelfbouw op CH341 - meestal gewoon een plaat met sockets voor SFP, XFP, GBIC en QSFP, soms in een geprinte behuizing. Universele software bestaat niet, elke vendor heeft zijn eigen tool, images haal je uit firmwaredatabases en van gespecialiseerde forums.
Twee dingen die duurder zijn dan de hardware. Eerste: veel modules hebben een 4-byte wachtwoord, het grootste deel is allang gepubliceerd, maar mis je ernaast, dan heb je een baksteen van een niet-goedkope module. Tweede: voor je in het geheugen gaat zitten, controleer eerst of de module überhaupt leeft. Temperatuur, spanning, biasstroom en TX/RX uit A0h/A2h,
show interfaces diagnostics opticsop Junos ofdisplay interface transceiverop Huawei, daarna de klemmen, contacten en lenzen schoonmaken, daarna vervangen door een gegarandeerd werkende. Een deel van de "dode" modules komt daarna zonder enige firmware weer tot leven, en de belasting controleer je pas daarna via iperf3.Terugkoppeling van het resultaat. Plaat op CH341 gebouwd, onder Linux antwoordde 0x51 meteen, de tweede pagina is volledig leesbaar, geen enkele duplicaat van de eerste 128 byte. Image van de J4859C naar de OptiCin geflasht, de HP 2530-24G J9776A accepteerde de module zonder morren, DDM toont zinnige waarden, een etmaal onder belasting zonder fouten gedraaid.
IC-prog verwijderd, om niet meer in de verleiding te komen. De 3Com 3CSFP91 die er nog bij lag, laat zich inderdaad niet beschrijven: lezen gaat, schrijven wordt niet toegepast, dus het klopt allemaal met WP. Bedankt, vraag opgelost.