Programmer leest SFP+ FTLX8571D3BCV-IT uit, maar antwoordt bij schrijven met No Acknowledge
Ik houd een kleine ruilvoorraad modules aan: de locaties liggen verspreid over de stad, en voor bijna elke vreemde switch moet een SFP herkodeerd worden. Bij gigabit-modules is het procedé al lang uitgekristalliseerd, maar bij een tiengigabit-exemplaar loop ik vast.
Wat er op tafel ligt:
- programmer met een cage voor SFP/SFP+, voeding 3,3 V
- Finisar FTLX8571D3BCV-IT en FTLX1471D3BCV-IT, beide lezen prima
- Cisco GLC-LH-SM uit oude voorraad
- HP J4858B en J4859C
Het uitlezen lukt stabiel en herhaalbaar, allebei de banken volledig. Schrijven lukt in geen enkel geval:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeWat ik al gecontroleerd heb:
- dezelfde bewerkingen op gewone gigabit-SFP's met dezelfde programmer lukken wel, dus de bekabeling en voeding leven nog;
- een tweede exemplaar van de FTLX8571D3BCV-IT gepakt, gedrag tot op de byte identiek;
- bij de GLC-LH-SM komt No Acknowledge meteen, nog voordat er geprobeerd wordt de vendorvelden aan te raken.
Het lijkt er dus niet aan dat ene exemplaar te liggen. Is dit hardwarematige schrijfbeveiliging in de module zelf, of zit er in SFP+ geen kale EEPROM meer en is gewoon schrijven via I2C er niet meer bij te komen? En apart ben ik benieuwd naar de HP J4858B/J4859C: schrijft iemand die met een gewone programmer, of is dat bij voorbaat een doodlopend spoor?
Comments 6
Hier lopen twee verschillende mechanismen door elkaar, en die verhelp je elk anders.
Het eerste is een gewone EEPROM met hardwarematige schrijfbeveiliging. De geheugenchip heeft een write-protect-pin, en zolang die hoog getrokken is, lukt lezen wel maar valt schrijven weg. De methode die mensen die dit grondig gedaan hebben aanraden: die pin tijdens het flashen naar aarde trekken. Bij een deel van de gigabit-modules is dat voldoende.
Het tweede is waar je bij het tiengigabit-exemplaar tegenaan loopt. In SFP+ zit de data vaak niet in een aparte EEPROM, maar achter de microcontroller van de module: die geeft zelf A0 en A2 vrij om te lezen en accepteert schrijven alleen via zijn eigen commandosequentie. Een standaardprogrammer kent die sequentie niet en krijgt bij elke poging No Acknowledge, ongeacht welk veld je probeert te raken. Daar valt niets te aarden.
Wat er in de praktijk wel bij helpt om de cage te omzeilen: met draden rechtstreeks op pin 4 en 7 van de module solderen, dus op de I2C-lijn, buiten de connector van de programmer om. Volgens de ervaringen schrijft daarna een deel van de modules die in de cage stil bleven. Het is een grove methode, er zijn rustige handen voor nodig, en de module leeft daarna op eigen risico.
HP is een apart verhaal. Standaardprogrammers pakken ze niet, daar is eigen verwerking voor nodig, en bij de J4858B/J4859C met gewone bekabeling zou ik geen succes verwachten. Als het doel gewoon is een werkende module in een vreemde switch te krijgen, is het goedkoper om HP niet te kwellen en in plaats daarvan een module met eerlijk geheugen te nemen en daar het vendor-image in zijn geheel op te zetten: van de 256 bytes van de dump zijn de eerste 128 relevant, de rest is reserve van de fabrikant.
Geen enkele vendor ondersteunt zo'n herkodering natuurlijk: met een omgeflashte module heb je bij support niets te zoeken.
Verduidelijk een paar dingen, anders wordt het gokwerk. Komt No Acknowledge al op het apparaatadres zelf, of pas na de eerste databyte? Dat is meestal te zien in het log van de programmer. En wat voor programmer heb je - een kant-en-klaar apparaat of een zelfbouw op eigen bekabeling? Daarvan hangt af wat er überhaupt te verwachten valt van 3,3 V op de cage.
Ook interessant is het gedrag bij het aansluiten van de voeding: is de fout hetzelfde meteen na het plaatsen van de module als nadat hij een paar minuten onder spanning heeft gestaan? En gedragen alle vier de types zich hetzelfde, of wijken Finisar en HP af: HP heeft meestal eigen oorzaken voor de weigering, die kun je beter meteen apart houden.
Ik meld de resultaten. Rechtstreeks op de I2C-lijn gesoldeerd, op pin 4 en 7, buiten de cage om. Finisar ging: de FTLX8571D3BCV-IT schreef weg en werd met terugleeswerk bevestigd, de FTLX1471D3BCV-IT ook. De GLC-LH-SM geeft geen No Acknowledge meer en schrijft gewoon normaal.
HP heeft zich niet gewonnen gegeven. De J4858B accepteert het schrijven formeel wel, maar na de aanpassing wordt de module door de switch geweigerd, de J4859C gedraagt zich net zo. Voor mij is de vraag dus voor de helft opgelost: Finisar en Cisco schrijf ik nu, HP leg ik opzij tot betere tijden.
Bij HP zit de val dieper dan schrijfbeveiliging, dus jouw resultaat is precies wat te verwachten was. Bij de J4858B verschuift bij het aanpassen van bytes 68-83, dus het serienummer, de checksum in bytes 124-127 mee, en daarna wordt de module geweigerd. Dat zijn niet de MSA-checksums CC_BASE en CC_EXT, die zijn geen probleem om te berekenen, maar een aparte vendorchecksum in de laatste vier bytes van A0. Het algoritme is publiek nooit ontrafeld, hoeveel er ook aan gepeuterd is.
De J9150A hoort bij hetzelfde verhaal. En in nieuwere modules zijn HP en Aruba helemaal van de statische checksum overgestapt naar een challenge-response-schema, HPIDv2, en daar is een programmer principieel nutteloos. Dus "schrijft wel, wordt niet geaccepteerd" is precies wat er uit moest komen.
Omdat jij een hele vloot hebt en niet één module, zeg ik iets over het gereedschap. Ik heb voor herkodering voor Huawei S5731 en S6730 en voor HP 6120XG de UACC-SFP-WIZARD van Ubiquiti ingezet: als goedkope programmer is hij prima bruikbaar. Alleen circuleren er over de Ubiquiti-modules zelf lijsten met wachtwoorden, items zoals 0x00001011, SFPX, QSFP, en zonder die gaat een deel van de modules niet open voor schrijven. Van de images gebruik ik zelf FTLX8571D3BCV en FTLX8574D3BCV, minder vaak SNR-SFP+W73-3 en W37-3.
Ik corrigeer de veralgemenisering hierboven, zodat niemand voortijdig naar de soldeerbout grijpt: niet in elke SFP+ zit het geheugen achter een microcontroller verstopt. Bij mij schreven een FTLX8574D3BCV en een paar SNR-SFP+W73-3 gewoon met een standaardprogrammer in de cage, zonder solderen. Dus eerst het specifieke exemplaar checken, en pas daarna de omweg induiken.
Het aarden van de write-protect-pin is trouwens ook geen universeel recept: bij een module met microcontroller levert dat niets op, daar komt de weigering niet uit het geheugen maar uit de firmware van de controller. Die handeling heeft alleen zin waar een eerlijke aparte EEPROM zit, en dan moet het op een spanningsloze module gebeuren, anders krijg je gemakkelijk een baksteen in plaats van een module.