Programmer reads SFP+ FTLX8571D3BCV-IT fine but write returns No Acknowledge
I keep a small pool of shared modules: the nodes are scattered around the city, and I have to recode SFP modules for almost every switch that isn't mine. With gigabit modules the routine has been solid for a long time, but a 10G one just stopped me cold.
What's on the bench:
- a programmer with an SFP/SFP+ socket, 3.3 V supply
- Finisar FTLX8571D3BCV-IT and FTLX1471D3BCV-IT, both read fine
- a Cisco GLC-LH-SM from old stock
- HP J4858B and J4859C
Reading comes back stable and repeatable, both banks in full. Writing fails in every case:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeWhat I've already checked:
- the same operations on plain gigabit SFPs go through fine with the same programmer, so the wiring and power are alive;
- I grabbed a second FTLX8571D3BCV-IT, byte-for-byte the same behavior;
- on the GLC-LH-SM the No Acknowledge shows up immediately, even before touching the vendor fields.
So it's not about a specific unit. Is this a hardware write-protect in the module itself, or has SFP+ memory stopped being plain EEPROM, so a plain I2C write just can't reach it anymore? And separately, has anyone written to HP J4858B/J4859C with an ordinary programmer, or is that a dead end from the start?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 6
Two different mechanisms are mixed up here, and they're fixed differently.
The first is a plain EEPROM with hardware write protection. The memory chip has a write-protect pin, and while it's pulled up, reads go through but writes fail. What people who've done this a lot recommend is grounding that pin for the duration of flashing. On some gigabit modules that's enough.
The second is what you're hitting on the 10G one. In SFP+ the data often doesn't sit in a separate EEPROM but behind the module's own microcontroller: it serves A0 and A2 for reads itself and only accepts writes through its own command sequence. A stock programmer doesn't know that sequence and gets No Acknowledge on any attempt, no matter which field you're targeting. There's nothing to ground there.
What actually helps get around the socket: solder wires directly to pins 4 and 7 of the module, i.e. onto the I2C lines, bypassing the programmer's connector. By reports, this gets some modules writing that stayed silent in the socket. It's a crude method, needs steady hands, and after that the module's fate is on you.
HP is a different story altogether. Stock programmers don't handle them, they need their own handling, and I wouldn't expect success on J4858B/J4859C with ordinary wiring. If the goal is simply to get a working module in someone else's switch, it's cheaper not to fight HP and instead take a module with honest memory and flash the vendor image into it whole: out of a 256-byte dump only the first 128 bytes matter, the rest is manufacturer reserve.
No vendor, of course, supports this kind of recoding: with a reflashed module there's nothing to bring to support.
Clarify a couple of things, otherwise it's guesswork. Does No Acknowledge arrive at the device address itself, or already after the first data byte? That's usually visible in the programmer's log. And what kind of programmer do you have - an off-the-shelf device or a homebrew with its own wiring? That affects what you can even expect from 3.3 V on the socket.
Also curious about power-up behavior: is the failure the same right after inserting the module and after it's been powered for a couple of minutes? And do all four types behave the same, or do Finisar and HP differ - HP usually has its own reasons for failure, better to separate it from the rest right away.
Reporting back on results. I soldered directly onto the I2C lines at pins 4 and 7, bypassing the socket. The Finisars went through: the FTLX8571D3BCV-IT wrote and was confirmed by a readback, same with the FTLX1471D3BCV-IT. The GLC-LH-SM stopped throwing No Acknowledge and writes normally now.
HP still didn't give in. The J4858B formally accepts the write, but after the edit the switch rejects the module; the J4859C behaves the same way. So for me the question is half closed: I'm now writing Finisar and Cisco, HP is set aside until better times.
The trap with HP goes deeper than write protection, so your result was expected. On the J4858B, editing bytes 68-83, i.e. the serial number, changes the checksum in bytes 124-127, and after that the module gets rejected. That's not the MSA CC_BASE/CC_EXT checksums, which aren't a problem to compute, but a separate vendor checksum in the last four bytes of A0. Nobody's publicly cracked the algorithm no matter how much digging has been done.
The J9150A is the same story. And newer HP and Aruba modules have moved away from a static checksum entirely to a challenge-response scheme, HPIDv2, where a programmer is useless in principle. So "writes but isn't accepted" is exactly the result that was supposed to happen.
Since you've got a fleet, not one module, I'll mention a tool. For recoding for Huawei S5731 and S6730 and for HP 6120XG I've adapted the Ubiquiti UACC-SFP-WIZARD - as a cheap programmer it's quite capable. Just be aware that password lists circulate for Ubiquiti's own modules, entries like 0x00001011, SFPX, QSFP, and without them some modules won't open for writing. Of the images I use, FTLX8571D3BCV and FTLX8574D3BCV are in rotation, more rarely SNR-SFP+W73-3 and W37-3.
Let me correct the generalization above, so nobody grabs a soldering iron too early: not every SFP+ has its memory hidden behind a microcontroller. My FTLX8574D3BCV and a couple of SNR-SFP+W73-3 wrote fine with a plain programmer in the socket, no soldering at all. So it's worth checking the specific unit first before going around it.
Grounding the write-protect pin, by the way, is also not a universal recipe: on a module with a microcontroller it does nothing, since the failure there comes from the controller's firmware, not from memory. That operation only makes sense where there's an honest, separate EEPROM, and it needs to be done with the module unpowered, otherwise you can easily end up with a brick instead of a module.