IC-prog dumps 256 bytes off an SFP, but the second half is a copy of the first, page A2 doesn't read (HP 2530-24G)
I run a small ISP's network and regularly reflash cheap modules for HP. Usual task: flash the vendor module's image into cheap Chinese 1.25G WDM modules so the switch accepts them without complaint. Donor is a J4859C, target hardware is an HP 2530-24G J9776A.
What's on the bench:
- HP 2530-24G J9776A switch
- OptiCin and Fiberstore modules, 1.25G WDM
- mini-USB NAG programmer
- IC-prog on Windows, reading and writing through it
The dump comes out as 256 bytes, but the second half matches the first byte for byte:
IC-prog, 0x00-0x7F: read
IC-prog, 0x80-0xFF: the exact same block, byte for byte
on some modules while reading: No Acknowledge receivedWhat I've already tried:
- reseated the module, cleaned the socket contacts, replaced the latch
- ran three modules from different batches, same picture
- changed the USB port, the cable, and the machine, nothing changed
I need the second page, with DDM and the housekeeping bytes, and I simply don't see it. Is this a limitation of IC-prog, a flawed programmer board, or is that just how the modules themselves behave?
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 7
There are two independent problems here, and neither is in the modules.
The first is IC-prog itself. It has a linear addressing model, it can't switch pages and simply can't reach A2. What you're seeing in the second half of the dump is A0 read a second time. It won't show an error because from its point of view everything's fine.
The second is the board. On this mini-USB programmer, VccR (pin 15) is tied to +5 V, even though per SFF-8431 it should stay unconnected, and on top of that power and ground are wired so that some modules never enter normal mode. That's where the
No Acknowledge receivedcomes from - not on every module, but on ones that don't like this wiring.What works fine:
i2cdump -y 3 0x50andi2cdump -y 3 0x51, there's an open-source Python script that reads and writes both pages.Simple criterion: as soon as 0x51 starts responding, from there it's ordinary work with the module's memory, not a fight with the tool.
Separate the software from the hardware, otherwise you'll be guessing all evening. Grab any Linux box and check whether the module answers on the second address at all:
Use your own bus number. If 0x50 reads but 0x51 is silent - the question isn't what you're using to view the dump anymore, it's whether proper power reaches the module. And tell us what the same programmer gets off a known-good donor J4859C: if its second page won't open either, cheap modules have nothing to do with it, dig into the software-plus-board combination.
Ran the donor first thing: a live J4859C in the same socket and the same IC-prog gives exactly the same picture - 256 bytes, second half repeats the first. So it's not about the cheap modules. Also checked under Linux through the adapter:
The vendor's own utility on the same module returns
No Acknowledge received, while IC-prog silently shows a copy of the first page and pretends everything's fine. Target modules are OptiCin, I'm pulling the image from that same J4859C.I'll add something about the write itself. In a 256-byte dump only the first 128 bytes matter, beyond that is the manufacturer's zone, usually fine to leave untouched. For HP we flash J4858C and J4859C images, and for WDM a plain LX image was enough a couple of times: the switch accepted the module and didn't check the wavelength.
But far from everything can be written. On 3Com 3CSFP91 and 3CSFP92, as well as branded Allied Telesis units, the write didn't go through at all: it reads fine, but the write doesn't apply - WP is locked. So if after switching programmers A2 reads but the write quietly goes nowhere, don't look for the cause in the software.
I'll qualify "from there it's ordinary work with memory." It's not ordinary everywhere. Some modules aren't EEPROM at all: the Medick SFP-10G-BX has a C8051F392 microcontroller that emulates A0/A2 and can demand a password or respond to a challenge. From outside it looks like ordinary memory right up until you try to write. The hardest case I've run into is the interactive EEPROM on HP/Aruba with keys, there's nothing to do there without a ready-made utility.
And if you're building the adapter yourself, don't mix up the pins: TX_Disable is pin 3, Mod_Abs is pin 6, VeeR is pin 9. Half the "unreadable" modules people I know ran into turned out to be a badly built socket, not vendor protection.
Of what's in use now: SNR SFP Writer, the SFPTotal Plus line, and CH341-based homebrews - usually just a board with sockets for SFP, XFP, GBIC, and QSFP, sometimes in a 3D-printed case. There's no universal software, each vendor needs its own utility, images get pulled from firmware databases and specialized forums.
Two things that matter more than the hardware. First: many modules have a 4-byte password, most of them have long been published, but get it wrong and you'll end up with a brick out of an expensive module. Second: before touching the memory, make sure the module is actually alive. Temperature, voltage, bias current, and TX/RX from A0h/A2h,
show interfaces diagnostics opticson Junos ordisplay interface transceiveron Huawei, then clean the latches, contacts, and lenses, then swap in a known-good one. Some "dead" modules come back to life after that with no flashing at all, and only after that do you check load through iperf3.Reporting back on the outcome. Built a CH341-based board, under Linux 0x51 answered right away, the second page reads in full, no duplicates of the first 128 bytes. Flashed the J4859C image into the OptiCin, the HP 2530-24G J9776A accepted the module without complaint, DDM shows sensible values, ran a full day under load with no errors.
Uninstalled IC-prog so I'm not tempted again. The 3Com 3CSFP91 that was lying around indeed doesn't write: reads fine, write doesn't apply, so the WP theory checks out. Thanks, question closed.