CodingBox Q&A Ask question

UDM-Pro SFP+ cage'inde bir FS GPON ONU stick: seri numarasını yazmak için yönetim IP'sine ulaşmanın bir yolu yok

Asked Active Viewed 93 AI translation from English
3

Ev kurulumu, ve bir Cosmote GPON hattındaki ISP router'ından kurtulmaya çalışıyorum. Fikir, fiberi doğrudan UDM-Pro'ya sokup ONU işini stick'e yaptırmak, ama sağlayıcı, eski CPE'nin 12 karakterlik seri numarası ve cihaz model string'i sunulmadıkça oturumu kabul etmiyor, yani modülün içine girip ikisini de yazmam gerekiyor.

  • Ubiquiti UDM-Pro, stick SFP+ port 10'da oturuyor
  • MAC SFP'li FS GPON ONU stick, item 133619
  • duvar prizinden SC/APC'den SC/APC'ye patch kordon
  • seri numarası ve model string referansı olarak masada duran eski CPE

Benim sorunum klonlamanın kendisinden daha temel: modüle hiç ulaşamıyorum. Gateway shell'inden onun yönetim adresinde hiçbir şey cevap vermiyor.

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

İkinci komut, pes edene kadar öylece bekliyor. Banner yok, reddedilen bağlantı yok, hiçbir şey yok.

Zaten yaptıklarım:

  • stick'i yeniden oturttum ve patch kordonu değiştirdim, modül güç alıyor ve LED'i normal davranıyor
  • UDM-Pro'da 192.168.1.0/24'ü kullanan hiçbir şey olmadığından emin oldum, benim LAN'ım farklı bir subnette yaşıyor
  • cage için ayrı bir yönetim VLAN'ı kurmayı düşündüm, ama bu tek bir yazma işlemi için çok fazla tesisat

SFP cage'ini UDM-Pro shell'inden doğrudan adresleyip stick'e login olup seri numarasını ve cihaz ID'sini yazmanın, bunun için ayrı bir VLAN kurmadan bir yolu var mı?

Comments 4

Accepted answer

İki ayrı şey yolunuza çıkıyor, ve ikisi de modül değil.

Birincisi, adresleme. SFP cage'i UDM-Pro'da sıradan bir arayüz, gösterilen port numarası eksi bir olarak numaralanıyor, yani port 10 eth9 oluyor. Gateway'e modülün subnet'i içinde bir adres verin ve cevapların o adresten kaynaklandığından emin olun:

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

Bundan sonra 192.168.1.10, gateway shell'inden cevap veriyor.

İkincisi, handshake. Bu stick'lerdeki firmware, key exchange listesinin legacy algoritmalarda durduğu kadar eski, yani birini açıkça belirtmeniz gerekiyor:

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

İçeri girdikten sonra, ISP seri numarası set_serial_number AVMGXXXXXXXX ile giriliyor ve cihaz model string'i sfp_i2c -i7 -s ile klonlanıyor. Stick'i reboot edin ve gerçekte neyin tuttuğunu kontrol edin:

fw_printenv | grep nSerial

İki uyarı. Bunların hiçbiri desteklenen bir yapılandırma değil - bir cihaz üzerinde elle bir adres ve bir NAT kuralı ekliyorsunuz, yani bunu programlama seansı için geçici bir tesisat olarak görün ve hat kimlik doğrulayana kadar eski CPE'yi elinizde tutun. Uyarının diğer yarısı hızla ilgili: 2.5 Gbit bu platformun kendiliğinden kabul edeceği bir şey değil, yani 2.5G reklamı yapan bir modül bile ya 1G ya da 10G'de eşleniyor. Gateway'e hiç dokunmak istemiyorsanız, alternatif stick'i routed bir SFP portu olan başka bir kutuda programlayıp sonra taşımak.

4 IndonesiaedgepilotID Show original (English) AI translation

Gateway'in kendisi o cage'e ne diyor? Bu kutuda SFP portları sıradan arayüzler, ama isimlendirme ön paneldeki basılı numaralarla örtüşmüyor, yani paketleri cage olmayan bir şeyden dışarı itmek çok kolay - ve shell'den bakınca bu tam olarak sizin elde ettiğinize benziyor, karşı ucunda hiçbir şey olmayan bir oturum öylece bekliyor.

Gateway shell'inden arayüz listesini yapıştırın. Hangi arayüzün o porta ait olduğu netleşince, adresleme kısmı işin kolay yarısı.

0 GermanycoreadminDE Show original (English) AI translation

eth9 tam olarak oydu, port 10 eksi bir. Adres artı SNAT kuralı, 192.168.1.10'un ilk denemede cevap vermesini sağladı, legacy key exchange seçeneği de işin diğer yarısıydı: o flag olmadan istemcim handshake sırasında pes ediyordu, onunla ONTUSER prompt'unu hemen aldım.

Seri numarasını set_serial_number AVMGXXXXXXXX ile yazdım, model string'i sfp_i2c -i7 -s ile klonladım, reboot ettim, ve fw_printenv | grep nSerial ayarladığım değeri geri veriyor. Hat birkaç dakika sonra kimlik doğruladı ve eski CPE artık prizden çekili.

Zor yoldan doğrulanan bir şey: port 1G'de geldi, tam da bu cage'de 2.5G konusunda uyarıldığı gibi. Burada ISP'nin bana verdiği profil için gayet yeterli.

3 ChinasfpnodeCN Show original (English) AI translation

Aynı iş, farklı parçalar, ve işin çirkinleştiği yer seri numarası. Bir Calix GigaPoint 801Gv2 kimliğini ritool ile bir G-010S-A stick'e taşıyordum:

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

ONT serisi 372010010470, ama modül onu şöyle geri logladı:

read_sn_from_RI sn is: 3720101470

bir sıfır eksik. Sebep alan düzeni: GPON serisi 8 byte, ilk dördü vendor ID'yi ASCII karakter olarak tutuyor (3720, dört harf olarak harfi harfine okunuyor) ve son dördü sayısal kısmı hex olarak paketlenmiş şekilde tutuyor. 10010470 gibi ondalık bir kuyruk hane hane girmiyor, echo'nun bir karakter kaybetmesinin sebebi de bu.

Yani zaferi ilan etmeden önce, sağlayıcınızın ONT'yi baştan nasıl kaydettiğini kontrol edin: seri numarası mı, yoksa SLID / registration ID mi. Sadece seri numarasını yazmak her zaman eşleştirdikleri şey olmuyor.

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