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:
| Module type | Memory block | Password offset |
|---|---|---|
| SFP / SFP+ | A2h (I²C address 0x51) | 0x7B–0x7E |
| QSFP / XFP | A0h | 0x7B |
Commonly cited passwords
| Password | Notes |
|---|---|
00 00 10 11 | MSA default — the first thing to try |
00 00 00 00, FF FF FF FF | frequently seen defaults |
9B B0 3D FA | seen on a number of modules |
4F 43 50 00 | ASCII "OCP" |
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
- Read the module; it is saved automatically to the code database
and a backup is taken before any write.
- Set the table address, password address and password value in
Protected memory & passwords — known passwords from the database are applied automatically.
- Edit the vendor, part number and other identity fields in the
EEPROM editor. CC_BASE and CC_EXT are recalculated for you.
- 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.
Sources
- GitHub — hfuller/transceiver-notes: passwords, addresses, hardware
- Habr / Selectel — optics diagnostics and re-programming (in Russian)
- forum.nag.ru — CWDM programming and SFP images (in Russian)
- ServeTheHome — "Transceiver programmer" thread; Reveltronics forum on SFP passwords