Turris OmniaのODI DFP-34X-2C2が1000base-xでしかリンクせず、ethtoolでspeed 2500を受け付けない
棚に置いていた別のONUの代わりに、Turris OmniaにODI DFP-34X-2C2のGPONスティックを挿して、ファイバがルータで直接終端するようにしました。そこまでは問題なし、回線は登録され、トラフィックも流れていて文句はありません。問題は速度です。1Gbpsを一度も超えず、このスティックを買った理由はまさに2.5Gのためでした。
- Turris Omnia、TurrisOS 6.0.4
- SFPケージに挿したODI DFP-34X-2C2 GPONスティック、eth2
- 銅線WANは未接続、ポートはケージが持っている
起動後にカーネルが出す内容と、速度を上げようとしたときの結果:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentリンクが上がっている状態でethtool eth2を見るとモジュールは1000baseX/Fullでそれ以上は出てこず、上の拒否はethtoolがspeed 2500をアドバタイズできないと言っているだけです。
ここまで試したこと:
- スティックにtelnetで入り、そちら側のシェルから速度を設定、コマンドは受け付けるが結局1Gbpsに戻る
- 銅線WANを挿した状態と外した状態それぞれで再起動
- MACに2.5Gが提示されている痕跡がないかdmesgを確認、何もなし
これはルータがポートに上限をかけているのでしょうか、それともモジュール自体の限界でしょうか? このスティックでeth2を2500base-xで上げるためにホスト側でできることは何かあるでしょうか?
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 5
ここでの上限はOmniaではなくモジュール自体です。
ホストがネゴシエートする相手は、モジュールのEEPROMが自己申告している能力そのものです。プローブ時点でケージが頼れる情報はそのチップしかないからです。このスティックは1000Mbpsとしてコードされています。だからポートはinband/1000base-xとして構成され、phylinkが提示できる2500base-xモードは存在せず、ethtoolはアドバタイズする材料が何もないのでspeed 2500を拒否します。ホスト側のどんな切り替えもこれを回避できません。ethtoolはポートが存在すると教えられたモードしか要求できないからです。スティック内部のシェルが設定するのはモジュールのPON側であって、ケージがMACに向けて何をアドバタイズするかではありません。だからこそtelnetでの変更は消えてなくなり、結局1Gbpsに戻るのです。
残る現実的な選択肢は2つです。モジュールを2.5Gをアドバタイズするように書き換えてもらうか、最初からそうなっているものに交換するかです。書き換える方向で行くなら、予備を手元に置いておいてください。ホストが信頼する識別ページを書き換えることになるので、1バイトでも間違えるとケージがまったく認識しなくなるモジュールが出来上がります。あと、2つの速度は頭の中で分けておいてください。PON側が出す速度と、SFP-MAC間のリンクがネゴシエートする速度は別の数字なので、お金をかける前に実際に何を得られるのか考えてください。
スティックを疑う前に、その機体がどのデバイスツリーで起動しているか確認してください。Omniaのケージは追加のインターフェースではなく、金属のWANポートと合わせて同じeth2への2つの入り口になっていて、どちらか一方だけがMACにつながります。どちらになるかは、カーネルが起動時に読み込むdtbで決まります。なので/boot/dtbが何を指しているか見てください。armada-385-turris-omnia-sfp.dtbでなければ、見ているのは銅線側で、数字には何の意味もありません。
あとmvnetaの行だけでなく、dmesg | grep -i sfpの全体も貼ってください。ここで面白いのはプローブ時にカーネルがモジュールから何を読み取っているかで、たいていそれで一発で片付きます。
dtbはすでにSFP用のものです。スティックを最初に挿したときにarmada-385-turris-omnia-sfp.dtbへシンボリックリンクを張っていて、そうしないと何も上がってきませんでした。ケージがeth2を持っていて、銅線WANは未接続のままです。
dmesg | grep -i sfpを見るとモジュールが識別された後、最初に貼ったのと同じ行、eth2 switched to inband/1000base-x link modeが出ます。2500についてはどこにも何もありません。リンクが上がってトラフィックが流れている状態でethtool eth2は1000baseX/Fullを報告し、ethtool -s eth2 speed 2500はやはりInvalid argumentを返すので、2500はまったくアドバタイズされません。スティック内部でtelnetから速度を設定しても以前と同じ挙動で、コマンドは受け付けるものの結局1Gbpsに戻ります。
同じ基板がらみで、1Gに張り付くのではなくまったく上がってこないスティックに困っている人向けに近い話も置いておきます。Turris OS HBS 6.2.4のOmniaに挿したHALNy HL-GSFPで、カーネルは認識してポートもinband/1000base-xに切り替わったのに、その後リンクが落ちてeth2が二度と上がってきませんでした。
こちらはEEPROMの問題ではありません。あのスティックの中には小さなOSが丸ごと入っていて、ホストに応答できる状態になるまで1分ほど自分の時間が必要です。コールドスタートだとルータはそれよりずっと前にケージのプローブを諦めてしまい、ポートは銅線側のマグネティクスに戻ってしまいます。U-Bootの待ち時間を延ばしたら直りました:
デフォルトは3秒、60にするとカーネルがケージのプローブに取りかかる頃にはスティックの起動が終わっています。銅線WANを抜いてもう一度再起動したのも検出の助けになりました。あとスティックの中を見る必要があるときのために、シリアルは38400 8N1です。
診断には同意ですが、同じような症状でここにたどり着いた人のために注意点を1つ。このボードで「2.5Gが出ない」全部がモジュールのせいというわけではありません。phylinkの汎用validateコードがバックポートされたOpenWrtのスナップショットがあり、それがOmniaのケージを完全に壊したことがありました。ethtoolは2500baseX/Fullをアドバタイズしたままなのに、Link detected: noと報告していました。そのバックポートを戻すとポートは元通りになり、ethtoolはLink detected: yes、2500Mb/s full duplexと読むようになって、その後の修正がアップストリームでこのバックポートをちゃんと直しました。
見分け方は、ethtoolがsupportedとadvertisedに何を並べているかです。そこに2500baseX/Fullがあるのにリンクが単に上がらないなら、光モジュールではなく直近のイメージアップグレード後のカーネルとphylinkを疑ってください。ここでの話のように、モジュール自身がそう申告しているせいでポートが1000baseXしか知らないのであれば、どんなホスト側のソフトウェアもそのモードを作り出すことはできません。それはEEPROMのnominal bit rateバイトが、SFF-8472が定めた通りに正しく動いているだけです。