Un ODI DFP-34X-2C2 dans un Turris Omnia ne monte qu'en 1000base-x, ethtool refuse la vitesse 2500
J'ai remplacé l'ONU du FAI par une clé GPON ODI DFP-34X-2C2 dans mon Turris Omnia pour que la fibre se termine dans le routeur plutôt que dans un autre boîtier sur l'étagère. Cette partie a fonctionné : la ligne est enregistrée, le trafic passe, aucune plainte. Le problème, c'est le débit. Il ne dépasse jamais 1 Gbit/s, et le 2,5G était toute la raison pour laquelle j'ai acheté cette clé.
- Turris Omnia, TurrisOS 6.0.4
- clé GPON ODI DFP-34X-2C2 dans la cage SFP, eth2
- WAN cuivre débranché, la cage possède le port
Ce que dit le noyau après un démarrage, et ce qui se passe quand j'essaie de forcer le débit :
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 avec le lien up montre le module en 1000baseX/Full et rien de plus, et le refus ci-dessus, c'est ethtool qui me dit que la vitesse 2500 ne peut pas être annoncée.
Déjà essayé :
- telnet dans la clé et réglage du débit depuis son propre shell ; elle accepte la commande puis revient à 1 Gbit/s
- redémarrages avec et sans le WAN cuivre branché
- parcouru dmesg pour trouver quoi que ce soit indiquant que le MAC se voit proposer du 2,5G, il n'y a rien
Est-ce le routeur qui plafonne le port, ou le module lui-même ? Et y a-t-il quelque chose côté hôte qui ferait monter eth2 en 2500base-x avec cette clé ?
Comments 5
Le plafond ici, c'est le module lui-même, pas l'Omnia.
Ce avec quoi l'hôte négocie, c'est ce que l'EEPROM du module déclare qu'il sait faire, parce qu'au moment du sondage, cette puce est la seule chose sur laquelle la cage peut se baser. Sur cette clé, c'est codé pour 1000 Mbps. Le port est donc configuré en inband/1000base-x, il n'y a pas de mode 2500base-x à proposer à phylink, et ethtool refuse la vitesse 2500 parce qu'il n'y a rien avec quoi l'annoncer. Aucun réglage côté hôte ne contourne ça : ethtool ne peut demander que des modes dont on a dit au port qu'ils existent. Le shell à l'intérieur de la clé configure le côté PON du module, pas ce que la cage annonce vers le MAC, ce qui explique exactement pourquoi votre changement par telnet s'évapore et que vous retombez à 1 Gbit/s.
Il reste deux vraies options : faire recoder le module pour qu'il annonce du 2,5G, ou le remplacer par un qui le fait déjà. Si vous partez sur le recodage, gardez un module de rechange sous la main. Vous réécrivez la page d'identité en laquelle l'hôte a confiance, et un mauvais octet à cet endroit vous donne un module que la cage cesse totalement de reconnaître. Gardez aussi les deux débits séparés dans votre tête, ce que le côté PON délivre et ce que le lien SFP-vers-MAC négocie sont deux chiffres distincts, donc déterminez ce que vous gagnez réellement avant de dépenser de l'argent là-dessus.
Avant d'accuser la clé, vérifiez quel device tree le boîtier démarre. La cage sur un Omnia n'est pas une interface supplémentaire : elle et la moitié WAN métallique sont deux façades avant sur un seul et même eth2, et une seule d'entre elles est réellement connectée au MAC à la fois. Laquelle, ça dépend du dtb que le noyau charge au démarrage. Regardez donc vers quoi pointe /boot/dtb : si ce n'est pas armada-385-turris-omnia-sfp.dtb, vous regardez le côté cuivre et les chiffres ne veulent rien dire.
Postez aussi le dmesg | grep -i sfp complet, pas juste la ligne mvneta. Ce que le noyau lit dans le module au moment du sondage est la partie intéressante ici, et ça règle en général la question en une ligne.
Le dtb est déjà celui du SFP, j'ai symlinké armada-385-turris-omnia-sfp.dtb dès que j'ai mis la clé en place, sinon rien ne montait du tout. La cage possède eth2 et le WAN cuivre reste débranché.
dmesg | grep -i sfp montre le module identifié puis la même ligne que j'ai postée, eth2 switched to inband/1000base-x link mode. Rien sur du 2500 nulle part. ethtool eth2 rapporte 1000baseX/Full pendant que le lien est up et passe du trafic, et ethtool -s eth2 speed 2500 revient toujours avec Invalid argument, donc ça n'annoncera jamais 2500. Régler le débit via telnet dans la clé se comporte comme avant, ça l'accepte puis ça retombe à 1 Gbit/s.
Histoire connexe sur la même carte, au cas où quelqu'un arrive ici avec une clé qui ne monte pas du tout plutôt qu'une bloquée à 1G. Un HALNy HL-GSFP dans un Omnia sous Turris OS HBS 6.2.4 : le noyau l'a identifiée, le port est même passé en inband/1000base-x, puis le lien est tombé et eth2 n'est jamais monté.
Ce n'est pas un problème d'EEPROM. Il y a tout un petit OS qui vit dans cette clé, et elle veut environ une minute pour elle-même avant d'être en état de répondre à l'hôte. Au démarrage à froid, le routeur a sondé la cage et a abandonné bien avant ce moment-là, donc le port retombe sur l'électronique cuivre. Allonger le délai d'U-Boot a corrigé ça ici :
Par défaut c'est 3 secondes ; à 60, la clé a fini de démarrer au moment où le noyau sonde enfin la cage. Débrancher le WAN cuivre et redémarrer une seconde fois a aussi aidé à la détection. Et si jamais vous devez regarder à l'intérieur d'une clé, le port série dessus est en 38400 8N1.
D'accord avec le diagnostic, avec une réserve pour quiconque arrive ici avec un symptôme similaire. Tous les « ça ne fait pas de 2,5G » sur cette carte ne sont pas le module. Il y a eu un snapshot OpenWrt où le code générique de validation de phylink a été rétroporté, et ça a purement et simplement cassé la cage de l'Omnia : ethtool annonçait toujours 2500baseX/Full mais rapportait Link detected: no. Revenir en arrière sur ce rétroportage a remis le port dans l'état où il était, ethtool lisant Link detected: yes, 2500Mb/s full duplex, et une pull request ultérieure a réglé le rétroportage en amont.
Le signe distinctif est dans ce qu'ethtool liste comme supporté et annoncé. Si 2500baseX/Full y figure et que le lien refuse simplement de monter, regardez du côté du noyau et de phylink après votre dernière mise à jour d'image, pas de l'optique. Si, comme ici, le port ne connaît jamais que du 1000baseX parce que c'est ce que le module a déclaré sur lui-même, aucun logiciel côté hôte ne fera apparaître le mode. C'est l'octet de débit binaire nominal dans l'EEPROM qui fait exactement ce que SFF-8472 dit qu'il doit faire.