FS-GPON-ONU-Stick im SFP+-Käfig einer UDM-Pro: kein Weg zur Management-IP, um die Seriennummer zu schreiben
Heimaufbau, und ich versuche, den ISP-Router an einer Cosmote-GPON-Leitung loszuwerden. Die Idee ist, die Faser direkt in die UDM-Pro zu führen und den Stick die ONU-Arbeit machen zu lassen, aber der Provider akzeptiert die Session nur, wenn die zwölfstellige Seriennummer und der Gerätemodell-String des alten CPE vorgelegt werden, ich muss also in das Modul rein und beides schreiben.
- Ubiquiti UDM-Pro, Stick sitzt in SFP+-Port 10
- FS-GPON-ONU-Stick mit MAC SFP, Artikel 133619
- SC/APC-zu-SC/APC-Patchkabel von der Wanddose
- altes CPE noch auf dem Tisch als Referenz für Seriennummer und Modell-String
Mein Problem ist grundlegender als das Klonen selbst: Ich erreiche das Modul überhaupt nicht. Aus der Gateway-Shell antwortet nichts auf seiner Management-Adresse.
ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10Der zweite Befehl sitzt einfach da, bis er aufgibt. Kein Banner, keine abgelehnte Verbindung, nichts.
Was ich schon gemacht habe:
- den Stick neu gesteckt und das Patchkabel getauscht, das Modul geht an und seine LED verhält sich normal
- sichergestellt, dass nichts auf der UDM-Pro 192.168.1.0/24 benutzt, mein LAN liegt in einem anderen Subnetz
- überlegt, ein eigenes Management-VLAN für den Käfig zu bauen, aber das ist eine Menge Aufwand für ein einziges Schreiben
Gibt es einen Weg, den SFP-Käfig direkt aus der UDM-Pro-Shell anzusprechen, damit ich mich in den Stick einloggen und Seriennummer und Geräte-ID schreiben kann, ohne dafür ein eigenes VLAN aufzusetzen?
Comments 4
Zwei getrennte Dinge stehen dir im Weg, und keins davon ist das Modul.
Erstens die Adressierung. Der SFP-Käfig ist ein normales Interface auf der UDM-Pro, nummeriert als die angezeigte Portnummer minus eins, Port 10 ist also eth9. Gib dem Gateway eine Adresse innerhalb des Subnetzes des Moduls und stell sicher, dass die Antworten von dort kommen:
Danach antwortet 192.168.1.10 aus der Gateway-Shell.
Zweitens der Handshake. Die Firmware auf diesen Sticks ist alt genug, dass ihre Key-Exchange-Liste bei den Legacy-Algorithmen endet, du musst also einen explizit benennen:
Sobald du drin bist, kommt die ISP-Seriennummer mit
set_serial_number AVMGXXXXXXXXrein, und der Gerätemodell-String wird mitsfp_i2c -i7 -sgeklont. Den Stick neu starten und prüfen, was tatsächlich hängen geblieben ist:Zwei Einschränkungen. Nichts davon ist eine unterstützte Konfiguration - du fügst von Hand eine Adresse und eine NAT-Regel auf einer Appliance hinzu, behandle das also als temporäre Verkabelung für die Programmiersession und behalte das alte CPE, bis die Leitung authentifiziert. Die andere Hälfte der Warnung betrifft die Rate: 2,5 Gbit wird diese Plattform von sich aus nicht mitmachen, selbst ein Modul, das 2,5G anbietet, landet am Ende entweder bei 1G oder bei 10G gepaart. Wenn du das Gateway lieber gar nicht anfassen willst, ist die Alternative, den Stick in einer anderen Box mit geroutetem SFP-Port zu programmieren und ihn danach umzustecken.
Wie nennt das Gateway diesen Käfig eigentlich selbst? Auf dieser Box sind die SFP-Ports gewöhnliche Interfaces, aber die Benennung stimmt nicht mit den auf der Frontblende aufgedruckten Nummern überein, es ist also leicht, Pakete aus etwas herauszuschicken, das gar nicht der Käfig ist - und aus der Shell sieht das genau so aus wie das, was du bekommen hast, eine Session, die dasitzt, ohne dass am anderen Ende etwas ist.
Paste die Interface-Liste aus der Gateway-Shell. Sobald klar ist, welches Interface zu diesem Port gehört, ist die Adressierung die leichte Hälfte.
eth9 war es genau, Port 10 minus eins. Die Adresse plus die SNAT-Regel ließen 192.168.1.10 beim ersten Versuch antworten, und die Legacy-Key-Exchange-Option war die andere Hälfte davon: Ohne dieses Flag gab mein Client beim Handshake auf, damit bekam ich sofort den ONTUSER-Prompt.
Die Seriennummer mit
set_serial_number AVMGXXXXXXXXgeschrieben, den Modell-String mitsfp_i2c -i7 -sgeklont, neu gestartet, undfw_printenv | grep nSerialgibt den Wert zurück, den ich gesetzt habe. Die Leitung authentifizierte ein paar Minuten später, und das alte CPE ist jetzt ausgesteckt.Eine Sache auf die harte Tour bestätigt: Der Port kam mit 1G hoch, genau wie bei diesem Käfig für 2,5G gewarnt. Passt zum Profil, das mir der ISP hier gibt.
Gleiche Aufgabe, andere Teile, und bei der Seriennummer wird es unangenehm. Ich habe eine Calix-GigaPoint-801Gv2-Identität mit ritool auf einen G-010S-A-Stick übertragen:
Die ONT-Seriennummer ist 372010010470, aber das Modul meldete sie zurück als
eine Null zu kurz. Der Grund ist das Feldlayout: Die GPON-Seriennummer ist 8 Byte, die ersten vier halten die Vendor-ID als ASCII-Zeichen (3720 wörtlich als vier Buchstaben gelesen), die letzten vier den numerischen Teil, als Hex gepackt. Ein dezimaler Schwanz wie 10010470 geht nicht Ziffer für Ziffer rein, deshalb verliert das Echo ein Zeichen.
Bevor man also den Sieg verkündet: prüfen, wie der eigene Provider das ONT überhaupt registriert - Seriennummer oder SLID/Registrierungs-ID. Nur die Seriennummer zu schreiben ist nicht immer das, worauf sie matchen.