Turris OmniaのALLNET ALL4781-VDSL2-SFPスティックが30分から120分おきに再同期する
ようやくVDSL2回線をISPの箱から外して、Turris Omnia自体で終端させました。主な狙いはPPPoEをブリッジモードの別デバイスではなくルーター自身で動かすことです。セットアップ自体は快適で、スティックをケージに挿すだけでWANインターフェースがそのままモジュールに移り、メタルソケットは使わなくなって、内部リンクも勝手に上がりました。緑のLEDはDSL同期を、オレンジはルーター側との接続を示しています。
- Turris Omnia、モデム側インターフェースにPPPoEを設定
- SFPケージにALLNET ALL4781-VDSL2-SFPモデムスティック
- 下り100Mbitフルでトレーニングが決まるVDSL2回線
option ifname 'eth1.7'(回線がVLAN 7タグを要求するため)
10分の設定と再起動でライン速度いっぱいまで上がりました。問題はそれが維持されないことです。30分から2時間のどこかでDSLが再同期を起こし、復帰までに2、3分かかります。
LCP terminated by peer
Modem hangup
eth1: link is downすでに試したこと:
- スティックを挿し直してルーターを再起動したが、その後の間隔は変わらない
- DSLパッチケーブルを交換し、スティックを回線の一番手前のソケットに移動した
- 銅線のWANケーブルを抜いて、インターフェースを奪い合うものが何もないようにした
どれをやってもパターンは変わりません。これはスティックの問題か、自分の回線の問題か、それともOmniaがケージを駆動する方法の問題でしょうか。このモデムスティックを再同期なしで長期間運用できている人はいますか。
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
それは既知の相性の悪い組み合わせです。ファームウェア3.4と、実際に100Mbitを出せる回線という組み合わせです。スティック自体が壊れているわけではありません。知っている別のOmniaでは同じモジュールをVDSL2プロファイル17aの回線で長期間動かしていて、一度も再同期していません。これがこの機種についての報告が割れる理由です。どの回線がどちらのグループに入るかは、データシートを事前に見ても分かりません。
この順番で2つです。
まずベンダーにファームウェアについて問い合わせてください。100Mbitに届く回線で3.4がおかしな挙動をすることはベンダー側も認めていて、新しいビルドは無料なので、使わない理由がありません。
次に、その後もLEDを見続けてください。先に緑が消えればDSL側、オレンジならケージ側の問題です。新しいビルドでも緑が落ち続けるなら、あなたの回線ではファームウェアだけが話のすべてではなかったということです。
どうせ聞かれるので正直に結果も書いておくと、更新しても何も変わらず、同じ30分から2時間の周期で再同期が続いた回線を少なくとも1本知っています。このスティックの安定性はビルドと同じくらい回線の特性にも左右されるようなので、ファームウェアは確実な解決策としてではなく、一番手軽に試せるものとして扱ってください。それでも落ちるなら、地味ですが前段にモデムを戻して
eth1.7経由でPPPoEセッションをルーター側に残す方法が残ります。今の設定はそのまま使えますし、同期を追いかけ続けなくて済みます。スティックにはどのファームウェアが入っていますか。出回っているビルドは複数あり、速い回線での挙動が同じではないので、まずそこを特定する必要があります。
ルーターを疑う前にあと2点。落ちた瞬間、緑のLEDは消えますか、それともオレンジ側だけが動いて緑は点いたままですか。これでDSL同期が失われているのか、それともOmniaへのリンクだけなのかが分かります。もう一つ、落ちる前の数分間にスティック自体から有用な情報、到達可能レート、SNRマージン、エラーカウンタなどは取れますか。死ぬ瞬間まで速度を維持している同期と、事前にじわじわ落ちていく同期はまったく違う話です。
スティックのファームウェアは3.4です。
箱の横に座って、3回連続で落ちる瞬間を確認しました。先に緑が消え、オレンジはずっと点いたままです。つまりルーターへのリンクは一切動いておらず、死ぬのはDSL同期のほうで、PPPoEセッションはそれに引きずられて落ちています。これで
LCP terminated by peerが原因ではなく結果だということも分かりました。疑ってはいたものの証明できていなかった点です。カウンタについては渡せるものが何もありません。到達可能レート、マージン、エラーカウント、これらをスティックはどこにも出しておらず、ルーターが見せてくれるのは同期レートだけです。その数値は消える瞬間までライン速度のままなので、事前にじわじわ落ちることはなく、単に消えるだけです。プロファイルもISPのモデムが前段にあった頃から変わっていません。
スティックは違いますがケージは同じなので、テスト中に知っておく価値はあります。
OmniaにHALNy HL-GSFP GPONスティックを挿していたことがあります。カーネルは何の文句もなく認識し、ポートはinband/1000base-xに切り替わったのに、eth2はずっとdownのままでした。原因は互換性ではなくタイミングです。このモジュールは自前の小さなOSを積んでいて、何に対しても応答するまでに1分近くかかるのに、ケージは電源投入から数秒でプローブされます。プローブは誰もいないと判断し、ルーターは黙ってメタルWANのままになり、SFPインターフェースは目を覚ましません。u-bootで
fw_setenv bootdelay 60としたら完全に解決しました。これではセッション途中の再同期は説明できないので、あなたの答えではありません。ただ、落ちた後に再起動して銅線側に戻ってしまうことがあれば、それはモジュールが死んでいるのではなく、この仕組みを見ているということです。