Le Turris Omnia bloque un bâton XPON Luleey LL-XS2510 en 1000baseX et ethtool n'offre jamais le 2,5G

Postez la sortie complète de ethtool eth2 et les lignes sfp de dmesg, pas seulement le message de lien. La partie intéressante est ce que l'hôte a décidé que le module est capable de faire : si phylink s'est fixé sur inband/1000base-x, il l'a pris de l'EEPROM du module lui-même, et rien de ce que vous configurez sur le routeur n'ajoutera un mode que le driver n'a jamais vu.

La cage sur l'Omnia va bien jusqu'à 2,5G, donc le matériel n'est pas ce qui vous limite ici. Dites aussi si quelque chose a changé récemment côté hôte, une mise à niveau d'image incluse.

dmesg, identique à chaque démarrage :

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

ethtool eth2 donne 1000baseX/Full à la fois comme ensemble supported et advertised, et Link detected: yes à 1000Mb/s full duplex. Rien au-dessus de 1G n'apparaît nulle part dans la sortie.

flash set LAN_SDS_MODE 6 sur le bâton passe bien et survit à un redémarrage du module, mais le côté hôte n'y réagit pas du tout : même message, même 1G. Le routeur est sur cette image depuis que le bâton a été installé, donc il n'y a rien à quoi revenir en arrière.

C'est l'hôte qui prend le module au mot. Le driver sfp lit l'EEPROM, voit une pièce qui déclare 1000base-x, et fixe eth2 sur inband/1000base-x ; phylink n'a alors aucun mode 2,5G à offrir, ce qui est exactement la sortie ethtool que vous avez postée. Ce que vous réglez à l'intérieur du RTL960x avec LAN_SDS_MODE touche le serdes propre au module, pas ce qu'il annonce au routeur, donc ça n'allait jamais changer le mode négocié.

Deux issues, et je ne connais que ces deux-là. Soit réécrire l'EEPROM du module pour qu'il annonce le 2,5G, ce qui est l'astuce connue sur le DFP-34X-2C3, mais le vôtre est un 2C2 et je ne présumerais pas des mêmes offsets. Soit patcher l'hôte : ajouter un quirk pour ce module dans sfp.c et faire tourner un kernel avec ça, en laissant le bâton intact.

Tout bien pesé, je patcherais l'hôte. Une EEPROM briquée sur un bâton qu'on ne peut pas facilement reflasher est un bien pire après-midi qu'un kernel qu'on peut annuler.

Une autre raison de garder l'hôte sous suspicion plutôt que le module. Sur les snapshots OpenWrt, il y a eu une période où le code générique de validation phylink rétroporté a carrément cassé la cage SFP de l'Omnia : ethtool annonçait toujours 2500baseX/Full et le port rapportait juste Link detected: no. Ça a été isolé proprement à ce commit du kernel, retirer le rétroportage a ramené le lien à 2500Mb/s full duplex, et un correctif de suivi a clos le sujet.

Symptôme différent du vôtre, même leçon. Sur les cartes mvneta et phylink, le logiciel hôte décide de ce que la cage est autorisée à faire, et ça paie de garder une image connue bonne comme filet de sécurité avant de commencer à construire la sienne.

Si vous partez sur la voie du kernel personnalisé sur Turris OS, prenez d'abord un instantané : schnapps create "Before new kernel", puis opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk et redémarrez. Si le kernel se comporte mal, vous revenez en arrière au lieu de démonter le routeur.

La seconde chose que personne ne mentionne avant coup : un lien 2,5 Gbps n'est pas 2,5 Gbps de trafic. Le CPU Armada de l'Omnia ne poussera pas ça sur une seule queue, donc prévoyez du packet steering et du réglage RPS avant que le chiffre sur le câble ne se transforme en débit.

Piège sans rapport pour quiconque d'autre lit ceci avec un bâton différent : certains modules PON font tourner leur propre système d'exploitation et ont besoin d'environ une minute avant de répondre du tout, donc sur un démarrage à froid le routeur sonde la cage trop tôt et retombe sur l'électronique cuivre. fw_setenv bootdelay 60 dans U-Boot est le remède habituel. Pas votre cas, puisque votre module est détecté tout de suite.

Pour boucler la boucle : l'hôte patché a gagné. J'ai construit un kernel avec le sfp.c modifié, pris l'instantané schnapps d'abord, installé l'ipk avec --force-reinstall et redémarré. ethtool eth2 liste maintenant 2500baseX/Full et le lien monte à 2,5 Gbps.

Rien n'a finalement été fait au module. LAN_SDS_MODE est resté où il était et s'est révélé sans importance, donc je n'ai jamais eu besoin de toucher à l'EEPROM.

Le débit a aussi eu besoin du second conseil. Juste après le redémarrage, le boîtier restait bien en dessous du débit de ligne sur une seule queue ; avec le packet steering réglé, le WAN fait enfin ce pour quoi le bâton a été acheté.