What a Catalyst 2960X checks in an SFP dump: vendor code, name, and MD5, and why a copied dump fails
I run a provider's network with a mixed fleet of modules, so I regularly have to prep modules for specific switches. I want to finally understand the mechanics of the check instead of guessing at dumps.
What I'm working with:
- Cisco Catalyst 2960X-24PS-L, the pickiest one in the fleet
- QTECH QSW-3750-28TX-AC and D-Link DGS-3420, the same modules come up fine on these
- SNR-SFP+SR and SFP-10G-BX modules
In the dump of a module that the Catalyst accepts, at the start I see the vendor code byte followed by the name in ASCII:
0E 43 49 53 43 4F ...What I tried: took a dump from a module that comes up on the C2960X-24PS-L and rewrote only the vendor name from this dump into another module. On QTECH and D-Link everything then comes up, but the Catalyst won't accept that module, even though the patched bytes match the donor byte for byte.
So here's my question about how the check is built. What exactly does Cisco compute and from which bytes, where does the result live in the module, and why isn't a vendor name copied from a working dump enough? I need the logic, I'll figure out the rest myself.
Comments 6
The mechanics there are simple and have long been worked out. It's not a single field being checked, but a pair: the vendor code byte plus the vendor name bytes. An MD5 is taken over that sequence, and the result sits in the module itself; the switch computes the same thing and compares.
Reproducible with stock utilities, nothing special needed:
Plug in your own code and your own vendor name and you get the value that should be sitting in the module. Of the codes that actually show up in dumps: 02 is Finisar, 0E is Methode, 11 shows up regularly, but nobody's ever pinned down whose it is. If the code-name pair is consistent and the hash matches it, the module passes on the C2960X-24PS-L.
Following up on the above: show what's actually sitting in the target module. Which vendor code byte is left there, and what name sits next to it? Based on your description, you transferred the name but left the code or the hash itself from the original module, and then the pair no longer matches, and the Catalyst rejects it completely legitimately. Check all three things at once, not just the one field you can see in the switch output.
Checked it, matches your theory. In the donor it's 0E followed by CISCO, and in the target module I really did rewrite the name, but the vendor code stayed original, and so did the hash. Ran both combinations through xxd -r -p and md5sum: for the donor the value matches what's in the module, for my hand-assembled one it doesn't.
So the whole pair needs to be transferred together, not field by field. Now at least it's clear what to look at and check before putting a module into a port.
An important consequence that keeps getting forgotten: if the vendor code and name aren't consistent, the module won't pass on a Catalyst even when unsupported modules are allowed on the switch. That's exactly why other people's dumps work only some of the time - they were patched partially, and the check looks at the pair.
Hence a practical takeaway about scope: in a 256-byte dump only the first 128 bytes matter, beyond that is the manufacturer's zone. There's no need to drag the whole image along, but the first half needs to be transferred consistently, including fields you can't see by eye in the switch output.
By the way, a dump doesn't solve everything. The Medick SFP-10G-BX has a C8051F392 microcontroller instead of memory: it emulates A0 and A2 and can well hold a password or a vendor challenge. You could check the pair down to the byte there and it still simply won't be accepted from outside. Of live tools I use SNR SFP Writer and SFPTotal Plus, colleagues also have CH341-based homebrews.
A small correction, so people who come here later don't get confused. This MD5 has nothing to do with the MSA checksums: CC_BASE and CC_EXT from SFF-8472 are computed as a plain byte sum and are trivial to recompute. The vendor check sits on top of them with its own rules, and rejects the module at exactly the moment when the MSA sums are already fine - hence the feeling that the dump is correct but the module still isn't accepted.
Cisco, by the way, is far from the worst case here: the mechanics are at least understood and reproducible. The hardest are HP and Aruba, where the memory behaves interactively and requires keys - there dumps alone won't cut it anymore.