Welke EEPROM-checksums moet je herberekenen na het aanpassen van vendor name en PN in een SFP-image

Jouw programmer doet wat CH341-gebaseerde tools normaal doen, namelijk niets. Ze schrijven de bytes die je ze geeft en raken de checksum-velden nooit aan. Vendor-programmers herberekenen bij het schrijven, en daarom lopen mensen die alleen dat soort tools gebruiken hier nooit tegenaan en zijn ze ervan overtuigd dat het hele onderwerp verzonnen is.

Twee dingen zijn het uitzoeken waard voordat je zelf tooling gaat schrijven. Ten eerste: wat heeft de image na het schrijven teruggelezen, dezelfde tool die geschreven heeft, of iets onafhankelijks? Een reader die je zijn eigen cache voorschotelt, laat je gerust een byte zien die nooit in de chip is beland. Ten tweede: heb je zelf de sum over bytes 0 tot en met 62 van de bewerkte image uitgerekend en vergeleken met byte 63, of vergelijk je byte 63 alleen met de originele dump? Ongewijzigd en correct zijn niet dezelfde test, en jouw notities laten alleen de eerste zien.

Ook de moeite waard om te noemen: welke host wijst hem af. Sommige lezen de identity-velden uit en verifiëren niets, andere valideren streng en laten de module vallen zodra een sum niet klopt. Dezelfde image, ander oordeel.

Het zijn er twee, en het zijn simpele 8-bit sums, nergens komt een CRC aan te pas.

• CC_BASE staat op byte 63 en is de laagste 8 bits van de som van bytes 0 tot en met 62
• CC_EXT staat op byte 95 en dekt bytes 64 tot en met 94

Vendor name en vendor PN staan allebei in het base-gebied, dus jouw edit maakte CC_BASE ongeldig terwijl CC_EXT terecht correct bleef. Wijzigingen aan serienummer en datumcode raken juist het extended-bereik, en dan is het byte 95 dat verouderd raakt. Een van beide herberekenen is twee regels over de buffer: de range optellen, maskeren met 0xFF, opslaan in de sum-byte.

Als je het liever niet met de hand doet: er is tooling. py-sfp-eeprom bouwt en valideert EEPROM-images vanuit Python (python3 -m sfp_eeprom), en sfppi draait op een Raspberry Pi, controleert de sums en biedt aan ze te herstellen. Beide zijn een betere gewoonte dan hex editor plus hoofdrekenen, want het faalt stil - de module geeft bij het uitlezen precies terug wat je geschreven hebt en alleen de host klaagt.

De twee MSA-sums kloppend krijgen is noodzakelijk, en afhankelijk van in welke poort je de module steekt, niet voldoende.

Cisco is het bekende voorbeeld: de identity-check is niet alleen de strings. Iemand heeft jaren geleden uitgevogeld dat de waarde die een Cisco-gecodeerde module draagt, te reproduceren is met niets exotischer dan xxd -r -p | md5sum, gevoed met de vendor code byte en daarna de name bytes. In die dumps horen code en naam bij elkaar - Finisar zit achter 02, Methode achter 0E. Laat die twee niet overeenkomen en een Catalyst 2960X spuugt de module er weer uit, unlock commands of niet.

Dat is meestal waarom een dump die van een werkende module is gekopieerd, stopt met werken zodra iemand er een andere vendor string in heeft geplakt. De sums kloppen, de identity is niet meer intern consistent.

Kleine correctie op het "fix de twee sums en je bent klaar"-frame: dat klopt voor de MSA-velden, niet voor wat elke vendor als een geldige image beschouwt.

HP is het blijvende tegenvoorbeeld. Bewerk het serienummer in een J4858B-image, bytes 68 tot en met 83, en ook bytes 124 tot en met 127 van A0 veranderen mee - een vendor-checksum die voorbij de MSA CC_BASE- en CC_EXT-bytes zit. Dat is destijds uitgebreid besproken en niemand heeft ooit het algoritme gepubliceerd; mensen bevestigden dat de bytes ertoe doen en daar eindigde de thread. Hetzelfde verhaal is gemeld rond J4859C en J9150A. Later stapten HP- en Aruba-apparatuur over op een challenge-response schema (HPIDv2), dat je in een EEPROM helemaal niet kunt vervalsen.

Zoek dus, voordat je in tooling investeert, uit wat de doelhost valideert: twee additieve sums voor een gewone host, een intern consistente identity voor Catalyst, en bij sommige HP-onderdelen een ongedocumenteerd veld dat je niet gaat reproduceren.