プログラマがSFP+ FTLX8571D3BCV-ITを読み取れるが書き込みはNo Acknowledgeになる
小さなモジュールの融通用ストックを持っていて、拠点は街中に散らばっていて、他人のスイッチに合わせてほぼ毎回SFPを書き換える必要があります。ギガビットモジュールについてはやり方がとっくに確立していますが、10Gで詰まりました。
手元にあるもの:
- SFP/SFP+用ケージ付きプログラマ、電源3.3V
- Finisar FTLX8571D3BCV-ITとFTLX1471D3BCV-IT、どちらも読み取り可能
- 古い在庫のCisco GLC-LH-SM
- HP J4858BとJ4859C
読み取りは安定して再現よく取得できます、両バンクとも丸ごと。書き込みはどのパターンでも通りません:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledgeすでに確認したこと:
- 同じ操作を普通のギガビットSFPに対して同じプログラマで行うと通るので、配線と電源は生きている
- FTLX8571D3BCV-ITをもう一つ用意したが、挙動はバイト単位で同一
- GLC-LH-SMではベンダーフィールドに触る前の段階で即座にNo Acknowledgeが返ってくる
つまり特定の個体の問題ではなさそうです。これはモジュール自体のハードウェア書き込み保護なのか、それともSFP+ではメモリがもう単なるEEPROMではなくなっていて、普通のI2C書き込みでは到達できないのでしょうか? あと別件でHP J4858B/J4859Cについても気になります: 普通のプログラマで書き込めている人はいますか、それとも最初から行き止まりですか?
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
ここには別々の2つの仕組みが混ざっていて、対処法もそれぞれ違います。
1つ目 - 普通のEEPROMでハードウェア書き込み保護がかかっているケース。メモリチップにはwrite protectピンがあり、それがプルアップされている間は読み取りはできても書き込みは弾かれます。この手の作業を本格的にやっている人たちが勧めていた方法は、書き込みの間だけそのピンをグラウンドに落とすことです。ギガビットモジュールの一部ではこれで十分です。
2つ目 - あなたが10Gで直面しているのはこちらです。SFP+ではデータが独立したEEPROMではなく、モジュールのマイクロコントローラの背後にあることが多いです: A0とA2の読み取りはコントローラ自身が返し、書き込みは自前のコマンドシーケンスでしか受け付けません。標準的なプログラマはそのシーケンスを知らないので、どのフィールドを狙おうがNo Acknowledgeを受け取ることになります。そこにはグラウンドに落とすべきものすらありません。
ケージを回避するために実際に効くのは: モジュールの4番と7番のピン、つまりI2Cラインに直接ワイヤーをはんだ付けして、プログラマのコネクタを迂回することです。報告によると、これでケージの中では沈黙していたモジュールの一部が書き込めるようになるとのことです。手荒な方法なので手先の器用さが必要ですし、その後のモジュールの動作は自己責任になります。
HPは別の話です。標準的なプログラマでは扱えず、専用の処理が必要で、J4858B/J4859Cに普通の構成で成功するとは期待しない方がいいです。目的が単に他人のスイッチで動くモジュールを手に入れることなら、HPを無理に攻略するより、素直なメモリを積んだモジュールを買ってベンダーのイメージを丸ごと書き込む方が安上がりです: ダンプ256バイトのうち意味があるのは最初の128バイトで、残りはメーカーの予約領域です。
こうした書き換えをサポートするベンダーは当然どこにもありません: 書き換え済みのモジュールを持ってサポートに行っても話になりません。
いくつか確認させてください、でないと当てずっぽうになります。No Acknowledgeはデバイスアドレス自体で返ってきますか、それともデータの最初のバイトの後ですか? プログラマのログを見れば通常分かります。あと使っているプログラマは何ですか - 既製品ですか、それとも自作の回路ですか? それによってケージの3.3Vから何を期待できるかが変わります。
電源投入時の挙動も気になります: モジュールを装着した直後と、数分間通電させた後とで、失敗の様子は同じですか? あと4種類すべて同じ挙動ですか、それともFinisarとHPで違いますか: HPは大抵独自の失敗理由を持っているので、最初から切り分けておいた方がいいです。
結果を報告します。ケージを迂回して4番と7番のピンのI2Cラインに直接はんだ付けしました。Finisarはうまくいきました: FTLX8571D3BCV-ITは書き込めて読み戻しでも確認でき、FTLX1471D3BCV-ITも同様です。GLC-LH-SMはNo Acknowledgeを返さなくなり、正常に書き込めています。
HPはまだ降参していません。J4858Bは書き込み自体は形式上受け付けますが、書き換え後にスイッチ側からモジュールを拒否されます、J4859Cも同じ挙動です。というわけで自分の中では問題は半分だけ解決しました: FinisarとCiscoは今は書き込めていますが、HPはまた今度ということで脇に置いています。
HPの罠は書き込み保護より根が深いので、その結果は予想どおりです。J4858Bではバイト68-83、つまりシリアル番号を書き換えると、バイト124-127のチェックサムが変わってしまい、その後モジュールが拒否されます。これはMSAのCC_BASEやCC_EXTではありません、それらは計算するだけなら問題にならず、A0の末尾4バイトにある別のベンダー独自のチェックサムです。アルゴリズムはどれだけ突つかれても公には解明されていません。
J9150Aも同じ話です。さらに新しいHPとArubaのモジュールでは静的なチェックサムからチャレンジレスポンス方式のHPIDv2にそもそも移行していて、そこではプログラマは原理的に無力です。つまり「書き込みはできるが受け付けられない」というのは、まさに想定どおりの結果だったということです。
モジュール1個ではなくまとまった台数があるとのことなので、道具の話をします。Huawei S5731とS6730、それにHP 6120XG向けの書き換え用に、UbiquitiのUACC-SFP-WIZARDを流用しています - 安価なプログラマとしては十分実用的です。ただしUbiquiti自体のモジュールについてはパスワードのリストが出回っていて、0x00001011やSFPX、QSFPといった形式のもので、それがないと書き込みが開かないモジュールが一部あります。使っているイメージはFTLX8571D3BCVとFTLX8574D3BCVが中心で、まれにSNR-SFP+W73-3とW37-3も使います。
上の一般化を少し訂正しておきます、誰も早まってはんだごてを掴まないように: SFP+のメモリが必ずマイクロコントローラの背後に隠れているわけではありません。うちではFTLX8574D3BCVとSNR-SFP+W73-3が2個、ケージに挿したまま普通のプログラマで、はんだ付けなしに書き込めました。なのでまず手元の個体で確認してから、迂回策に手を出すべきです。
ちなみにwrite protectピンをグラウンドに落とすのも万能のレシピではありません: マイクロコントローラを積んだモジュールではそれをやっても何も変わらず、そこでの拒否はメモリではなくコントローラのファームウェアから来ています。この操作が意味を持つのは素直な独立したEEPROMが載っている場合だけで、しかも通電していないモジュールに対して行う必要があります。そうしないとモジュールがただのレンガになりかねません。