Patyczek GPON DFP-34X-2C2 pojawia się w dmesg dopiero po kilkudziesięciu sekundach, a potem łączy się na 1G
Zastępuję ONT operatora patyczkiem SFP GPON na skrzynce Linux, która kończy nasz WAN, i patyczek zachowuje się zupełnie nie jak transceiver. Wsadzam go i gniazdo milczy przez pół minuty albo dłużej, wystarczająco długo, że dwa razy uznałem moduł za martwy, a kiedy kernel w końcu go zauważy, link ustala się na prędkości gigabitowej, co przekreśla sens całego ćwiczenia.
Stanowisko:
- skrzynka routera Linux, gniazdo SFP sterowane przez warstwę SFP kernela, mainline kernel
- patyczek GPON ODI DFP-34X-2C2
- patyczek Huawei MA5671a jako druga próbka
- zwykły moduł światłowodowy 1G, który pojawia się w tym samym gnieździe natychmiast, więc samo gniazdo jest w porządku
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offCo już próbowałem:
- przełożenie patyczka i zostawienie go samego na kilka minut, zanim dotknę interfejsu, a to oczekiwanie jest za każdym razem, nie tylko przy pierwszym włożeniu
- odbicie interfejsu po wykryciu, co niczego nie zmienia w wynegocjowanym trybie
- MA5671a pokazuje to samo powolne pojawianie się, więc to nie jedna wadliwa próbka
Czy to po prostu tak zachowują się patyczki GPON na hoście Linux, czy moja strona robi coś źle? Co właściwie dzieje się tutaj między włożeniem a wykryciem?
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 7
Zanim zacznie się zgadywanie, dwie rzeczy warto ustalić. Po pierwsze, wklej nieprzycięty dmesg od włożenia w dół, zamiast dwulinijkowego grepa. Mówisz, że gniazdo siedzi za warstwą SFP kernela, i nie mam powodu w to wątpić, ale linie, które odfiltrowałeś, to te, które pokazują, ile razy moduł był odpytywany, co się w międzyczasie poddawało i ile trwała każda próba.
Po drugie, co sam interfejs deklaruje, że potrafi, gdy patyczek już w końcu wstanie, i czy 2500baseX pojawia się gdziekolwiek w ogłaszanych trybach? I jaką prędkość daje ci ISP po stronie PON, bo jeśli to plan gigabitowy, to link, jaki dostajesz, jest tym właściwym i nie ma czego naprawiać.
Niestety oczekiwane zachowanie, i to nie twój host.
Patyczek GPON to nie transceiver z chipem EEPROM w środku. To mały komputer Linux na własnym SoC, wciśnięty w powłokę SFP, a EEPROM, który twój host czyta przez I2C, jest emulowany przez ten system. Nic nie odpowiada na magistrali, dopóki własny firmware patyczka nie zdąży wystartować na tyle, żeby serwować te strony, dlatego siedzisz tam kilkadziesiąt sekund, podczas gdy zwykły moduł odpowiada natychmiast. Ta cisza przed twoją linią modułu to właśnie boot.
Druga połowa twojego problemu to to, że to, co ogłaszają emulowane strony, często jest po prostu błędne. Interfejs po stronie hosta na tych patyczkach to 2500BASE-X, a EEPROM mówi coś innego, więc warstwa SFP bierze to za dobrą monetę i osiada na trybie gigabitowym. Obie połówki są w kernelu załatwione przez quirki per moduł, a nie przez cokolwiek, co dałoby się skonfigurować, a OEM-owy DFP-34X-2C2 złapał jeden z tych quirków właśnie z tego powodu.
Czy twoja próbka na niego trafia, zależy od stringów producenta i części, jakie zgłasza, a te różnią się między rebadge'ami, więc porównaj, co wypisuje twoja linia dmesg, z tym, co dopasowuje quirk, zanim założysz, że jesteś pokryty.
Żeby podkreślić, dlaczego podejście przez quirki jest w ogóle potrzebne: SFF-8472 zakłada pasywne urządzenie pamięci, które odpowiada w zwykłych czasach I2C. Nic w nim nie przewiduje urządzenia, które potrzebuje pół minuty bootu, zanim zacznie mówić, więc host trzymający się standardu ma pełne prawo poddać się co do modułu albo zaufać bitom trybu, które w końcu odczyta.
Punkt o rebadge'ach powyżej to praktyczna pułapka. Dopasowanie idzie po stringach producenta i części, więc dokładnie ten sam fizyczny patyczek sprzedawany pod inną nazwą całkowicie omija quirk i wracasz do linku gigabitowego bez oczywistego powodu. I nie buduj niczego, co zależy od obecności modułu wkrótce po boocie, bo ten wyścig jest tutaj nie do wygrania.
Liczenie na to, że producenci patyczków naprawią zawartość swojego EEPROM, też jest optymistyczne. Kiedy te problemy były zgłaszane, nawet duzi ISP dostawali od nich bardzo mało w odpowiedzi.
Ta sama klasa problemu pojawia się na routerach konsumenckich, więc przynajmniej masz towarzystwo. Właściciele Archer BE800, BE900 i GE800 z patyczkiem w combo porcie SFP+ 10G dostają 1 Gbit/s zamiast 2,5, za które płacą, a własna lista TP-Link patyczków zgłaszanych jako działające w tych portach to ODI DFP-34X-2C2, Huawei MA5671A i Nokia G-010SA, czyli ta sama krótka lista części, na jakiej każdy kończy.
Pierwszą radą tam był firmware plus przełożenie, i część o przełożeniu nie jest bez sensu, moduł, który nie zatrzasnął się do końca, faktycznie potrafi się cofnąć. Buildy beta w końcu odsłoniły konfigurację portu, jedną na model:
Z jednym z nich na skrzynce tryb portu SFP staje się ustawialny przez telnet, najpierw zrzucony interfejs,
ip link set eth1 downi tak dalej.Wciąż obejście, nie naprawa, pamiętaj. Rok później napływały te same skargi, i nie tylko o patyczkach: jedna osoba miała w tym porcie AOC JT-AOC-SFP-15 od JT-COM, inna pasywny DAC SFP+ 10G od Ampcom, i oba siedziały na 1 Gbit/s.
Warto znać drugi tryb awarii, zanim ktoś zaproponuje przeniesienie patyczka na kartę NIC. Na OpenWrt 19.07 na x86 z Intel X520 i kmod-ixgbe, MA5671a jest po prostu odrzucany jako niewspierany SFP. Ustawienie allow_unsupported_sfp przez zwykłe pliki konfiguracji modułu nic tam nie daje, parametr trzeba podać w momencie ładowania modułu:
I nawet z tym sterownik dalej go odrzuca, bo EEPROM patyczka w ogóle nie opisuje normalnego transceivera, a flaga nie potrafi tego zatuszować. Jeśli jednak wylądujesz na karcie NIC, sprawdź port najpierw zwykłym modułem 1000BASE-T, LX albo SX, inaczej debugujesz kartę i patyczek jednocześnie.
Uważaj jednak, żeby nie zlewać tych dwóch spraw. allow_unsupported_sfp żyje wewnątrz ixgbe i decyduje, czy ten sterownik w ogóle jest skłonny sterować daną optyką, co jest inną decyzją niż ta podejmowana tutaj. Długie oczekiwanie i zły tryb biorą się z tego, że generyczna warstwa SFP czyta emulowane strony i przekazuje wynik w górę do phylink, i to właśnie tam siedzą quirki per moduł.
Na płycie z prawdziwym gniazdem SFP flaga ixgbe w ogóle nie istnieje i nie jest naprawą, a na X520 lista quirków też cię nie uratuje. Ten sam objaw na powierzchni, inna warstwa pod spodem, i mylenie ich to właśnie tak ludzie kończą przebudowywaniem sterowników na darmo.
Jeszcze jedna granica warta narysowania, skoro już przy tym jesteś: sprawienie, żeby host widział patyczek, i sprawienie, żeby OLT go zaakceptował, to niezależne problemy, a ten drugi potrafi być dużo gorszy.
Jest dobrze udokumentowany przypadek Xicom DFP-34X-2C2 załadowanego tożsamością skopiowaną z ZTE ZXHN F601 przez setmac i zapytania OMCI, GPON serial, hasło PLOAM, LOID, serial sprzętowy i string firmware, wszystko. Patyczek dochodzi do stanu O5 i po prostu tam siedzi, bez przypisanego ONU ID i bez ruchu, bo dojście do O5 znaczy tylko, że ranging zadziałał, podczas gdy upload MIB wciąż musi pasować do profilu ONT, jakiego oczekuje OLT. Nikt w tamtym wątku nie wyprodukował naprawy.
Więc kiedy już dostaniesz 2500BASE-X lokalnie, nie zakładaj, że trudna część jest za tobą. Tam, gdzie operator wiąże profil usługi z jednym konkretnym modelem ONT, może nie być żadnego zestawu skopiowanych pól, który sprawi, że patyczek third-party zostanie zaakceptowany.