IC-progでSFPのダンプが256バイト取れるが後半が前半のコピーでA2ページが読めない(HP 2530-24G)
小規模プロバイダのネットワークを運用していて、安い中華モジュールをHP用に定期的に書き換えています。よくある作業で、中国製1.25G WDMモジュールに純正イメージを書き込んで、スイッチに文句を言わせず認識させたいだけです。ドナーはJ4859C、書き込み対象はHP 2530-24G J9776Aです。
手元にあるもの:
- スイッチ HP 2530-24G J9776A
- OptiCinとFiberstoreのモジュール、1.25G WDM
- ミニUSBプログラマ NAG
- Windows用のIC-prog、読み書きに使用
ダンプは256バイト取得できますが、後半は前半とバイト単位で完全に一致します:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedすでに試したこと:
- モジュールの挿し直し、ソケット接点の清掃、ラッチの交換
- 異なるロットのモジュールを3個試すも結果は同じ
- USBポート、ケーブル、PCを変更しても変化なし
必要なのはDDMや管理用バイトがある2ページ目ですが、それがまったく見えません。これは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
ここには互いに無関係な問題が2つあり、どちらもモジュール側の話ではありません。
1つ目はIC-progそのものです。アドレッシングがリニアモデルで、ページの切り替えができないためA2には原理的に届きません。ダンプの後半に見えているのは、2回読まれた同じA0です。エラーは出ません、IC-progの視点では何もおかしいことをしていないからです。
2つ目は基板です。このミニUSBプログラマではVccR(15番ピン)が+5Vに直結されています。SFF-8431ではオープンのままにしておくべきピンです。さらに電源とグランドの引き回しのせいで、モジュールの一部が正常なモードに入れません。
No Acknowledge receivedが出るのはこのせいで、全部のモジュールではなく、この配線と相性が悪いものだけに出ます。問題なく動くもの:
i2cdump -y 3 0x50とi2cdump -y 3 0x51。両ページを読み書きするオープンなPythonスクリプトもあります。基準はシンプルで、0x51が応答し始めればあとはツールとの格闘ではなく、普通のモジュールメモリ操作になります。
ソフトとハードを切り分けないと、いつまでも当てずっぽうになります。手近なLinuxで、モジュールが2つ目のアドレスにそもそも応答するか見てください:
バス番号は自分の環境に合わせてください。0x50は読めるのに0x51が無応答なら、問題はダンプを何で見ているかではなく、モジュールにまともな電源が来ているかどうかです。あと、同じプログラマで間違いなく生きているドナーのJ4859Cが何を返すか教えてください。それも2ページ目が開かないなら、安いモジュールは無関係で、ソフトと基板の組み合わせを疑うべきです。
まずドナーで確認しました。同じソケット、同じIC-progで生きているJ4859Cを読んでも、まったく同じ256バイトで後半が前半の繰り返しになります。つまり安いモジュールのせいではありません。さらにLinuxでアダプタ経由でも確認しました:
同じモジュールに純正ユーティリティを使うと
No Acknowledge receivedが出るのに、IC-progは黙って1ページ目のコピーを表示して、何事もないふりをします。対象のモジュールはOptiCinで、イメージはまさにこのJ4859Cから取っています。書き込みについても補足します。256バイトのダンプで意味があるのは最初の128バイトまでで、その先はベンダー領域なので普通は触らなくて大丈夫です。HP向けにはJ4858CとJ4859Cのイメージを焼いていて、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プリントのケースに入っています。汎用ソフトは存在せず、ベンダーごとに専用ユーティリティがあり、イメージはファームウェアのデータベースや専門フォーラムから拾ってきます。
基板より重要なポイントが2つあります。1つ目、多くのモジュールには4バイトのパスワードが掛かっていて、大半はすでに公開されているものの、間違えると安くはないモジュールがただの文鎮になります。2つ目、メモリをいじる前にモジュールが生きているか確認してください。A0h/A2hから温度、電圧、バイアス電流、TX/RXを見て、Junosなら
show interfaces diagnostics optics、Huaweiならdisplay interface transceiver、それからラッチと接点とレンズの清掃、それでもだめなら確実に動くモジュールに交換します。これで「死んでいる」と思われたモジュールの一部はファームウェアいじりなしで復活し、負荷確認はそのあとiperf3で行います。結果を報告します。CH341で基板を組んだところ、Linux上で0x51がすぐに応答し、2ページ目が丸ごと読め、最初の128バイトの重複も出ませんでした。J4859CのイメージをOptiCinに焼いたら、HP 2530-24G J9776Aは黙ってモジュールを受け入れ、DDMもまともな値を示していて、丸1日負荷をかけてもエラーなしでした。
IC-progはもう誘惑されないようにアンインストールしました。手元に転がっていた3Com 3CSFP91は本当に書き込めず、読めるのに書き込みが反映されない、WPの話とも辻褄が合います。ありがとうございました、これで解決です。