EEPROM の再コード化：パスワードと仕組み

長年のエンジニアリング議論から得られる核心的な洞察はこうです。トランシーバーの互換性を決めるのはファームウェアではなく、I²C 経由で読み取られる EEPROM 内の識別文字列です。 スイッチがモジュールを拒否するのは、単にベンダー文字列を認識できないからにすぎません。この一点だけで、「とりあえず Cisco としてコーディングしておけば、ほぼどこでも動く」という一般的な慣行や、コーディングツール市場そのものの存在理由が説明できます。

パスワードのありか

モジュールメモリーの保護領域へ書き込むには、書き込みの前に固定アドレスへ4バイトのパスワードを入力する必要があります。

よく挙げられるパスワード

一部ベンダーの QSFP-DD モジュールは、独自の固定デフォルト値で出荷されます。また、一部のマイクロプロセッサーベースのモジュールは変化する可変パスワードを使用しており、総当たり攻撃を試みる者にとっての落とし穴となっています。

総当たりが答えにならない理由

メモリーマップ全体を保護するメーカーレベルのパスワードは、総当たりに100日以上かかるオーダーです。ホストレベルの ASCII パスワードでさえ、最大で3日ほどかかります。現実的な方法は、正規モジュールから取得した既知のコードとパスワードのデータベースを使うことです——コーディングツールの本当の価値はここにあり、（単純な仕組みである）I²C のハードウェア部分にはありません。

自作プログラマーの落とし穴

• 安価な CH341A プログラマーは SFP のチェックサムを計算しません。 有効な CC_BASE/CC_EXT を伴わずにイメージを書き込むと、スイッチに拒否されるモジュールになってしまいます。チェックサムを自動的に再計算するツールが必要です。
• 一部のスイッチはアドレス 0x50 にしか書き込めないため、0x51 にあるパスワードにはスイッチ自身からアクセスできません。専用のプログラマーボードが必要です。
• EEPROM の書き込み保護ピン — 一部の工場では WP を Vcc に接続しており、現場でのモジュールへの書き込みができないようにロックされています。

現場での事例

• あるベンダーとしてコーディングされたモジュールは、別ベンダーのスイッチではオートネゴシエーションできませんでした。スイッチ自身のベンダー文字列にリコーディングすると、即座にリンクアップしました。
• 光モジュールベンダーの中には、意図的に未コーディングのモジュールを出荷し、購入者側で対象プラットフォーム向けにコーディングすることを想定しているところもあります。
• DWDM モジュールの波長チューニングも、コーディングに使うのと同じ管理インターフェースを通じて行われます。

CodingBox での手順

1. モジュールを読み取ります。内容は自動的にcode databaseに保存され、書き込みの前には必ずバックアップが取られます。
2. 書き込み保護されたメモリとパスワードでテーブルアドレス、パスワードアドレス、パスワード値を設定します——データベース内の既知のパスワードは自動的に適用されます。
3. EEPROM editor でベンダー、部品番号、その他の識別情報フィールドを編集します。CC_BASE と CC_EXT は自動的に再計算されます。
4. 選択したページを書き込み、読み戻して確認します。光モジュールの検証にあるコマンドで、スイッチ上のモジュールを確認します。

自らに権限のある相互運用性のためにのみモジュールをコーディングし、所属組織およびベンダーのポリシーに従ってください。

正しいリコーディングを支える規則——フィールドの形式、設定すべきビット、修正すべきチェックサム——はベンダーフィールド、コンプライアンスコード、チェックサムにあります。

工場が同じ段階で行うこと、そして不用意な書き込みが破壊しうる校正値がどの領域にあるか：製造と試験、コントローラーとファームウェア。

編集前に、どのバイトが何を保持しているか：SFF-8472 A0h マップ、SFF-8636 上位ページマップ、CMIS 上位ページマップ、XFP マップ。

ベンダーごとの対象型番とその命名規則：OEM 型番。書き込み後に各プラットフォームクラスが確認する内容：各 NOS がモジュールをどう検証するか。