CodingBox Q&A Ask question

UDM-ProのSFP+ケージに挿したFS製GPON ONUスティック: 管理IPに到達できずシリアルを書き込めない

Asked Active Viewed 93 AI translation from English
3

自宅環境で、CosmoteのGPON回線からISPのルーターを取り除こうとしています。ファイバーをUDM-Proに直接引き込んで、スティックにONUの仕事をさせるというアイデアですが、プロバイダーは旧CPEの12文字のシリアルとデバイスモデル文字列を提示しないとセッションを受け付けないので、モジュールの中に入ってその両方を書き込む必要があります。

  • Ubiquiti UDM-Pro、スティックはSFP+ポート10に
  • MAC SFP搭載のFS製GPON ONUスティック、品番133619
  • 壁のソケットからのSC/APC対SC/APCパッチコード
  • シリアルとモデル文字列の参照用に、旧CPEはまだ机の上に置いてある

私の問題はクローン作業そのものより基本的なところにあります。モジュールにまったく到達できません。ゲートウェイのシェルからは、その管理アドレスに何も応答がありません。

ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10

2つ目のコマンドは、あきらめるまでただ座り続けます。バナーもなし、接続拒否もなし、何も出ません。

すでに試したこと:

  • スティックを挿し直し、パッチコードも交換した。モジュールは電源が入りLEDも動いている
  • UDM-Pro上で192.168.1.0/24を使っているものが他にないことを確認した。自分のLANは別のサブネットにある
  • そのケージ専用の管理VLANを組むことも検討したが、1回の書き込みのためにしては配線が大掛かりすぎる

別途VLANを立てなくても、UDM-Proのシェルから直接SFPケージにアドレスを振って、スティックにログインしてシリアルとデバイスIDを書き込む方法はあるでしょうか。

Comments 4

Accepted answer

障害になっているのは別々の2つのことで、どちらもモジュール自体の問題ではありません。

まずアドレッシング。SFPケージはUDM-Pro上では普通のインターフェースで、表示されているポート番号から1引いた番号が振られています。つまりポート10はeth9です。ゲートウェイにモジュールのサブネット内のアドレスを与え、応答がそこから返るようにしてください。

ip addr add dev eth9 local 192.168.1.2/24
iptables -t nat -A POSTROUTING -o eth9 -d 192.168.1.0/24 -j SNAT --to 192.168.1.2

これで192.168.1.10がゲートウェイのシェルから応答するようになります。

次にハンドシェイク。このスティックのファームウェアは古く、鍵交換のリストがレガシーなアルゴリズムまでしかないので、明示的に指定する必要があります。

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ONTUSER@192.168.1.10

入れたら、ISPのシリアルはset_serial_number AVMGXXXXXXXXで書き込み、デバイスモデル文字列はsfp_i2c -i7 -sでクローンします。スティックを再起動して、実際に反映されたか確認してください。

fw_printenv | grep nSerial

注意点は2つです。これはどれもサポートされた構成ではありません。アプライアンスにアドレスとNATルールを手動で追加しているので、書き込み作業のための一時的な配線だと考えて、回線が認証されるまでは旧CPEを残しておいてください。もう半分の注意はレートについてです。2.5Gbitはこのプラットフォームが自分から合意するものではないので、2.5Gをアドバタイズするモジュールでも結局1Gか10Gのどちらかでネゴシエーションされます。ゲートウェイにまったく触りたくないなら、代わりにルーテッドSFPポートを持つ別のボックスでスティックをプログラムしてから移す方法もあります。

4 IndonesiaedgepilotID Show original (English) AI translation

ゲートウェイ自身はそのケージを何と呼んでいますか。このボックスではSFPポートは普通のインターフェースですが、命名がフロントパネルに印刷されている番号とは一致しないので、そのケージとはまったく別の何かからパケットを送り出してしまうことが簡単に起こります。そしてシェルから見ると、それはまさにあなたが得ている状態、つまり対向に何もないままセッションが座り続けている状態に見えます。

ゲートウェイのシェルからインターフェース一覧を貼ってください。どのインターフェースがそのポートに対応するかはっきりすれば、アドレッシングの部分は簡単なほうの半分です。

0 GermanycoreadminDE Show original (English) AI translation

eth9でぴったり当たりでした、ポート10から1引いたものです。アドレスとSNATルールで192.168.1.10が一発で応答するようになり、レガシー鍵交換オプションがもう半分でした。そのフラグなしだとクライアントはハンドシェイク中にあきらめ、付けたらすぐにONTUSERプロンプトが出ました。

set_serial_number AVMGXXXXXXXXでシリアルを書き込み、sfp_i2c -i7 -sでモデル文字列をクローンし、再起動したらfw_printenv | grep nSerialは設定した値を返してきます。数分後に回線は認証され、旧CPEは今は抜いてあります。

苦労して確認したことがひとつ。ポートは1Gで上がりました、このケージで2.5Gについて警告されていたとおりです。こちらでISPが渡してくるプロファイルにはそれで十分です。

3 ChinasfpnodeCN Show original (English) AI translation

同じ作業でも部品が違うと、シリアルのところで厄介なことになります。私はCalix GigaPoint 801Gv2のアイデンティティをritoolでG-010S-Aスティックに移していました。

ritool set MfrID 3720
ritool set G984Serial 10010470
ritool set YPSerialNum 10010470

ONTのシリアルは372010010470ですが、モジュールは書き戻すとこう記録しました。

read_sn_from_RI sn is: 3720101470

0が1桁足りません。理由はフィールドのレイアウトにあります。GPONのシリアルは8バイトで、最初の4バイトはベンダーIDをASCII文字として保持し(3720がそのまま4文字として読まれる)、残り4バイトは数値部分をhexにパックして保持します。10010470のような10進数の末尾は桁ごとにそのまま収まるわけではないので、エコーバックで1桁失われるわけです。

なので勝利宣言をする前に、そもそもプロバイダーがONTをどう登録しているのか、シリアルなのかSLID/登録IDなのかを確認してください。シリアルだけ書き込んでも、それが照合対象とは限りません。

4 SpainoptictechES Show original (English) AI translation
Log in to comment. Log in