La clé GPON DFP-34X-2C2 n'apparaît dans dmesg qu'après des dizaines de secondes puis monte en 1G
Je remplace l'ONT de l'opérateur par une clé SFP GPON sur le boîtier Linux qui termine notre WAN, et la clé ne se comporte absolument pas comme un transceiver. On l'insère et la cage reste silencieuse pendant une trentaine de secondes ou plus, assez longtemps pour que j'aie deux fois cru le module mort, et quand le noyau finit par le remarquer, le lien se stabilise en vitesse gigabit, ce qui va à l'encontre du but de l'exercice.
Le banc :
- boîtier routeur Linux, cage SFP pilotée par la couche SFP du noyau, noyau mainline
- clé GPON ODI DFP-34X-2C2
- une clé Huawei MA5671a comme second échantillon
- un module fibre 1G ordinaire qui apparaît instantanément dans la même cage, donc la cage elle-même n'est pas en cause
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offCe que j'ai essayé jusqu'ici :
- réinsérer la clé et la laisser tranquille plusieurs minutes avant de toucher à l'interface, et l'attente est là à chaque fois, pas seulement à la première insertion
- réactiver l'interface après détection, ce qui ne change rien au mode négocié
- le MA5671a montre la même apparition lente, ce n'est donc pas un échantillon isolé défectueux
Est-ce simplement comme ça que se comportent les clés GPON sur un hôte Linux, ou est-ce que je fais quelque chose de travers de mon côté ? Que se passe-t-il réellement entre l'insertion et la détection ici ?
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 7
Avant de commencer à deviner, deux choses valent la peine d'être précisées. D'abord, postez le dmesg complet dès l'insertion plutôt qu'un grep de deux lignes. Vous dites que la cage est derrière la couche SFP du noyau et je n'ai aucune raison d'en douter, mais les lignes que vous avez filtrées sont celles qui montrent combien de fois le module a été sondé, ce qui a abandonné entre-temps et combien de temps chaque tentative a pris.
Ensuite, que prétend l'interface elle-même pouvoir faire une fois que la clé est enfin up, et est-ce que 2500baseX apparaît quelque part dans les modes annoncés ? Et quel débit le FAI vous fournit-il côté PON, car s'il s'agit d'un forfait gigabit, alors le lien que vous obtenez est le bon et il n'y a rien à corriger.
Comportement attendu, malheureusement, et ce n'est pas votre hôte.
Une clé GPON n'est pas un transceiver avec une puce EEPROM à l'intérieur. C'est un petit ordinateur Linux sur son propre SoC, comprimé dans une coque SFP, et l'EEPROM que votre hôte lit via I2C est émulée par ce système. Rien ne répond sur le bus tant que le firmware propre de la clé n'a pas démarré suffisamment pour servir ces pages, d'où le fait que vous attendiez des dizaines de secondes alors qu'un module normal répond immédiatement. Ce silence avant votre ligne de module, c'est le démarrage.
La seconde moitié de votre problème, c'est que ce qu'annoncent les pages émulées est fréquemment tout simplement faux. L'interface côté hôte sur ces clés est du 2500BASE-X, et l'EEPROM indique autre chose, donc la couche SFP prend ça pour argent comptant et se règle sur le mode gigabit. Les deux moitiés sont traitées dans le noyau via des contournements spécifiques par module plutôt que par quelque chose de configurable, et le DFP-34X-2C2 OEM a récupéré un de ces contournements précisément pour cette raison.
Que votre échantillon en bénéficie dépend des chaînes constructeur et référence qu'il rapporte, et celles-ci diffèrent entre les rebadges, donc comparez ce qu'affiche votre ligne dmesg avec ce que le contournement reconnaît avant de supposer que vous êtes couvert.
Pour souligner pourquoi l'approche par contournement est nécessaire du tout : le SFF-8472 suppose un périphérique mémoire passif qui répond dans des délais I2C ordinaires. Rien dedans n'envisage un appareil qui a besoin d'une demi-minute de démarrage avant de pouvoir parler, donc un hôte qui suit la norme a parfaitement le droit d'abandonner sur le module ou de faire confiance aux bits de mode qu'il finit par lire.
Le point sur les rebadges ci-dessus est le piège pratique. La correspondance se fait sur les chaînes constructeur et référence, donc la même clé physique vendue sous un autre nom rate complètement le contournement et vous vous retrouvez avec un lien gigabit sans raison évidente. Et ne construisez rien qui dépende de la présence du module peu après le démarrage, parce que cette course est ici imperdable.
Espérer que les fournisseurs de clés corrigent le contenu de leur EEPROM est optimiste aussi. Quand ces problèmes ont été soulevés, même de grands FAI n'en ont obtenu que très peu en retour.
Le même type de problème apparaît sur des routeurs grand public, donc au moins vous n'êtes pas seul. Les propriétaires d'Archer BE800, BE900 et GE800 avec une clé dans le port combo SFP+ 10G obtiennent 1 Gbit/s au lieu des 2,5 payés, et la propre liste de TP-Link des clés signalées comme fonctionnant dans ces ports est l'ODI DFP-34X-2C2, le Huawei MA5671A et le Nokia G-010SA, la même courte liste de pièces sur laquelle tout le monde finit par tomber.
Le premier conseil là-bas était firmware plus réinsertion, et la partie réinsertion n'est pas absurde, un module qui ne s'est pas enclenché complètement retombe effectivement en repli. Des versions bêta ont fini par exposer la configuration du port, une par modèle :
Avec l'une d'elles sur le boîtier, le mode du port SFP devient réglable via telnet, interface d'abord désactivée,
ip link set eth1 downet ainsi de suite.Reste un contournement et pas une correction, cela dit. Un an plus tard, les mêmes plaintes revenaient, et pas seulement à propos de clés : une personne avait un AOC JT-AOC-SFP-15 de JT-COM dans ce port, une autre un DAC SFP+ 10G passif d'Ampcom, et les deux étaient bloqués à 1 Gbit/s.
Ça vaut le coup de connaître l'autre mode de défaillance avant que quelqu'un ne suggère de déplacer la clé sur une carte réseau. Sous OpenWrt 19.07 sur x86 avec une Intel X520 et kmod-ixgbe, un MA5671a est simplement refusé comme SFP non supporté. Régler allow_unsupported_sfp via les fichiers de configuration de module habituels ne fait strictement rien là, le paramètre doit être donné au moment du chargement du module :
Et même avec ça, le pilote le rejette quand même, parce que l'EEPROM de la clé ne décrit pas du tout un transceiver normal au départ et l'option ne peut pas masquer ça. Si vous finissez sur une carte réseau, prouvez d'abord le port avec un module 1000BASE-T, LX ou SX ordinaire, sinon vous déboguez la carte et la clé en même temps.
Attention à ne pas mélanger les deux, cependant. allow_unsupported_sfp vit à l'intérieur d'ixgbe et décide si ce pilote est disposé à piloter une optique donnée, ce qui est une décision différente de celle prise ici. La longue attente et le mauvais mode viennent de la couche SFP générique qui lit les pages émulées et transmet le résultat à phylink, et c'est là que se trouvent les contournements par module.
Sur une carte avec une vraie cage SFP, le drapeau ixgbe n'existe pas et n'est pas la solution, et sur une X520 la liste de contournements ne vous sauvera pas non plus. Même symptôme en surface, couche différente en dessous, et les confondre est la façon dont les gens finissent par reconstruire des pilotes pour rien.
Encore une limite à tracer tant qu'on y est : faire voir la clé par l'hôte et la faire accepter par l'OLT sont des problèmes indépendants, et le second peut être bien pire.
Il existe un cas bien documenté d'un Xicom DFP-34X-2C2 chargé avec l'identité copiée d'un ZTE ZXHN F601 via setmac et des requêtes OMCI, numéro de série GPON, mot de passe PLOAM, LOID, numéro de série matériel et chaîne de firmware, tout y est passé. La clé atteint l'état O5 puis reste bloquée là, aucun ID d'ONU assigné et aucun trafic, parce qu'atteindre O5 signifie seulement que le ranging a fonctionné, alors que le téléchargement de la MIB doit encore correspondre au profil d'ONT attendu par l'OLT. Personne dans ce fil n'a produit de solution.
Donc quand vous obtenez enfin du 2500BASE-X en local, ne présumez pas que la partie difficile est derrière vous. Là où l'opérateur lie un profil de service à un modèle d'ONT précis, il se peut qu'aucun jeu de champs copiés ne fasse accepter une clé tierce.