FS GPON ONU-stick in een UDM-Pro SFP+-cage: geen manier om het management-IP te bereiken om het serienummer te schrijven
Thuisopstelling, en ik probeer van de ISP-router af te komen op een Cosmote GPON-lijn. Het idee is om de fiber rechtstreeks in de UDM-Pro te laten lopen en de stick het ONU-werk te laten doen, maar de provider accepteert de sessie alleen als het serienummer van 12 tekens en de device-modelstring van de oude CPE worden aangeboden, dus moet ik in de module komen om beide te schrijven.
- Ubiquiti UDM-Pro, stick in SFP+-poort 10
- FS GPON ONU-stick met MAC SFP, item 133619
- SC/APC-naar-SC/APC-patchkabel vanaf de wandaansluiting
- oude CPE staat nog op het bureau als referentie voor serienummer en modelstring
Mijn probleem is basaler dan het klonen zelf: ik kan de module helemaal niet bereiken. Vanuit de gateway-shell reageert er niets op het management-adres ervan.
ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10Het tweede commando blijft gewoon hangen tot het opgeeft. Geen banner, geen geweigerde verbinding, niets.
Wat ik al heb geprobeerd:
- de stick opnieuw geplaatst en de patchkabel gewisseld, de module start op en het ledje gedraagt zich normaal
- gecontroleerd dat niets op de UDM-Pro 192.168.1.0/24 gebruikt, mijn LAN zit op een ander subnet
- overwogen een aparte management-VLAN voor de cage te bouwen, maar dat is veel gedoe voor één schrijfactie
Is er een manier om de SFP-cage rechtstreeks vanuit de UDM-Pro-shell aan te spreken, zodat ik op de stick kan inloggen en het serienummer en de device-ID kan schrijven, zonder daar een aparte VLAN voor op te zetten?
Comments 4
Er staan twee losse dingen in de weg, en geen van beide is de module.
Eerst het adresseren. De SFP-cage is een gewone interface op de UDM-Pro, genummerd als het weergegeven poortnummer min een, dus poort 10 is eth9. Geef de gateway een adres binnen het subnet van de module en zorg dat de antwoorden daarvandaan komen:
Daarna antwoordt 192.168.1.10 vanuit de gateway-shell.
Dan de handshake. De firmware op deze sticks is oud genoeg dat de lijst met key-exchange-algoritmes stopt bij de legacy-algoritmes, dus moet je er expliciet een benoemen:
Eenmaal binnen gaat het ISP-serienummer erin met
set_serial_number AVMGXXXXXXXXen wordt de device-modelstring gekloond metsfp_i2c -i7 -s. Herstart de stick en controleer wat er echt is blijven hangen:Twee kanttekeningen. Niets hiervan is een ondersteunde configuratie - je voegt handmatig een adres en een NAT-regel toe aan een appliance, dus behandel het als tijdelijke bekabeling voor de programmeersessie en houd de oude CPE achter de hand tot de lijn authenticeert. De andere helft van de waarschuwing gaat over de snelheid: 2,5 Gbit is niet iets waar dit platform uit zichzelf mee akkoord gaat, dus zelfs een module die 2.5G adverteert eindigt gepaird op 1G of 10G. Als je de gateway liever helemaal niet aanraakt, is het alternatief om de stick in een andere doos met een gerouteerde SFP-poort te programmeren en hem daarna over te zetten.
Hoe noemt de gateway die cage zelf? Op deze doos zijn de SFP-poorten gewone interfaces, maar de naamgeving loopt niet gelijk met de nummers die op het frontpaneel staan, dus het is makkelijk om pakketten naar buiten te sturen via iets dat helemaal niet de cage is - en vanuit de shell ziet dat er precies zo uit als wat jij hebt: een sessie die daar blijft hangen zonder iets aan de andere kant.
Plak de interfacelijst van de gateway-shell erbij. Zodra duidelijk is welke interface bij die poort hoort, is het adresseren het makkelijke deel.
eth9 was hem precies, poort 10 min een. Het adres plus de SNAT-regel zorgde dat 192.168.1.10 meteen bij de eerste poging antwoordde, en de legacy key-exchange-optie was de andere helft ervan: zonder die vlag gaf mijn client het op tijdens de handshake, met de vlag kreeg ik direct de ONTUSER-prompt.
Het serienummer geschreven met
set_serial_number AVMGXXXXXXXX, de modelstring gekloond metsfp_i2c -i7 -s, herstart, enfw_printenv | grep nSerialgeeft de waarde terug die ik heb ingesteld. De lijn authenticeerde een paar minuten later en de oude CPE staat nu los.Eén ding is op de harde manier bevestigd: de poort kwam op met 1G, precies zoals gewaarschuwd over 2.5G op deze cage. Prima voor het profiel dat de ISP mij hier geeft.
Zelfde klus, andere onderdelen, en het serienummer is waar het vervelend wordt. Ik was een Calix GigaPoint 801Gv2-identiteit aan het overzetten naar een G-010S-A-stick met ritool:
Het ONT-serienummer is 372010010470, maar de module logde het terug als
een nul te kort. De reden zit in de veldindeling: het GPON-serienummer is 8 bytes, de eerste vier bevatten de vendor-ID als ASCII-tekens (3720 letterlijk gelezen als vier letters) en de laatste vier bevatten het numerieke deel verpakt als hex. Een decimale staart zoals 10010470 past er niet cijfer voor cijfer in, en daarom verliest de echo een teken.
Dus voordat je de overwinning uitroept: check eerst hoe je provider de ONT registreert - op serienummer of op SLID / registratie-ID. Alleen het serienummer schrijven is niet altijd waar ze op matchen.