SFPイメージのベンダー名とPNを編集した後に再計算が必要なEEPROMチェックサムはどれか

あなたのプログラマはCH341ベースのツールが普段やっていること、つまり何もしていません。渡したバイトをそのまま書き込むだけで、チェックサムフィールドには一切触れません。ベンダー製のプログラマは書き込み時に再計算するので、そればかり使っている人はこの問題に一度も遭遇せず、この話題自体を作り話だと思い込んでいます。

ツールを書く前にはっきりさせておくべきことが2つあります。1つ目、書き込み後にイメージを読み戻したのは何を使ったのか、書き込んだのと同じツールなのか、それとも別のものなのか。自前のキャッシュを返すリーダーは、実際にはチップに載っていないバイトでも平気で表示します。2つ目、編集後のイメージのバイト0から62までの合計を自分で計算してバイト63と比較したのか、それとも単にバイト63を元のダンプと比較しているだけなのか。変わっていないことと正しいことは同じテストではなく、あなたのメモは前者しか示していません。

拒否しているホストが何かも書いておく価値があります。識別フィールドを読むだけで何も検証しないホストもあれば、厳格に検証してサムが1つでもずれた瞬間にモジュールを弾くホストもあります。同じイメージでも判定は変わります。

この2つは単純な8ビットサムで、CRCは一切絡んでいません。

• CC_BASEはバイト63にあり、バイト0から62までの合計の下位8ビットです
• CC_EXTはバイト95にあり、バイト64から94までをカバーします

ベンダー名とベンダーPNはどちらもベース領域にあるので、あなたの編集はCC_BASEを無効にした一方でCC_EXTは正当なまま正しい状態が保たれました。シリアル番号や日付コードの編集はその代わりに拡張範囲を触るので、その場合古くなるのはバイト95の方です。どちらの再計算もバッファに対して2行で済みます: 範囲を合計し、0xFFでマスクし、サムバイトに格納するだけです。

自分で組みたくないなら、ツールがあります。py-sfp-eepromはPythonからEEPROMイメージを構築・検証でき(python3 -m sfp_eeprom)、sfppiはRaspberry Pi上で動いてサムをチェックし、修正も提案してくれます。どちらもhexエディタと暗算の組み合わせよりましな習慣です。失敗モードが静かだからです。モジュールはあなたが書いた通りに読み戻され、文句を言うのはホストだけです。

2つのMSAサムを正しくすることは必要条件ですが、どのベンダーのポートに挿すかによっては、それだけでは十分ではありません。

Ciscoがよく知られた例です。識別チェックは文字列だけではありません。Ciscoコード品のモジュールが持つ値は、ベンダーコードバイトに続けて名前バイトを食わせたxxd -r -p | md5sum程度の代物で再現できることを、何年も前に誰かが突き止めています。それらのダンプではコードと名前が互いに結び付いていて、Finisarは02の後ろに、Methodeは0Eの後ろに来ます。この2つが食い違っていれば、unlockコマンドを使おうが使うまいが、Catalyst 2960Xはまたモジュールを弾きます。

動作しているモジュールから取ったダンプに誰かが別のベンダー文字列を貼り付けた途端に動かなくなるのは、たいていこれが理由です。サムは問題なくても、識別情報の整合性が取れなくなっています。

「2つのサムを直せば終わり」という捉え方への小さな訂正ですが、それが成り立つのはMSAフィールドについてだけで、どのベンダーにとっても有効なイメージの条件がそれで全部というわけではありません。

HPが定番の反例です。J4858Bイメージのシリアル番号(バイト68から83)を編集すると、A0のバイト124から127も変わります。これはMSAのCC_BASEとCC_EXTバイトより先にあるベンダー独自のチェックサムです。この件は長く議論されましたが、アルゴリズムを公開した人はついに現れず、バイトが効くことが確認されただけでスレッドは終わっています。J4859CとJ9150Aの周辺でも同じ話が報告されています。その後のHPとArubaの機器はチャレンジレスポンス方式(HPIDv2)に移行し、これはEEPROM内では一切偽造できません。

ですので、ツールに投資する前に、対象のホストが何を検証しているのかを見極めてください。素のホストなら2つの加算サム、Catalystなら内部で整合の取れた識別情報、そして一部のHP製品では再現しようのない未文書化フィールドです。