Programmer geeft WRITE FAIL op een SFP+ die schoon dumpt: dode EEPROM of iets dat writes blokkeert?
De meeste maanden hercoderen we een kleine batch modules voor hosts van klanten, niets exotisch: de originele pagina lezen, de vendorstring schrijven die de host wil, de module in de switch stoppen en verdergaan. Eén module uit de huidige batch weigert elke write terwijl hij perfect terugleest, en voordat ik hem wegdoe wil ik weten of er nog iets te proberen valt.
Werkbank:
- CH341-klasse USB-programmer met een SFP-breakoutboard
- SFP+-module, diagnostics capable, leest goed koud en na een power cycle
- dezelfde opstelling schreef een uur eerder nog drie andere modules uit dezelfde tray
Wat de tool print zodra ik op write druk:
WRITE FAILMeteen daarna teruglezen geeft me byte voor byte de originele pagina terug, dus er is helemaal niets weggeschreven, ook niet gedeeltelijk.
Wat ik geprobeerd heb:
- de module opnieuw ingestoken en het breakoutboard verwisseld voor een reserve
- één enkele byte geschreven in een gebied dat me niet uitmaakt in plaats van de volledige pagina, zelfde resultaat
- bevestigd dat de read stabiel is over meerdere power cycles, dus de bedrading is niet marginaal
Is een module die schoon leest maar nooit een write accepteert simpelweg versleten, of zit er in de module zelf iets dat writes met opzet kan weigeren?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Leest schoon, writes geweigerd, originele pagina daarna intact. Zo gedraagt een versleten EEPROM zich normaal niet. Dode cellen geven je een slechte terugleesuitkomst of een pagina die half geschreven is, geen nette weigering met alles ongemoeid.
En aangezien zelfs die ene byte buiten het vendorgebied terugstuiterde, is dit geen slecht stukje op de chip, het is het onderdeel dat writes en masse afwijst. Twee dingen de moeite waard om vast te pinnen voor je iets beslist. Eerst: wie de module echt gebouwd heeft, ga af op de vendorstring in de pagina die je al gedumpt hebt, niet op wat er toevallig op de tray stond. Ten tweede: of een write landt als je hem afvuurt op het moment dat de voeding aankomt, voordat iets anders op de bus met de module gesproken heeft. De waarschijnlijke verklaring verschilt afhankelijk van die antwoorden, en een ervan is helemaal geen defect.
Dat leest meer als wachtwoordbeveiliging dan als schade. SFF-8472 staat een diagnostics-capable module toe om een 4-byte-wachtwoord te vereisen voordat hij een write accepteert. Stuur niets, of stuur het verkeerde, en de module beantwoordt de write met een fout terwijl reads wijd open blijven, wat precies jouw WRITE FAIL is met de pagina die ongewijzigd terugkomt. Het is een functie van het onderdeel, geen symptoom van een stervende.
Wat dat voor jouw werkbank betekent: een programmer die hiervan weet laat je een fabrikants- of hostwachtwoord invoeren, en de betere exemplaren brute-forcen een onbekend wachtwoord en herberekenen na de write de checksums voor je. Een CH341-klasse opstelling heeft helemaal geen checksum-automatisering, dus zelfs nadat je langs het wachtwoord bent, moet je de checksums zelf herstellen, anders eindig je met een module waarvan de pagina er voor jou goed uitziet en die de host nog steeds weigert.
Gebruikelijke kanttekening: ik ben dit op een handvol modules tegengekomen en daar werkte de wachtwoordroute, dus probeer het op jouw eigen onderdeel voor je iets afschrijft.
Om daaraan toe te voegen: bij sommige vendors zijn de wachtwoorden niet echt geheim. Er circuleren gedeelde verzamelingen Ubiquiti-transceiverwachtwoorden met entries als 0x00001011 en platte strings zoals SFPX en QSFP, dus als de module uit dat ecosysteem komt, kost het je vijf minuten om de bekende te proberen voor je ook maar in de buurt van brute force komt.
En als je een tool wilt die de hele flow al kent in plaats van te vechten met een generieke programmer, is de UACC-SFP-WIZARD de goedkope optie waar mensen naar grijpen. Het is geen labinstrument, maar hij handelt de modulekant netjes af.
Verwant, uit het hercoderen van modules voor Huawei S5731- en S6730-hosts en een oude HP 6120XG. Als de cage of de breakout de zwakke schakel is in plaats van de module, solderen mensen rechtstreeks op pin 4 en 7 van de module, dat zijn de I2C SDA- en SCL-lijnen, en sturen ze de EEPROM aan met de cage volledig buiten beeld. Lelijk, en je doet het alleen bij onderdelen die je bereid bent te verliezen, maar het haalt een hele klasse contactproblemen weg.
Onderdelen die hier op die manier behandeld zijn: Finisar FTLX8571D3BCV en FTLX8574D3BCV, Intel SFP+ LR- en SR-modules, SNR-SFP+W73-3 en SNR-SFP+W37-3, plus een HP J9150A.
In jouw geval is de read al rotsvast over power cycles heen, dus contact is niet jouw probleem. Jaag eerst de wachtwoordhoek na.
Wachtwoord is het waarschijnlijke antwoord, maar laat het niet bij "typ het wachtwoord in en je bent klaar", want twee dingen bijten mensen meteen daarna.
Ten eerste, bij sommige onderdelen moet de invoer opnieuw gebeuren nadat de module van stroom is ontkoppeld, dus een script dat meerdere pagina's na elkaar schrijft moet voorbereid zijn om het opnieuw in te voeren in plaats van aan te nemen dat één unlock de hele sessie dekt.
Ten tweede, de checksums. Met een CH341-klasse programmer reken je die met de hand opnieuw uit. Laat je ze verouderd, dan leest de module nog steeds prima, meldt jouw tool succes, en weigert de host de module toch stilletjes, waarna iedereen weer de hardware de schuld gaat geven. Lees de pagina terug en verifieer de sommen voordat die module in een klantswitch gaat.