Un bâtonnet ONU GPON FS dans une cage SFP+ d'UDM-Pro : aucun moyen d'atteindre son IP de gestion pour y écrire le numéro de série
Installation domestique, j'essaie de me débarrasser du routeur du FAI sur une ligne GPON Cosmote. L'idée est de faire arriver la fibre directement dans l'UDM-Pro et de laisser le bâtonnet faire le travail d'ONU, mais le fournisseur n'accepte la session que si le numéro de série à 12 caractères et la chaîne de modèle de l'ancien CPE sont présentés, donc je dois entrer dans le module pour écrire les deux.
- Ubiquiti UDM-Pro, bâtonnet dans le port SFP+ 10
- bâtonnet ONU GPON FS avec MAC SFP, référence 133619
- cordon de brassage SC/APC vers SC/APC depuis la prise murale
- l'ancien CPE encore sur le bureau comme référence pour le numéro de série et la chaîne de modèle
Mon problème est plus basique que le clonage lui-même : je n'arrive pas du tout à atteindre le module. Depuis le shell de la gateway, rien ne répond à son adresse de gestion.
ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10La seconde commande reste juste plantée jusqu'à abandonner. Pas de bannière, pas de connexion refusée, rien.
Ce que j'ai déjà fait :
- réinséré le bâtonnet et changé le cordon de brassage, le module s'allume et sa LED se comporte normalement
- vérifié que rien sur l'UDM-Pro n'utilise 192.168.1.0/24, mon LAN vit sur un autre sous-réseau
- envisagé de créer un VLAN de gestion dédié pour la cage, mais c'est beaucoup de plomberie pour une seule écriture
Y a-t-il un moyen d'adresser directement la cage SFP depuis le shell de l'UDM-Pro pour me connecter au bâtonnet et écrire le numéro de série et l'identifiant de l'appareil, sans monter un VLAN séparé pour ça ?
Comments 4
Deux choses distinctes vous bloquent, et aucune des deux n'est le module.
D'abord, l'adressage. La cage SFP est une interface normale sur l'UDM-Pro, numérotée comme le numéro de port affiché moins un, donc le port 10 est eth9. Donnez à la gateway une adresse dans le sous-réseau du module et assurez-vous que les réponses en sont bien issues :
Après ça, 192.168.1.10 répond depuis le shell de la gateway.
Ensuite, la négociation. Le firmware de ces bâtonnets est assez ancien pour que sa liste d'échange de clés s'arrête aux algorithmes historiques, donc il faut en nommer un explicitement :
Une fois dedans, le numéro de série du FAI s'écrit avec
set_serial_number AVMGXXXXXXXXet la chaîne de modèle de l'appareil se clone avecsfp_i2c -i7 -s. Redémarrez le bâtonnet et vérifiez ce qui a réellement tenu :Deux mises en garde. Rien de tout cela n'est une configuration supportée - vous ajoutez à la main une adresse et une règle NAT sur un appliance, donc traitez ça comme une plomberie temporaire pour la session de programmation et gardez l'ancien CPE jusqu'à ce que la ligne s'authentifie. L'autre moitié de l'avertissement concerne le débit : le 2,5 Gbit n'est pas quelque chose que cette plateforme acceptera d'elle-même, donc même un module qui annonce 2,5G finira apparié soit en 1G soit en 10G. Si vous préférez ne pas toucher du tout à la gateway, l'alternative est de programmer le bâtonnet dans une autre machine avec un port SFP routé et de le déplacer ensuite.
Comment la gateway elle-même appelle-t-elle cette cage ? Sur cette machine, les ports SFP sont des interfaces ordinaires, mais le nommage ne correspond pas aux numéros imprimés sur la face avant, donc il est facile d'envoyer des paquets par quelque chose qui n'est pas du tout la cage - et depuis le shell, ça ressemble exactement à ce que vous avez, une session qui reste plantée sans rien de l'autre côté.
Collez la liste des interfaces depuis le shell de la gateway. Une fois qu'on sait clairement quelle interface correspond à ce port, la partie adressage est la moitié facile.
eth9 était exactement ça, port 10 moins un. L'adresse plus la règle SNAT ont fait répondre 192.168.1.10 dès le premier essai, et l'option d'échange de clés historique était l'autre moitié : sans ce drapeau mon client abandonnait pendant la négociation, avec lui j'ai obtenu directement l'invite ONTUSER.
J'ai écrit le numéro de série avec
set_serial_number AVMGXXXXXXXX, cloné la chaîne de modèle avecsfp_i2c -i7 -s, redémarré, etfw_printenv | grep nSerialrenvoie bien la valeur que j'ai définie. La ligne s'est authentifiée quelques minutes plus tard et l'ancien CPE est maintenant débranché.Une chose confirmée à la dure : le port est monté à 1G, exactement comme averti à propos du 2,5G sur cette cage. Ça convient pour le profil que me donne le FAI ici.
Même travail, pièces différentes, et c'est le numéro de série qui devient désagréable. Je déplaçais une identité Calix GigaPoint 801Gv2 sur un bâtonnet G-010S-A avec ritool :
Le numéro de série de l'ONT est 372010010470, mais le module l'a rejournalisé comme
un zéro en moins. La raison tient à la disposition du champ : le numéro de série GPON fait 8 octets, les quatre premiers contiennent l'ID vendeur en caractères ASCII (3720 lu littéralement comme quatre lettres) et les quatre derniers contiennent la partie numérique compactée en hexadécimal. Une queue décimale comme 10010470 ne rentre pas chiffre par chiffre, c'est pour ça que l'écho perd un caractère.
Donc avant de déclarer victoire, vérifiez d'abord comment votre fournisseur enregistre l'ONT - numéro de série ou SLID / ID d'enregistrement. Écrire seulement le numéro de série n'est pas toujours ce sur quoi ils font correspondre.