La clé ALLNET ALL4781-VDSL2-SFP dans un Turris Omnia se resynchronise toutes les 30 à 120 minutes
J'ai finalement retiré ma ligne VDSL2 du boîtier du FAI et je l'ai terminée directement sur le Turris Omnia, surtout pour que le PPPoE tourne sur le routeur plutôt que sur un second appareil en mode bridge. La partie configuration a été agréable : on insère la clé dans la cage et l'interface WAN bascule simplement sur le module, laissant la prise métallique hors jeu, avec le lien interne qui monte tout seul. La LED verte suit la synchronisation DSL, l'orange le côté face au routeur.
- Turris Omnia, PPPoE configuré sur l'interface face au modem
- Clé modem ALLNET ALL4781-VDSL2-SFP dans la cage SFP
- Ligne VDSL2 qui s'entraîne aux pleins 100 Mbit en descendant
option ifname 'eth1.7', parce que ma ligne veut le tag VLAN 7
Dix minutes de configuration plus un redémarrage et c'était monté au débit de la ligne. Le problème, c'est que ça ne reste pas monté. Quelque part entre une demi-heure et deux heures, le DSL se désynchronise, et il lui faut deux à trois minutes pour revenir :
LCP terminated by peer
Modem hangup
eth1: link is downCe que j'ai déjà fait :
- réinséré la clé et redémarré le routeur, l'intervalle ensuite est le même
- échangé le câble de brassage DSL et déplacé la clé vers la première prise de la ligne
- débranché le câble WAN cuivre pour que rien ne se dispute l'interface
Rien de tout ça ne change le schéma. Est-ce la clé, ma ligne, ou la façon dont l'Omnia pilote la cage ? Quelqu'un fait-il tourner cette clé modem sur le long terme sans resynchronisations ?
Comments 4
C'est la mauvaise combinaison connue : firmware 3.4 sur une ligne qui peut réellement faire 100 Mbit. La clé n'est pas cassée en tant que telle - un autre Omnia que je connais fait tourner le même module sur une ligne VDSL2 profil 17a depuis longtemps et ne s'est jamais resynchronisée une seule fois, ce qui explique pourquoi les retours sur cette chose se répartissent comme ils le font. Quelle ligne tombe dans quel groupe n'est pas quelque chose que vous pouvez lire sur une fiche technique à l'avance.
Deux choses, dans cet ordre.
D'abord, allez voir le fabricant au sujet du firmware. Ils ont reconnu que la 3.4 se comportait mal quand la ligne peut atteindre 100 Mbit, et la version plus récente ne coûte rien, donc rien n'empêche de la faire tourner.
Ensuite, continuez à surveiller les LED après ça. Le vert qui s'éteint en premier signifie DSL, l'orange signifie le côté cage. Si le vert continue à tomber sur la nouvelle version, le firmware n'était pas toute l'histoire sur votre ligne.
Pour être honnête sur le résultat, puisque vous allez le demander de toute façon : je connais au moins une ligne où la mise à jour n'a rien changé et les resynchronisations ont continué au même rythme de trente minutes à deux heures. La stabilité avec cette clé semble dépendre autant des caractéristiques de la ligne que de la version, donc traitez le firmware comme la chose la moins coûteuse à essayer plutôt qu'une correction garantie. Si ça continue à tomber après ça, le recours peu glorieux est de remettre un modem devant et de garder la session PPPoE sur le routeur via
eth1.7- vous gardez la config que vous avez déjà et vous arrêtez de poursuivre la synchronisation.Quel firmware est sur la clé ? Il y a plus d'une version en circulation et elles ne se comportent pas de la même façon sur des lignes rapides, donc c'est la première chose à préciser.
Deux choses de plus avant d'accuser le routeur. Au moment où ça tombe, la LED verte s'éteint-elle, ou reste-t-elle allumée pendant que l'orange bouge ? Ça vous dit si la synchronisation DSL est perdue ou seulement le lien vers l'Omnia. Et pouvez-vous tirer quelque chose d'utile de la clé elle-même dans les minutes précédant une chute - débit atteignable, marge SNR, compteurs d'erreurs ? Une synchronisation qui garde son débit jusqu'à la seconde où elle meurt se lit très différemment d'une qui rampe vers le bas d'abord.
Firmware 3.4 sur la clé.
Je me suis assis à côté du boîtier et j'ai attrapé trois chutes de suite : le vert s'éteint en premier, l'orange reste allumé tout du long. Donc le lien vers le routeur ne bouge jamais, c'est la synchronisation DSL qui meurt et la session PPPoE la suit dans sa chute. Ça fait aussi de
LCP terminated by peerune conséquence plutôt qu'une cause, ce que je soupçonnais mais n'avais pas prouvé.Côté compteurs, je n'ai rien à vous donner. Débit atteignable, marge, comptes d'erreurs - la clé n'en expose rien nulle part où je puisse trouver, et le routeur me montre le débit de synchronisation et rien d'autre. Ce chiffre reste au débit de la ligne jusqu'à la seconde où il disparaît, donc rien ne rampe vers le bas d'abord, ça part simplement. Le profil n'a pas changé non plus depuis que le modem du FAI était devant la ligne.
Clé différente, même cage, bon à savoir pendant vos tests.
J'avais une clé GPON HALNy HL-GSFP dans un Omnia : le noyau l'a reconnue sans problème, le port est passé en inband/1000base-x, puis eth2 est resté down pour toujours. Un problème de timing, pas de compatibilité. Le module embarque son propre petit OS et veut près d'une minute avant de répondre à quoi que ce soit, alors que la cage est sondée quelques secondes après la mise sous tension. La sonde ne trouve personne, le routeur reste tranquillement sur le WAN métallique et l'interface SFP ne se réveille jamais.
fw_setenv bootdelay 60dans u-boot a réglé ça définitivement.Ça n'expliquera pas une resynchronisation en plein milieu d'une session, donc ce n'est pas votre réponse. Mais si vous redémarrez un jour après une chute et vous retrouvez sur le cuivre, c'est ce mécanisme que vous observez, pas un module mort.