IC-prog 读出的 256 字节 SFP dump 后一半是前一半的复制，A2 页读不出来（HP 2530-24G）
我维护着一个小运营商的网络，经常给便宜模块刷成 HP 能识别的样子。任务很常规：把原厂模块的镜像写进中国产的 1.25G WDM 模块里，让交换机不再报错地接受它们。样本机是 J4859C，目标设备是 HP 2530-24G J9776A。
手头的东西：
- 交换机 HP 2530-24G J9776A
- OptiCin 和 Fiberstore 的 1.25G WDM 模块
- mini-USB 编程器 NAG
- Windows 下的 IC-prog，用它读写
dump 出来的是 256 字节，但后一半跟前一半逐字节完全一样：
IC-prog, 0x00-0x7F: 已读取
IC-prog, 0x80-0xFF: 和前面完全相同的内容，逐字节一致
部分模块读取时: No Acknowledge received已经尝试过：
- 重新插拔模块，清洁了插座触点，换过卡扣
- 测试了三个不同批次的模块，现象一样
- 换过 USB 口、数据线和电脑，都没有变化
我需要的是第二页，里面有 DDM 和服务字节，但我根本看不到它。这是 IC-prog 的限制，还是编程器板子的设计问题，还是模块本身就是这个表现？
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
这里其实是两个互相独立的问题，而且都不在模块身上。
第一个问题是 IC-prog 本身。它用的是线性地址模型，不会切换页面，从原理上就够不到 A2。你在 dump 后一半看到的，其实就是第二次读到的同一个 A0 页面。它不会报错，因为从它的角度看，这一切都是正常的。
第二个问题在板子上。这个 mini-USB 编程器把 VccR（第 15 脚）直接接到了 +5V，而按照 SFF-8431 这一脚应该是悬空的，加上电源和地的走线方式，导致部分模块进不了正常工作模式。这就是
No Acknowledge received的来源——不是所有模块都会这样，只有对这种走线比较敏感的模块才会出问题。能正常工作的方案：
i2cdump -y 3 0x50和i2cdump -y 3 0x51，网上有一个开源的 Python 脚本可以同时读写两个页面。判断标准很简单：只要 0x51 开始有响应了，接下来就是对模块内存的常规操作，而不是在跟工具较劲。
先把软件和硬件分开，不然你能猜到晚上。找一台随便什么 Linux，看看模块在第二个地址上到底有没有反应：
总线号换成你自己的。如果 0x50 能读出来，0x51 没反应，那问题就已经不是你用什么工具看 dump 了，而是模块有没有拿到正常的供电。另外说一下，用同一个编程器读一个确认正常的原厂 J4859C 会得到什么：如果它的第二页也打不开，那便宜模块就跟这事没关系了，得从软件加板子这个组合本身查起。
第一件事就是测了原厂样本：用同一个插座、同一个 IC-prog 读一个正常的 J4859C，得到的现象一模一样——256 字节，后一半重复前一半。所以问题不在便宜模块上。又在 Linux 下通过转接头测了一次：
原厂工具在同一个模块上给出的是
No Acknowledge received，而 IC-prog 却悄悄显示第一页的复制内容，装作一切正常。目标模块是 OptiCin，镜像正是从这个 J4859C 上取的。关于写入这件事再补充一下。在 256 字节的 dump 里，有意义的是前 128 字节，后面是厂商保留区，通常完全不用动它。给 HP 刷模块时我们用的是 J4859C 和 J4858C 的镜像，对于 WDM 有时候一个普通的 LX 镜像就够用了：交换机只认模块，不看波长。
但不是所有模块都能写进去。3Com 3CSFP91 和 3CSFP92，还有贴牌的 Allied Telesis，完全写不进去：读取正常，写入却不生效——WP 被锁死了。所以如果换了编程器之后 A2 能读了，但写入悄悄没有任何效果，别再从软件上找原因了。
关于「接下来就是常规内存操作」这句话我要补充一句保留意见。「常规」不是在哪里都成立的。有一部分模块根本不是 EEPROM：Medick SFP-10G-BX 里用的是一颗单片机 C8051F392，它模拟出 A0/A2 的行为，还能要求密码或者响应挑战应答。从外面看和正常内存一模一样，直到你真的去写它才会露馅。我遇到过最麻烦的案例，是 HP/Aruba 上那种带密钥的交互式 EEPROM，没有现成工具的话基本无从下手。
另外如果你自己搭转接器，别接错引脚：TX_Disable 是第 3 脚，Mod_Abs 是第 6 脚，VeeR 是第 9 脚。我认识的人里，有一半所谓「读不出来」的模块，其实是插座接错了，跟厂商的保护措施没关系。
现在大家在用的工具：SNR SFP Writer、SFPTotal Plus 系列，还有基于 CH341 的自制板子——一般就是一块带 SFP、XFP、GBIC 和 QSFP 插座的板子，有时候还带个 3D 打印的外壳。没有通用软件，每个厂商都要用各自的工具，镜像从固件库和相关论坛上找。
有两点比硬件本身更值得重视。第一，很多模块带一个 4 字节密码，绝大部分早就被公开了，但如果你猜错，一个不便宜的模块就可能变砖。第二，在动内存之前，先确认模块本身是活的。看 A0h/A2h 里的温度、电压、偏置电流和 TX/RX，Junos 上用
show interfaces diagnostics optics，华为上用display interface transceiver，然后清洁卡扣、触点和镜片，再换一个确认能用的对比测试。不少「已死」的模块经过这一套处理就活过来了，压根不用刷任何固件，负载测试再用 iperf3 去验证。汇报一下最终结果。自己搭了一块 CH341 板子，Linux 下 0x51 立刻就有响应了，第二页能完整读出来，没有前 128 字节的重复。把 J4859C 的镜像写进了 OptiCin，HP 2530-24G J9776A 悄无声息地接受了这个模块，DDM 显示的数值也正常，带负载跑了一整天没有任何错误。
IC-prog 已经卸载了，免得再动歪脑筋。旁边那个 3Com 3CSFP91 确实写不进去：能读，写入不生效，WP 那个说法确实对得上。谢谢，问题解决了。