Turris Omnia odmawia odblokowanego sticka GPON MA5671A: eth2 nigdy nie wstaje na Turris OS 5.0.3
Próbuję zastąpić terminal ISP w domowej szafie stickiem GPON wpiętym prosto w router, żeby światłowód lądował w jednym pudełku zamiast w dwóch. Stick jest rozpoznawany i na tym dobre wieści się kończą.
- Turris Omnia na Turris OS 5.0.3, standardowy kernel
- stick GPON Huawei MA5671A z odblokowanym firmware, ustawiony na SGMII 1G
- pigtail SC/APC z gniazdka ściennego do sticka
- eth2 to port SFP
Moduł jest wykrywany, ale interfejs nigdy się nie aktywuje:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 zostaje potem w down, bez carriera, nic w licznikach.
Co już próbowałem:
- przeflashowanie sticka z powrotem na stock firmware, co daje mi za to błąd odczytu EEPROM
- wymuszenie prędkości przez ethtool -s eth2 1000 autoneg off duplex full, po czym interfejs siedzi na 10 Mbit half duplex
- przeniesienie tego samego sticka do routera MikroTik, gdzie wstaje, jak tylko prędkość portu zostanie ustawiona ręcznie
Czyli sam moduł żyje, a strona światłowodowa jest w porządku. Co w sticku jest takiego, czemu kernel się sprzeciwia, i które sticki GPON faktycznie wstają na Omnii, zamiast być odrzucane?
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
To jest problem po stronie hosta, nie martwy moduł. EEPROM w tych przerobionych stickach GPON deklaruje kodowanie, którego mainline'owy sterownik sfp nie zmapuje, phylink w związku z tym odmawia postawienia portu, a linijka, którą wkleiłeś, to sterownik mówiący dokładnie to. Twoje własne dowody wskazują to samo: identyczny stick łączy się na MikroTiku, jak tylko prędkość portu zostanie ustawiona ręcznie, więc optyka i strona PON są w porządku.
Jedyne, co u mnie ruszyło sprawę, to kernel wystarczająco nowy, żeby nieść specyficzne obejścia per moduł, co na Omnii oznaczało gałąź testową HBD z kernelem 5.4. Uprzedzam, że to tylko częściowe zwycięstwo i mocno zależy od tego, jaki masz stick. Na tym kernelu:
Więc jeśli chcesz mieć Omnię działającą teraz, a nie kiedyś tam, DFP-34G-2C2 to ten, który bym wstawił do klatki. Przetestuj na swoim sprzęcie, zanim się zdecydujesz, wyniki tutaj wyraźnie różnią się między stickami, a nawet między wersjami firmware tego samego.
Dwie rzeczy warto ustalić, zanim ktokolwiek zacznie zgadywać. Po pierwsze, z jakiej gałęzi jest to 5.0.3 i jaki kernel zgłasza uname? Specyficzne obejścia SFP per moduł, których potrzebują te przerobione sticki GPON, wylądowały później, więc wysyłkowy stabilny kernel i testowy zachowują się bardzo różnie przy dokładnie tym samym module.
Po drugie, czy numer seryjny ONU jest zarejestrowany po stronie operatora? Stick, który nigdy nie zostanie autoryzowany na OLT, będzie tam siedział, wyglądając na martwy, a wielu operatorów w ogóle odmawia rejestracji ONU innego producenta.
I gdy go podłączasz, czy port w ogóle przełącza się w inband/1000base-x, czy log zatrzymuje się dokładnie na tym komunikacie o kodowaniu?
Gałąź stabilna, standardowy kernel dla 5.0.3, nic dołożonego na wierzch. Strona operatora nie jest tu problemem, to ten sam światłowód, a stick niesie zarejestrowany numer seryjny.
Log zatrzymuje się na linijce o kodowaniu, port nigdy nie przeskakuje w inband/1000base-x. To, co dostaję, zależy od firmware. Z odblokowanym:
plus błąd nadawania zgłaszany przez moduł. Z fabrycznym firmware nawet tak daleko nie dochodzi:
I jak mówiłem, wymuszenie prędkości nic zupełnie nie daje: po ethtool -s eth2 1000 autoneg off duplex full interfejs dalej siedzi na 10 Mbit half duplex.
Jeszcze jeden tryb awarii do wykluczenia na tym samym routerze, bo wygląda podobnie, a nie ma nic wspólnego z kodowaniem. HALNy HL-GSFP na Turris OS HBS 6.2.4 był wykrywany, port nawet przełączył się w inband/1000base-x, potem link spadł i eth2 zostało w down.
Przyczyna: ten stick to sam w sobie mały komputer. Spędza coś koło minuty na podnoszeniu własnego firmware i dopiero potem odpowiada klatce czymkolwiek sensownym. Przy zimnym starcie router zagląda do klatki dużo wcześniej niż w tym momencie, więc wykrycie się nie udaje, a urządzenie po cichu wraca do miedzianych magnetyków WAN. Wydłużenie opóźnienia startu to naprawiło:
Sześćdziesiąt sekund zamiast domyślnych trzech, i ktoś inny z tym samym stickiem to potwierdził. Jeszcze dwie rzeczy, które pomogły: odłączyć miedziany kabel WAN i zrestartować jeszcze raz, oraz zalogować się do samego modułu, żeby zobaczyć, w jakim jest stanie, po serialu na 38400 8N1 albo po SSH na 192.168.77.154 port 22666.