EEPROM recoding: passwords & mechanics

The key insight from years of engineering discussion: transceiver compatibility is not firmware — it is identification strings in EEPROM, read over I²C. A switch rejects a module simply because it does not recognise the vendor string. That single fact explains the common practice of "coding everything as Cisco — it works almost everywhere" and the entire market of coding tools.

Where the passwords live

Writing to protected areas of module memory requires a 4-byte password entered at a fixed address before the write:

Commonly cited passwords

Some vendors' QSFP-DD modules ship with their own fixed defaults, and a few microprocessor-based modules use a variable password that changes — a trap for anyone attempting brute force.

Why brute force is not the answer

A manufacturer-level password guarding the whole memory map takes on the order of 100+ days to brute-force; even a host-level ASCII password takes up to about three days. The practical route is a database of known codes and passwords captured from original modules — which is where the real value of a coding tool lies, not in the I²C hardware (which is simple).

Pitfalls of do-it-yourself programmers

• Cheap CH341A programmers do not compute the SFP checksum. Writing an image without a valid CC_BASE/CC_EXT produces a module the switch will reject. You need a tool that recalculates checksums automatically.
• Some switches only write to address 0x50, so the password at 0x51 cannot be reached from the switch itself — a proper programmer board is needed.
• The EEPROM write-protect pin — some factories tie WP to Vcc so the module is locked against writing in the field.

Cases from the field

• Modules coded as one vendor would not autonegotiate on a switch of another; recoded to the switch's own vendor string, they came up immediately.
• Some optics vendors ship uncoded modules by design, expecting the buyer to code them for the target platform.
• DWDM modules are tuned to wavelength through the same management interface used for coding.

Doing it in CodingBox

1. Read the module; it is saved automatically to the code database and a backup is taken before any write.
2. Set the table address, password address and password value in Protected memory & passwords — known passwords from the database are applied automatically.
3. Edit the vendor, part number and other identity fields in the EEPROM editor. CC_BASE and CC_EXT are recalculated for you.
4. Write the selected pages, then read back to verify. Check the module on the switch with the commands in Verifying optics.

Code modules only for interoperability you are entitled to, and follow your organisation's and vendors' policies.

The rules behind a clean recode — field formats, which bits to set and which sums to fix — are in Vendor fields, Compliance codes and Checksums.

What the factory does at the same step, and which areas hold calibration a careless write can destroy: Manufacturing & testing, Controller & firmware.

Which byte holds what before you edit: SFF-8472 A0h map, SFF-8636 upper page map, CMIS upper pages map, XFP map.

Target part numbers and their grammar per vendor: OEM part numbers; what each platform class checks after the write: How each NOS validates a module.