Turris Omniaがロック解除済みMA5671A GPONスティックを拒否、Turris OS 5.0.3でeth2が上がらない
自宅ラックのISP終端装置を、ルーターに直接挿すGPONスティックに置き換えようとしています。そうすればファイバーが2つの箱ではなく1つの箱に収まります。スティック自体は認識されますが、良い話はそこまでです。
- Turris OS 5.0.3、標準カーネルのTurris Omnia
- ロック解除ファームウェアのHuawei MA5671A GPONスティック、SGMII 1Gに設定
- 壁ソケットからスティックまでSC/APCピグテール
- eth2がSFPポート
モジュールは検出されますが、インターフェースは一向に有効化されません。
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66bその後eth2はdownのままで、キャリアもなく、カウンタにも何も出ません。
これまで試したこと:
- スティックを標準ファームウェアに戻したところ、代わりにEEPROM読み取りエラーになった
- ethtool -s eth2 1000 autoneg off duplex fullでレートを強制したところ、インターフェースは10Mbitハーフデュプレックスのままになった
- 同じスティックをMikroTikルーターに移したところ、ポート速度を手動で設定すればちゃんと上がる
つまりモジュール自体は生きていて、ファイバー側も問題ありません。カーネルがこのスティックの何に文句を言っているのか、そしてOmniaで拒否されずに実際に上がるGPONスティックはどれなのでしょうか。
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
これはモジュールが死んでいるのではなく、ホスト側の問題です。こうした転用GPONスティックのEEPROMは、メインラインのsfpドライバがマッピングできないエンコーディングを申告しています。そのためphylinkはポートを上げることを拒否し、あなたが貼ったログの行はまさにドライバがそう言っているものです。あなた自身の証拠も同じ方向を指しています。同じスティックがMikroTikではポート速度を手動設定すればリンクするので、オプティクスとPON側は問題ありません。
自分の環境で効果があったのは、モジュールごとの個別対応を持つくらい新しいカーネルだけで、Omniaで言うとカーネル5.4のHBDテスト版ブランチです。ただしこれは部分的な勝利で、どのスティックを持っているかに大きく左右される点は注意してください。そのカーネルでの結果は:
いずれではなく今すぐOmniaを動かしたいなら、自分ならDFP-34G-2C2をケージに挿します。本腰を入れる前に自分の機材でテストしてください。この結果はスティック間はもちろん、同じスティックのファームウェアリビジョン間でもはっきり変わります。
誰かが推測を始める前に、はっきりさせておく価値のあることが2つあります。まず、その5.0.3はどのブランチのもので、unameはどのカーネルを報告しますか。こうした転用GPONスティックが必要とするモジュールごとの個別対応は後から入ったので、出荷済みの安定版カーネルとテスト版とでは、まったく同じモジュールでも挙動がかなり違います。
次に、ONUのシリアルはプロバイダ側で登録されていますか。OLT側で認可されないスティックは、ただ死んでいるように見えるだけになりますし、サードパーティ製ONUの登録をそもそも拒否するプロバイダも少なくありません。
そして挿した時、ポートはinband/1000base-xに切り替わることが一度でもありますか、それともログはそのエンコーディングのメッセージのところで止まっていますか。
安定版ブランチで、5.0.3の標準カーネルのままです、何もカスタムはしていません。プロバイダ側は今回の問題ではなく、同じファイバーですし、スティックには登録済みのシリアルが入っています。
ログはエンコーディングの行で止まり、ポートはinband/1000base-xに切り替わりません。出る症状はファームウェアによって変わります。ロック解除版では:
加えてモジュールが送信フォルトを報告します。標準ファームウェアではそこまでも行きません。
そして先に書いた通り、レートを強制しても何も変わりません。ethtool -s eth2 1000 autoneg off duplex fullを実行してもインターフェースは10Mbitハーフデュプレックスのままです。
同じルーターで除外しておく価値のある別の故障パターンがあります。見た目は似ていますが、エンコーディングとは無関係です。Turris OS HBS 6.2.4でHALNy HL-GSFPを挿すと検出され、ポートはinband/1000base-xに切り替わりさえしたのに、その後リンクが落ちてeth2はdownのままになりました。
原因はこのスティックがそれ自体1台の小さなコンピュータだということです。自前のファームウェアを起動するのに1分近くかかり、それが終わって初めてケージに対してまともに応答します。コールドブートではその時点よりずっと前にルーターがケージを見に行ってしまうので検出に失敗し、ルーターは黙って銅線WANのマグネティクスにフォールバックします。ブート遅延を延ばしたら直りました。
デフォルトの3秒ではなく60秒にしたということで、同じスティックを持つ別の人もこれで確認できたと言っています。効果があったことがあと2つあります。銅線WANケーブルを抜いてもう一度再起動すること、そしてモジュール自体にログインして状態を確認すること(シリアルなら38400 8N1、SSHなら192.168.77.154のポート22666)です。