Le Turris Omnia refuse une clé GPON MA5671A débloquée : eth2 ne monte jamais sous Turris OS 5.0.3
J'essaie de remplacer le terminal du FAI dans mon rack domestique par une clé GPON directement dans le routeur, pour que la fibre arrive dans un seul boîtier au lieu de deux. La clé est reconnue, et c'est là que s'arrêtent les bonnes nouvelles.
- Turris Omnia sous Turris OS 5.0.3, noyau d'origine
- Clé GPON Huawei MA5671A avec firmware débloqué, réglée sur SGMII 1G
- Pigtail SC/APC de la prise murale vers la clé
- eth2 est le port SFP
Le module est détecté mais l'interface ne s'active jamais :
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 reste down après ça, no carrier, rien dans les compteurs.
Ce que j'ai essayé jusqu'ici :
- reflasher la clé avec le firmware d'origine, ce qui me donne à la place une erreur de lecture EEPROM
- forcer le débit avec ethtool -s eth2 1000 autoneg off duplex full, après quoi l'interface reste à 10 Mbit half duplex
- déplacer la même clé dans un routeur MikroTik, où elle monte bien une fois la vitesse de port réglée à la main
Donc le module lui-même est vivant et le côté fibre va bien. Qu'est-ce que dans la clé le noyau conteste, et quelles clés GPON montent réellement sur un Omnia plutôt que d'être refusées ?
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 4
C'est un problème côté hôte, pas un module mort. L'EEPROM de ces clés GPON détournées déclare un encodage que le driver sfp mainline ne saura pas mapper, phylink refuse donc de faire monter le port, et la ligne que vous avez collée est le driver qui le dit précisément. Vos propres constats pointent dans le même sens : la clé identique monte sur un MikroTik une fois la vitesse de port réglée à la main, donc l'optique et le côté PON vont bien.
La seule chose qui a fait bouger les choses pour moi, c'est un noyau assez récent pour porter les bizarreries propres à chaque module, ce qui sur l'Omnia signifiait la branche de test HBD avec le noyau 5.4. Attention, c'est une victoire partielle et ça dépend beaucoup de la clé que vous avez. Sur ce noyau :
Donc si vous voulez que l'Omnia fonctionne maintenant plutôt qu'un jour, la DFP-34G-2C2 est celle que je mettrais dans la cage. Testez-la sur votre propre boîtier avant de vous engager, les résultats varient clairement ici entre clés et même entre révisions de firmware d'une même clé.
Deux choses à préciser avant que quiconque commence à deviner. D'abord, de quelle branche vient cette 5.0.3 et quel noyau rapporte uname ? Les bizarreries SFP propres à chaque module dont ces clés GPON détournées ont besoin sont arrivées plus tard, donc un noyau stable livré et un noyau de test se comportent très différemment avec exactement le même module.
Ensuite, le numéro de série de l'ONU est-il enregistré côté fournisseur ? Une clé qui n'est jamais autorisée sur l'OLT restera là à avoir l'air morte, et beaucoup de fournisseurs refusent carrément d'enregistrer une ONU tierce.
Et quand vous la branchez, le port passe-t-il un jour en inband/1000base-x, ou le journal s'arrête-t-il pile à ce message d'encodage ?
Branche stable, noyau d'origine pour la 5.0.3, rien de personnalisé par-dessus. Le côté fournisseur n'est pas le problème ici, c'est la même fibre et la clé porte le numéro de série enregistré.
Le journal s'arrête à la ligne d'encodage, le port ne bascule jamais en inband/1000base-x. Ce que j'obtiens dépend du firmware. Avec le débloqué :
plus un défaut de transmission signalé par le module. Avec le firmware d'origine, ça ne va même pas jusque-là :
Et comme dit, forcer le débit ne fait absolument rien : après ethtool -s eth2 1000 autoneg off duplex full, l'interface reste toujours à 10 Mbit half duplex.
Un autre mode de panne à écarter sur le même routeur, parce qu'il ressemble à ça mais n'a rien à voir avec l'encodage. Un HALNy HL-GSFP sur Turris OS HBS 6.2.4 a été détecté, le port est même passé en inband/1000base-x, puis le lien est tombé et eth2 est resté down.
Cause : cette clé est un petit ordinateur à part entière. Elle passe environ une minute à démarrer son propre firmware, et ce n'est qu'après ça qu'elle répond quoi que ce soit de sensé à la cage. Un démarrage à froid fait regarder le routeur dans la cage bien avant ce point, donc la détection échoue et le boîtier revient tranquillement sur les magnétiques du WAN cuivre. Allonger le délai de démarrage a réglé ça :
Soixante secondes au lieu des trois par défaut, et quelqu'un d'autre avec la même clé l'a confirmé. Deux autres choses qui ont aidé : débrancher le câble WAN cuivre et redémarrer encore une fois, et se connecter au module lui-même pour voir dans quel état il est, en série à 38400 8N1 ou en SSH sur 192.168.77.154 port 22666.