Stick ONU GPON FS in una cage SFP+ dell'UDM-Pro: nessun modo di raggiungere il suo IP di gestione per scrivere il seriale
Setup domestico, e sto cercando di togliermi di torno il router dell'ISP su una linea GPON Cosmote. L'idea è far entrare la fibra dritta nell'UDM-Pro e lasciare che lo stick faccia il lavoro di ONU, ma il provider accetta la sessione solo se vengono presentati il seriale a 12 caratteri e la stringa del modello del vecchio CPE, quindi devo entrare nel modulo e scrivere entrambi.
- Ubiquiti UDM-Pro, stick nella porta SFP+ 10
- stick ONU GPON FS con MAC SFP, articolo 133619
- bretella SC/APC a SC/APC dalla presa a muro
- vecchio CPE ancora sulla scrivania come riferimento per seriale e stringa modello
Il mio problema è più di base della clonazione in sé: non riesco proprio a raggiungere il modulo. Dalla shell del gateway non risponde nulla sul suo indirizzo di gestione.
ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10Il secondo comando resta lì fermo finché non rinuncia. Nessun banner, nessuna connessione rifiutata, niente.
Cosa ho già fatto:
- riseduto lo stick e cambiata la bretella, il modulo si accende e il suo LED si comporta normalmente
- controllato che niente sull'UDM-Pro usi 192.168.1.0/24, la mia LAN vive su una subnet diversa
- valutato di costruire una VLAN di gestione dedicata per la cage, ma è un sacco di impianto per una sola scrittura
C'è un modo per indirizzare la cage SFP direttamente dalla shell dell'UDM-Pro così posso loggarmi nello stick e scrivere il seriale e il device ID, senza tirare su una VLAN separata apposta?
Comments 4
Ci sono due cose separate sulla tua strada, e nessuna delle due è il modulo.
Primo, l'indirizzamento. La cage SFP è un'interfaccia normale sull'UDM-Pro, numerata come il numero di porta mostrato meno uno, quindi la porta 10 è eth9. Dai al gateway un indirizzo dentro la subnet del modulo e assicurati che le risposte siano sorgenti da lì:
Dopo di che 192.168.1.10 risponde dalla shell del gateway.
Secondo, l'handshake. Il firmware su questi stick è abbastanza vecchio che la sua lista di key exchange si ferma agli algoritmi legacy, quindi devi nominarne uno esplicitamente:
Una volta dentro, il seriale dell'ISP si scrive con
set_serial_number AVMGXXXXXXXXe la stringa del modello del dispositivo si clona consfp_i2c -i7 -s. Riavvia lo stick e controlla cosa è rimasto davvero:Due avvertenze. Niente di tutto questo è una configurazione supportata - stai aggiungendo a mano un indirizzo e una regola NAT su un apparato, quindi trattalo come impianto temporaneo per la sessione di programmazione e tieni il vecchio CPE finché la linea non si autentica. L'altra metà dell'avvertimento riguarda la velocità: 2.5 Gbit non è qualcosa che questa piattaforma accetterà da sola, quindi anche un modulo che annuncia 2.5G finisce accoppiato o a 1G o a 10G. Se preferisci non toccare affatto il gateway, l'alternativa è programmare lo stick in un altro box con una porta SFP instradata e spostarlo lì dopo.
Come chiama il gateway stesso quella cage? Su questo box le porte SFP sono interfacce normali, ma la denominazione non corrisponde ai numeri stampati sul pannello frontale, quindi è facile star spingendo pacchetti fuori da qualcosa che non è affatto la cage - e dalla shell questo sembra esattamente quello che hai ottenuto, una sessione ferma lì senza niente dall'altro lato.
Incolla la lista delle interfacce dalla shell del gateway. Una volta chiaro quale interfaccia appartiene a quella porta, la parte dell'indirizzamento è la metà facile.
eth9 era esattamente quello, porta 10 meno uno. L'indirizzo più la regola SNAT hanno fatto rispondere 192.168.1.10 al primo tentativo, e l'opzione di key exchange legacy era l'altra metà: senza quel flag il mio client rinunciava durante l'handshake, con quello ho avuto subito il prompt ONTUSER.
Scritto il seriale con
set_serial_number AVMGXXXXXXXX, clonata la stringa del modello consfp_i2c -i7 -s, riavviato, efw_printenv | grep nSerialrestituisce il valore che ho impostato. La linea si è autenticata qualche minuto dopo e il vecchio CPE ora è staccato.Una cosa confermata nel modo duro: la porta è salita a 1G, esattamente come avvisato riguardo al 2.5G su questa cage. Va bene per il profilo che l'ISP mi dà qui.
Stesso lavoro, componenti diversi, ed è il seriale il punto dove si mette male. Stavo spostando un'identità Calix GigaPoint 801Gv2 su uno stick G-010S-A con ritool:
Il seriale dell'ONT è 372010010470, ma il modulo lo ha loggato di ritorno come
uno zero in meno. Il motivo è il layout dei campi: il seriale GPON è di 8 byte, i primi quattro tengono il vendor ID come caratteri ASCII (3720 letto letteralmente come quattro lettere) e gli ultimi quattro tengono la parte numerica impacchettata come hex. Una coda decimale come 10010470 non ci entra cifra per cifra, ed è per questo che l'eco perde un carattere.
Quindi prima di dichiarare vittoria, controlla come il tuo provider registra l'ONT in primo luogo - seriale oppure SLID / registration ID. Scrivere solo il seriale non è sempre quello su cui fanno il match.