Turris Omnia przypina stick XPON Luleey LL-XS2510 do 1000baseX, a ethtool nigdy nie oferuje 2.5G

Wklej pełny wynik ethtool eth2 i linie sfp z dmesg, nie tylko komunikat o linku. Ciekawa część to to, co host uznał za możliwości modułu: jeśli phylink osiadł na inband/1000base-x, wziął to z własnego EEPROM modułu, i nic, co skonfigurujesz na routerze, nie doda trybu, którego sterownik nigdy nie zobaczył.

Klatka w Omnii jest w porządku aż do 2.5G, więc to nie sprzęt cię tu ogranicza. Powiedz też, czy coś ostatnio zmieniło się na hoście, łącznie z upgrade'em image'u.

dmesg, identyczne przy każdym boocie:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2 daje 1000baseX/Full zarówno jako zestaw supported, jak i advertised, oraz Link detected: yes przy 1000Mb/s full duplex. Nic powyżej 1G nigdzie się w wyniku nie pojawia.

flash set LAN_SDS_MODE 6 na sticku faktycznie przechodzi i przeżywa restart modułu, ale strona hosta w ogóle na to nie reaguje: ten sam komunikat, to samo 1G. Router jest na tym image od kiedy stick tam wszedł, więc nie ma do czego zrobić rollbacku.

To host bierze moduł za słowo. Sterownik sfp czyta EEPROM, widzi część, która deklaruje 1000base-x, i przypina eth2 do inband/1000base-x; phylink wtedy nie ma trybu 2.5G do zaoferowania, co dokładnie odpowiada wynikowi ethtool, który wkleiłeś. To, co ustawiasz wewnątrz RTL960x przez LAN_SDS_MODE, dotyka własnego serdesa modułu, nie tego, co ogłasza routerowi, więc to nigdy nie miało zmienić wynegocjowanego trybu.

Dwa wyjścia, i znam tylko te dwa. Albo przepisz EEPROM modułu, żeby ogłaszał 2.5G, co jest znaną sztuczką na DFP-34X-2C3, ale twój to 2C2 i nie zakładałbym tych samych offsetów. Albo załataj hosta: dodaj quirk dla tego modułu w sfp.c i uruchom kernel z tą łatką, zostawiając stick nietkniętym.

Licząc na chłodno, załatałbym hosta. Zbrickowany EEPROM w sticku, którego nie da się łatwo przeflashować, to dużo gorsze popołudnie niż kernel, do którego można zrobić rollback.

Kolejny powód, żeby podejrzewać hosta, a nie moduł. W snapshotach OpenWrt był okres, gdy backportowany generyczny kod phylink validate psuł klatkę SFP w Omnii wprost: ethtool wciąż ogłaszał 2500baseX/Full, a port po prostu zgłaszał Link detected: no. Zbisekcjonowało się to czysto do tego commita w kernelu, zrzucenie backportu przywróciło link przy 2500Mb/s full duplex, a kolejna poprawka zamknęła temat.

Inny objaw niż u ciebie, ta sama lekcja. Na płytach mvneta i phylink to software hosta decyduje, co wolno klatce, i opłaca się trzymać sprawdzony image do odwrotu, zanim zaczniesz budować własny.

Jeśli idziesz drogą własnego kernela na Turris OS, zrób najpierw snapshot: schnapps create "Before new kernel", potem opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk i restart. Jeśli kernel się źle zachowuje, robisz rollback zamiast rozbierać routera.

Druga rzecz, o której nikt nie wspomina aż do potem: link 2.5 Gbps to nie 2.5 Gbps ruchu. CPU Armada w Omnii nie przepchnie tego na jednej kolejce, więc zaplanuj packet steering i strojenie RPS, zanim liczba na drucie zamieni się w przepustowość.

Niezwiązana pułapka dla każdego, kto czyta to z innym stickiem: niektóre moduły PON uruchamiają własny system operacyjny i potrzebują z minutę, zanim w ogóle odpowiedzą, więc przy zimnym boocie router odpytuje klatkę za wcześnie i spada na miedziane magnetyki. fw_setenv bootdelay 60 w U-Boot to zwykłe lekarstwo. Nie twój przypadek, skoro twój moduł jest wykrywany od razu.

Zamykając wątek: wygrał załatany host. Zbudowałem kernel ze zmodyfikowanym sfp.c, najpierw zrobiłem snapshot schnapps, zainstalowałem ipk z --force-reinstall i zrestartowałem. ethtool eth2 teraz wylistowuje 2500baseX/Full, a link wstaje przy 2.5 Gbps.

Przy module ostatecznie nic nie zrobiłem. LAN_SDS_MODE zostało tam, gdzie było, i okazało się nieistotne, więc nigdy nie musiałem dotykać EEPROM.

Przepustowość potrzebowała też drugiej rady. Zaraz po restarcie box siedział wyraźnie poniżej prędkości linku na jednej kolejce; po dostrojeniu packet steeringu WAN wreszcie robi to, po co ten stick kupiono.