ODI DFP-34X-2C2 w Turris Omnia łączy się tylko na 1000base-x, ethtool nie przyjmuje speed 2500
Zamieniłem ONU od ISP na patyczek GPON ODI DFP-34X-2C2 w moim Turris Omnia, żeby światłowód kończył się w routerze, a nie w kolejnym pudełku na półce. Ta część zadziałała: łącze się rejestruje, ruch płynie, żadnych zastrzeżeń. Problem jest z prędkością. Nigdy nie wychodzi ponad 1Gbps, a 2.5G było całym powodem, dla którego kupiłem ten patyczek.
- Turris Omnia, TurrisOS 6.0.4
- patyczek GPON ODI DFP-34X-2C2 w klatce SFP, eth2
- miedziany WAN odpięty, port należy do klatki
Co mówi kernel po starcie i co się dzieje, gdy próbuję wymusić tę prędkość:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 przy podniesionym linku pokazuje moduł jako 1000baseX/Full i nic ponad to, a powyższa odmowa to ethtool mówiący, że speed 2500 nie da się zgłosić.
Co już sprawdziłem:
- telnet do patyczka i ustawienie prędkości z jego własnego shella; komenda jest przyjmowana, po czym i tak wraca do 1Gbps
- restarty z podpiętym i bez podpiętego miedzianego WAN
- przejrzałem dmesg w poszukiwaniu czegokolwiek o tym, że MAC dostaje ofertę 2.5G, nie ma nic
Czy to router ogranicza port, czy sam moduł? I czy jest coś po stronie hosta, co sprawi, że eth2 wstanie na 2500base-x z tym patyczkiem?
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 5
Sufitem jest tu sam moduł, nie Omnia.
Host negocjuje względem tego, co deklaruje EEPROM modułu, bo w momencie odpytania ten chip to jedyne, na czym klatka może się oprzeć. W tym patyczku jest zakodowane 1000Mbps. Więc port ustawia się jako inband/1000base-x, phylink nie ma trybu 2500base-x do zaoferowania, a ethtool odmawia speed 2500, bo nie ma czym go zgłosić. Żaden przełącznik po stronie hosta tego nie obejdzie: ethtool może prosić tylko o tryby, o których portowi powiedziano, że istnieją. Shell wewnątrz patyczka konfiguruje stronę PON modułu, a nie to, co klatka zgłasza w stronę MAC, i dlatego właśnie twoja zmiana przez telnet znika i lądujesz z powrotem na 1Gbps.
Zostają więc dwie realne opcje: przekodować moduł tak, żeby zgłaszał 2.5G, albo zamienić go na taki, który już to robi. Jeśli idziesz w przekodowanie, miej zapasowy na biurku. Przepisujesz stronę tożsamości, której ufa host, a zły bajt w tym miejscu daje ci moduł, którego klatka w ogóle przestaje rozpoznawać. Trzymaj też te dwie prędkości osobno w głowie: to, co dostarcza strona PON, i to, co negocjuje link SFP-MAC, to osobne liczby, więc policz, co faktycznie zyskujesz, zanim wydasz na to pieniądze.
Zanim obwinisz patyczek, sprawdź, jakie device tree ładuje urządzenie przy starcie. Klatka w Omnii to nie dodatkowy interfejs: ona i miedziana połówka WAN to dwa fronty na jeden i ten sam eth2, i tylko jeden z nich jest w danej chwili podłączony do MAC. To, który to jest, zależy od dtb, które kernel ładuje przy starcie. Sprawdź więc, na co wskazuje /boot/dtb: jeśli to nie armada-385-turris-omnia-sfp.dtb, patrzysz na stronę miedzianą i te liczby nic nie znaczą.
Wklej też pełne dmesg | grep -i sfp, nie tylko linię o mvneta. To, co kernel odczytuje z modułu przy odpytaniu, jest tu ciekawą częścią i zwykle rozstrzyga sprawę w jednej linii.
dtb jest już tym od SFP, zsymlinkowałem armada-385-turris-omnia-sfp.dtb, gdy tylko włożyłem patyczek, inaczej nic w ogóle nie wstawało. Klatka ma eth2 na własność, a miedziany WAN zostaje odpięty.
dmesg | grep -i sfp pokazuje moduł jako zidentyfikowany, a potem tę samą linię, którą wkleiłem, eth2 switched to inband/1000base-x link mode. Nigdzie ani słowa o 2500. ethtool eth2 zgłasza 1000baseX/Full, gdy link stoi i przepuszcza ruch, a ethtool -s eth2 speed 2500 nadal wraca z Invalid argument, więc w ogóle nie zgłosi 2500. Ustawienie prędkości przez telnet wewnątrz patyczka zachowuje się tak samo jak wcześniej: przyjmuje to, a potem wraca do 1Gbps.
Pokrewna historia z tej samej płyty, gdyby ktoś tu trafił z patyczkiem, który w ogóle nie chce wstać, a nie takim, co utknął na 1G. HALNy HL-GSFP w Omnii na Turris OS HBS 6.2.4: kernel go zidentyfikował, port nawet przełączył się na inband/1000base-x, a potem link spadł i eth2 nigdy nie wstał.
To akurat nie jest problem z EEPROM. Wewnątrz tego patyczka żyje cały mały system operacyjny i potrzebuje około minuty dla siebie, zanim jest w stanie w ogóle odpowiedzieć hostowi. Przy zimnym starcie router odpytuje klatkę i poddaje się na długo przed tym momentem, więc port wraca do miedzianych magnetyków. Wydłużenie opóźnienia U-Boot pomogło tutaj:
Domyślnie są to 3 sekundy; przy 60 patyczek zdążył już w pełni wstać, zanim kernel dobiera się do odpytania klatki. Odpięcie miedzianego WAN i drugi restart też pomogły przy wykrywaniu. A jeśli kiedyś będziesz musiał zajrzeć do środka patyczka, port szeregowy to 38400 8N1.
Zgadzam się z diagnozą, z jednym zastrzeżeniem dla każdego, kto trafi tu z podobnym objawem. Nie każde „nie chce robić 2.5G” na tej płycie to wina modułu. Był snapshot OpenWrt, w którym backportowano generyczny kod phylink validate, i to całkowicie zepsuło klatkę w Omnii: ethtool nadal zgłaszał 2500baseX/Full, ale raportował Link detected: no. Cofnięcie tego backportu przywróciło port do poprzedniego stanu, ethtool czytał Link detected: yes, 2500Mb/s full duplex, a późniejszy pull request naprawił ten backport w upstreamie.
Wskazówka tkwi w tym, co ethtool wymienia jako supported i advertised. Jeśli jest tam 2500baseX/Full, a link po prostu nie chce wstać, patrz na kernel i phylink po ostatnim upgrade obrazu, nie na optyk. Jeśli natomiast, jak tutaj, port zna wyłącznie 1000baseX, bo to właśnie zadeklarował o sobie moduł, żadne oprogramowanie hosta nie wyczaruje tego trybu. To bajt nominal bit rate w EEPROM robi dokładnie to, co mówi SFF-8472.