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
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
İ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:
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:
İçeri girdikten sonra, ISP seri numarası
set_serial_number AVMGXXXXXXXXile giriliyor ve cihaz model string'isfp_i2c -i7 -sile klonlanıyor. Stick'i reboot edin ve gerçekte neyin tuttuğunu kontrol edin:İ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.
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ı.
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 AVMGXXXXXXXXile yazdım, model string'isfp_i2c -i7 -sile klonladım, reboot ettim, vefw_printenv | grep nSerialayarladığı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.
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:
ONT serisi 372010010470, ama modül onu şöyle geri logladı:
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.