CodingBox Documentation

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 typeMemory blockPassword offset
SFP / SFP+A2h (I²C address 0x51)0x7B–0x7E
QSFP / XFPA0h0x7B

Commonly cited passwords

PasswordNotes
00 00 10 11MSA default — the first thing to try
00 00 00 00, FF FF FF FFfrequently seen defaults
9B B0 3D FAseen on a number of modules
4F 43 50 00ASCII "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

  1. Read the module; it is saved automatically to the code database

and a backup is taken before any write.

  1. Set the table address, password address and password value in

Protected memory & passwords — known passwords from the database are applied automatically.

  1. Edit the vendor, part number and other identity fields in the

EEPROM editor. CC_BASE and CC_EXT are recalculated for you.

  1. 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