Which EEPROM checksums must be recalculated after editing vendor name and PN in an SFP image

Asked 16 days ago Active 15 days ago Viewed 101 Original language: English

Bench work: re-coding a small batch of SFP+ modules so they carry the vendor string and part number the customer's kit expects. The edit itself is trivial in a hex editor, the write goes through, the read back matches byte for byte what I wrote - and the host still throws the module out.

generic SFP+ modules, A0 page edited by hand
CH341 based programmer with the tool that came with it
edited fields: vendor name and vendor part number, nothing else touched
an untouched dump written back to the same module works fine, so the write path itself is not the problem

What I compared after the edit:

edited fields   : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT  : identical to the original image
host            : rejects the module, checksum error

So the sum bytes clearly did not move when the payload did. Before I go and write my own tooling for this: which byte ranges do those two sums actually cover, are they plain additive sums or something CRC shaped, and is there a maintained utility that recalculates them so I am not doing arithmetic by hand on every module?

Also available in: English العربية Deutsch Español Français हिन्दी Bahasa Indonesia Italiano 日本語 한국어 Nederlands Polski Português Русский Türkçe Tiếng Việt 简体中文

linkadmin79 KR

Comments 4

Your programmer is doing what CH341 based tools normally do, which is nothing. They write the bytes you hand them and never touch the checksum fields. Vendor programmers recalculate on write, which is why people who only ever use those never hit this and are convinced the whole topic is imaginary.

Two things worth pinning down before you write any tooling. First, what read the image back after the write - the same tool that wrote it, or something independent? A reader serving you its own cache will happily show a byte that never landed in the chip. Second, did you work out the sum over bytes 0 to 62 of the edited image yourself and compare that with byte 63, or are you only comparing byte 63 against the original dump? Unchanged and correct are not the same test, and your notes only show the first one.

Also worth naming the host that rejects it. Some read the identity fields and verify nothing, others validate strictly and drop the module the moment a sum is off. Same image, different verdict.

waverunner21IN 16 days ago Original (English)

There are two of them and they are dumb 8-bit sums, no CRC involved anywhere.

CC_BASE sits at byte 63 and is the low 8 bits of the sum of bytes 0 to 62
CC_EXT sits at byte 95 and covers bytes 64 to 94

Vendor name and vendor PN both live in the base area, so your edit invalidated CC_BASE while CC_EXT stayed legitimately correct. Serial numbber and date code edits hit the extended range instead, and then it is byte 95 that goes stale. Recomputing either one is two lines over the buffer: sum the range, mask with 0xFF, store into the sum byte.

If you would rather not hand roll it, there is tooling. py-sfp-eeprom builds and validates EEPROM images from Python (python3 -m sfp_eeprom), and sfppi runs on a Raspberry Pi, checks the sums and offers to fix them. Either is a better habit than hex editor plus mental arithmetic, because the failure mode is silent - the module reads back exactly as you wrote it and only the host ever complains.

edgenode14KR 16 days ago Original (English)

Getting the two MSA sums right is necessary and, depending on whose port you are plugging into, not sufficient.

Cisco is the well worn example: the identity check is not just the strings. Somebody worked out years ago that the value a Cisco coded module carries can be reproduced with nothing more exotic than xxd -r -p | md5sum, fed the vendor code byte and then the name bytes. In those dumps code and name are tied to one another - Finisar sits behind 02, Methode behind 0E. Let the two disagree and a Catalyst 2960X spits the module out again, unlock commands or no unlock commands.

That is usually why a dump copied off a working module stops working once someone has pasted a different vendor string into it. The sums are fine, the identity is no longer self consistent.

coaxengFR 15 days ago Original (English)

Small correction to the "fix the two sums and you are done" framing: that holds for the MSA fields, not for every vendor's idea of a valid image.

HP is the standing counterexample. Edit the serial number in a J4858B image, bytes 68 to 83, and bytes 124 to 127 of A0 change as well - a vendor checksum sitting past the MSA CC_BASE and CC_EXT bytes. That one was chewed over at length and nobody ever published the algorithm; people confirmed the bytes matter and the thread ended there. Same story reported around J4859C and J9150A. Later HP and Aruba gear moved to a challenge response scheme (HPIDv2), which you cannot forge in an EEPROM at all.

So before you invest in tooling, work out what the target host validates: two additive sums for a plain host, an internally consistent identity for Catalyst, and on some HP parts an undocumented field you are not going to reproduce.

coreadminDE 15 days ago Original (English)