SFP EEPROM lezen en herschrijven via de Raspberry Pi I2C-bus in plaats van een programmer kopen
Ik heb thuis een plank vol uitgebouwde SFP's staan en zou graag hun EEPROM kunnen lezen, een module repareren waarvan de checksum verminkt is geraakt, en af en toe een module hercoderen voor een switch die kieskeurig is over vendor strings. Een commerciële programmer kopen voor een handvol modules per jaar heeft hier geen zin, dus probeer ik uit te zoeken hoever een zelfgebouwde rig daadwerkelijk komt.
Wat er op de bank staat:
- Raspberry Pi met de I2C-bus uitgebroken naar een SFP-cage die ik zelf bedraad heb
- een CH341A USB-programmer bordje over van een BIOS-klus
- een gemengde stapel 1G en 10G SFP/SFP+ modules, plus twee QSFP+ modules die ik ook graag zou bekijken
Lezen werkt in elk geval in de zin dat er iets antwoordt op de bus:
$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
$ i2cdump -y 1 0x50Wat ik tot nu toe gedaan heb:
- A0h met de hand gedumpt en de bytes vergeleken met de SFF-8472 veld-offsets, wat traag is en makkelijk fout gaat
- een paar bytes geschreven met de CH341A: ze landen, maar niets herberekent de checksums voor me, dus de module komt terug als garbage totdat ik ze zelf patch
- de QSFP+ modules ongemoeid gelaten, want de cage die ik gebouwd heb neemt alleen SFP
Dus hoe ziet de open tooling hiervoor er eigenlijk uit: is er iets dat de memory layout kent, de checksum-bytes na een write verifieert, en ook een QSFP+ slot kan aansturen? En waar houdt een zelfgebouwde rig op genoeg te zijn?
Comments 4
Voor gewoon SFP/SFP+ werk is de Pi genoeg. De module is gewoon twee I2C devices, precies wat jouw i2cdetect output laat zien op 0x50 en 0x51, en daarboven gebeurt er niets magisch. Wat je het byte-tellen bespaart is sfppi: het stuurt de I2C-bus van de Pi aan, decodeert de velden voor je, en het controleert CC_BASE en CC_EXT en biedt aan ze na een write te herstellen. Dat is precies de stap die de CH341A niet voor je doet. De CH341A is niet nutteloos, hij leest en schrijft prima, hij heeft alleen geen idee wat de bytes betekenen, dus elke checksum blijft jouw probleem.
Voor QSFP+ helpt jouw gesoldeerde cage niet. Het community-ontwerp waar mensen naar wijzen is Hubble, een open programmer met een QSFP slot naast de SFP, dus dat is de richting als je die twee modules wilt aanraken. Er is ook een kale Reveltronics build die gebruikt wordt om write-passwords op modules die writes ronduit weigeren te brute-forcen. Die heb ik zelf nooit nodig gehad, dus zie het als een verwijzing en test hem op hardware die je je kunt veroorloven te verliezen.
Dat komt overeen met wat ik hier zie. De tweede pagina is ook live, dus beide helften van het geheugen zijn er om te lezen:
Ik ga de bedrading van de cage netjes overdoen en probeer dan het checksum-pad op een module waar ik niet aan hecht, voordat ik iets aanraak dat ik wil behouden. QSFP+ blijft voorlopig geparkeerd, een tweede cage bouwen voor twee modules per jaar is moeilijk te rechtvaardigen, dus die blijven read-only tot ik beslis of Hubble de moeite waard is.
Om daar iets aan toe te voegen vanaf het andere eind van het prijsspectrum, want niet iedereen bouwt zijn eigen: de tools die je in dagelijks gebruik ziet zijn de SNR SFP Writer, de SFPTotal Plus serie, en diverse eenmalige apparaten gebouwd rond CH341-bordjes, dezelfde chip die je al op de bank hebt.
Wat de moeite waard is om te weten voordat je hier dieper induikt: niet elke module is een simpele EEPROM. Sommige hebben hun eigen microcontroller die het A0/A2-geheugen emuleert in plaats van een echte chip bloot te leggen, met een Medick SFP-10G-BX met een C8051F392 erin als voorbeeld dat steeds terugkomt. Die kunnen write-passwords of vendor challenges implementeren, en hoeveel je ook aan de bus peutert, ze worden er geen domme EEPROM van. Het vervelendste geval dat mensen aanhalen is de interactieve HP/Aruba EEPROM met keys.
Één praktische opmerking voor je eigen cage: zorg dat de pinout klopt, anders jaag je op spoken. TX_Disable is pin 3, Mod_Abs is pin 6, VeeR is pin 9. Mod_Abs bepaalt in het bijzonder of er überhaupt geloofd wordt dat er een module aanwezig is.
En de risicokant ervan, want die wordt zelden genoemd totdat iemand een dode module heeft. Veel modules willen een 4-byte password voordat ze een write accepteren. De meeste van die passwords circuleren publiekelijk en er is geen universele utility, dus je eindigt met een stapel vendor-specifieke tools en images getrokken uit firmware-databases of van de fabrikant. Doe daar iets verkeerd mee en je hebt een module gebrickt die meer kostte dan de programmer.
Bewijs dus, voordat je de EEPROM überhaupt aanraakt, dat de module echt kapot is: lees DDM-temperatuur, spanning, bias current en TX/RX power uit A0h/A2h, maak de latches, contacten en lenzen schoon, wissel een bekend goede module in, en load-test de link met iperf3. De helft van de modules die zogenaamd geherflasht moeten worden, hoeft gewoon alleen schoongemaakt te worden.
Als je liever betaalt dan soldeert: besef dat de commerciële boxen met hun eigen addertjes komen. De FS Box hercodeert prima, mensen kregen zo FS SFP-GE-BX modules werkend op een Intel X710 met autoselect, maar hij programmeert alleen FS-modules, en het insteken van een niet-FS module heeft gebruikers al weken-lange account-lockouts opgeleverd.