CodingBox Q&A Ask question

Patyczek FS GPON ONU w klatce SFP+ UDM-Pro: nie da się dobić do jego IP zarządzania, żeby zapisać numer seryjny

Asked Active Viewed 93 AI translation from English
3

Domowy setup, próbuję pozbyć się routera ISP na linii GPON Cosmote. Pomysł jest taki, żeby wpiąć światłowód prosto w UDM-Pro i dać patyczkowi robić za ONU, ale operator akceptuje sesję tylko wtedy, gdy podany jest 12-znakowy numer seryjny i ciąg modelu urządzenia starego CPE, więc muszę wejść do środka modułu i zapisać oba.

  • Ubiquiti UDM-Pro, patyczek siedzi w porcie SFP+ 10
  • patyczek FS GPON ONU z MAC SFP, item 133619
  • patch cord SC/APC na SC/APC z gniazdka ściennego
  • stare CPE wciąż na biurku jako punkt odniesienia dla numeru seryjnego i ciągu modelu

Mój problem jest bardziej podstawowy niż samo klonowanie: w ogóle nie mogę dobić do modułu. Z powłoki bramy nic nie odpowiada na jego adres zarządzania.

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

Drugie polecenie po prostu wisi, aż się podda. Żadnego bannera, żadnego odrzucenia połączenia, nic.

Co już zrobiłem:

  • osadziłem patyczek ponownie i zamieniłem patch cord, moduł się zasila i jego LED zachowuje się normalnie
  • upewniłem się, że nic na UDM-Pro nie używa 192.168.1.0/24, moja sieć LAN żyje na innej podsieci
  • rozważałem zbudowanie dedykowanego VLAN-u zarządzania dla tej klatki, ale to sporo hydrauliki na jeden zapis

Czy da się zaadresować klatkę SFP bezpośrednio z powłoki UDM-Pro, żebym mógł zalogować się do patyczka i zapisać numer seryjny oraz device ID, bez stawiania osobnego VLAN-u tylko dla tego?

Comments 4

Accepted answer

Na drodze stoją dwie osobne rzeczy, i żadna z nich to nie moduł.

Po pierwsze, adresowanie. Klatka SFP to zwykły interfejs na UDM-Pro, numerowany jako wyświetlany numer portu minus jeden, więc port 10 to eth9. Daj bramie adres wewnątrz podsieci modułu i upewnij się, że odpowiedzi są wysyłane z niego:

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

Potem 192.168.1.10 odpowiada z powłoki bramy.

Po drugie, handshake. Firmware na tych patyczkach jest na tyle stary, że jego lista wymiany kluczy kończy się na starych algorytmach, więc trzeba jeden podać wprost:

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

Kiedy już jesteś w środku, numer seryjny ISP wchodzi przez set_serial_number AVMGXXXXXXXX, a ciąg modelu urządzenia klonuje się przez sfp_i2c -i7 -s. Zrestartuj patyczek i sprawdź, co faktycznie się przyjęło:

fw_printenv | grep nSerial

Dwa zastrzeżenia. Nic z tego nie jest obsługiwaną konfiguracją - ręcznie dodajesz adres i regułę NAT na urządzeniu appliance, więc traktuj to jako tymczasową hydraulikę na czas sesji programowania i trzymaj stare CPE, dopóki linia się nie uwierzytelni. Druga połowa ostrzeżenia dotyczy prędkości: 2,5 Gbit to coś, na co ta platforma sama z siebie się nie zgodzi, więc nawet moduł, który zgłasza 2,5G, kończy sparowany na 1G albo 10G. Jeśli wolisz w ogóle nie dotykać bramy, alternatywa to zaprogramować patyczek w innej maszynie z routowanym portem SFP i przełożyć go potem.

4 IndonesiaedgepilotID Show original (English) AI translation

Jak sama brama nazywa tę klatkę? Na tym urządzeniu porty SFP to zwykłe interfejsy, ale nazewnictwo nie pokrywa się z numerami wydrukowanymi na przednim panelu, więc łatwo jest pchać pakiety z czegoś, co wcale nie jest tą klatką - a z poziomu powłoki to wygląda dokładnie tak, jak to, co masz: sesja wisząca bez niczego po drugiej stronie.

Wklej listę interfejsów z powłoki bramy. Jak tylko będzie jasne, który interfejs należy do tego portu, część z adresowaniem to łatwiejsza połowa.

0 GermanycoreadminDE Show original (English) AI translation

eth9 to było dokładnie to, port 10 minus jeden. Adres plus reguła SNAT sprawiły, że 192.168.1.10 odpowiedziało za pierwszym razem, a opcja starej wymiany kluczy była drugą połową: bez tej flagi mój klient poddawał się podczas handshake, z nią dostałem prompt ONTUSER od razu.

Zapisałem numer seryjny przez set_serial_number AVMGXXXXXXXX, sklonowałem ciąg modelu przez sfp_i2c -i7 -s, zrestartowałem, i fw_printenv | grep nSerial zwraca wartość, którą ustawiłem. Linia uwierzytelniła się kilka minut później i stare CPE jest już odłączone.

Jedno potwierdziło się na trudny sposób: port wstał na 1G, dokładnie tak jak ostrzegano o 2,5G na tej klatce. W sam raz dla profilu, jaki dostaję tu od ISP.

3 ChinasfpnodeCN Show original (English) AI translation

Ta sama robota, inne części, i to numer seryjny robi się tu nieprzyjemny. Przenosiłem tożsamość Calix GigaPoint 801Gv2 na patyczek G-010S-A przez ritool:

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

Numer seryjny ONT to 372010010470, ale moduł zalogował go z powrotem jako

read_sn_from_RI sn is: 3720101470

o jedno zero za krótko. Powód jest w układzie pola: numer seryjny GPON ma 8 bajtów, pierwsze cztery trzymają vendor ID jako znaki ASCII (3720 czytane dosłownie jako cztery litery), a ostatnie cztery trzymają część liczbową spakowaną jako hex. Dziesiętny ogon taki jak 10010470 nie wchodzi cyfra po cyfrze, dlatego echo gubi jeden znak.

Więc zanim ogłosisz zwycięstwo, sprawdź, jak twój operator w ogóle rejestruje ONT - po numerze seryjnym czy po SLID / registration ID. Sam zapis numeru seryjnego nie zawsze jest tym, po czym dopasowują.

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