きれいにダンプできるSFP+にプログラマーがWRITE FAILを返す: EEPROMが死んでいるのか、それとも書き込みを塞ぐ何かがあるのか

読み出しはきれいで、書き込みは拒否され、そのあとも元のページはそのまま。それは寿命が尽きたEEPROMの普通の挙動ではない。セルが死んでいる場合は、読み返しがおかしくなったり、書き込みが半端に入ったりするもので、何も変わらないきれいな拒否にはならない。

しかもベンダー領域の外にある1バイトすら弾かれたということは、チップ上の特定の領域が悪いのではなく、そのパーツが書き込みをまるごと拒否しているということ。何か結論を出す前に押さえておく価値のある点が2つある。1つ目は、実際にそのモジュールを作ったのは誰かということ。トレイに貼ってあったラベルではなく、すでにダンプしたページの中のベンダー文字列を見ること。2つ目は、電源が入った直後、バス上の他の誰かがそのモジュールと話す前に書き込みを撃てば通るかどうか。答えによってありそうな説明は変わってくるし、そのうちの一つは故障ですらない。

それは故障というよりパスワード保護のように見える。SFF-8472は、診断機能付きのモジュールが書き込みを受け付ける前に4バイトのパスワードを要求できることを許容している。何も送らないか、間違ったものを送ると、モジュールは読み出しは全開のままエラーで書き込みに応じる。これはまさにそちらのWRITE FAILとページが変わらず戻ってくる状況そのもの。これはそのパーツの機能であって、壊れかけている兆候ではない。

そちらのベンチにとっての意味は、これを知っているプログラマーならメーカーやホストのパスワードを入力させてくれるということで、出来の良いものだと未知のパスワードをブルートフォースし、書き込み後にチェックサムまで再計算してくれる。CH341系の装置にはチェックサムの自動化が一切ないので、パスワードを突破したあともチェックサムは自分で直す必要がある。そうしないと、見た目は正しいのにホストからは相変わらず拒否されるモジュールが出来上がることになる。

いつもの断り書きだが、自分がこれに当たったのは数個のモジュールだけで、そこではパスワードのルートがうまくいった。何かを見限る前に、手元のパーツでも試してみること。

関連する話として、Huawei S5731とS6730向けのホスト、それに古いHP 6120XG向けにモジュールを再コード化した経験から。弱点がモジュールではなくケージやブレイクアウト側にあるときは、モジュールのピン4と7、つまりI2CのSDAとSCLに直接はんだ付けして、ケージを完全に無視した状態でEEPROMを駆動するという手を使う人たちがいる。見た目は汚いし、失っても構わないパーツでしかやらないが、接触関連の問題をまるごと排除できる。

こちらでその処理をしたパーツは、Finisar FTLX8571D3BCVとFTLX8574D3BCV、IntelのSFP+ LRとSRモジュール、SNR-SFP+W73-3とSNR-SFP+W37-3、それにHP J9150A。

そちらの場合、電源の入れ直しをまたいでも読み出しはすでに盤石なので、接触は問題ではない。まずパスワードの線を追うこと。