FS GPON ONU stick in a UDM-Pro SFP+ cage: no way to reach its management IP to write the serial
Home setup, and I am trying to get rid of the ISP router on a Cosmote GPON line. The idea is to run the fibre straight into the UDM-Pro and let the stick do the ONU job, but the provider only accepts the session if the 12-character serial and the device model string of the old CPE are presented, so I have to get inside the module and write both.
- Ubiquiti UDM-Pro, stick sitting in SFP+ port 10
- FS GPON ONU stick with MAC SFP, item 133619
- SC/APC to SC/APC patch cord from the wall socket
- old CPE still on the desk as the rfeerence for serial and model string
My problem is more basic than the cloning itself: I cannot reach the module at all. From the gateway shell nothing answers on its management address.
ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10The second command just sits there until it gives up. No banner, no refused connection, nothing.
What I already did:
- reseated the stick and swapped the patch cord, the module powers up and its LED behaves
- made sure nothing on the UDM-Pro is using 192.168.1.0/24, my LAN lives on a different subnet
- looked at building a dedicated management VLAN for the cage, but that is a lot of plumbing for one write
Is there a way to address the SFP cage directly from the UDM-Pro shell so I can log into the stick and write the serial and device ID, without standing up a separate VLAN for it?
Comments 4
Two separate things are in your way, and neither of them is the module.
First, addressing. The SFP cage is a normal interface on the UDM-Pro, numbered as the displayed port number minus one, so port 10 is eth9. Give the gateway an address inside the module's subnet and make sure the replies are sourced from it:
After that 192.168.1.10 answers from the gateway shell.
Second, the handshake. Firmware on these sticks is old enough that its key exchange list stops at the legacy algorithms, so you have to name one explicitly:
Once you are in, the ISP serial goes in with
set_serial_number AVMGXXXXXXXXand the device model string is cloned withsfp_i2c -i7 -s. Reboot the stick and check what actually stuck:Two caveats. None of this is a supported configuration - you are hand-adding an address and a NAT rule on an appliance, so treat it as temporary plumbing for the programming session and keep the old CPE until the line authenticates. The other half of the warning is about rate: 2.5 Gbit is not something this platform will agree to on its own, so even a module that advertises 2.5G ends up pareed at either 1G or 10G. If you would rather not touch the gateway at all, the alternative is to program the stick in another box with a routed SFP port and move it over afterwards.
What does the gateway itself call that cage? On this box the SFP ports are ordinary interfaces, but the naming does not line up with the numbers printed on the front panel, so it is easy to be pushing packets out of something that is not the cage at all - and from the shell that looks exactly like what you got, a session sitting there with nothing on the other end.
Paste the interface list from the gateway shell. Once it is clear which interface belongs to that port, the addressing part is the easy half.
eth9 was exactly it, port 10 minus one. The address plus the SNAT rule made 192.168.1.10 answer on the first try, and the legacy key exchange option was the other half of it: without that fag my client gave up during the handshake, with it I got the ONTUSER prompt straight away.
Wrote the serial with
set_serial_number AVMGXXXXXXXX, cloned the model string withsfp_i2c -i7 -s, rebooted, andfw_printenv | grep nSerialgives back the value I set. The line authenticated a few minutes later and the old CPE is now unplugged.One thing confirmed the hard way: the port came up at 1G, exactly as warned about 2.5G on this cage. Fine for the profile the ISP gives me here.
Same job, different parts, and the serial is where it turns nasty. I was moving a Calix GigaPoint 801Gv2 identity onto a G-010S-A stick with ritool:
The ONT serial is 372010010470, but the module logged it back as
one zero short. The reason is the field layout: the GPON serial is 8 bytes, the first four hold the vendor ID as ASCII characters (3720 read literally as four letters) and the last four hold the numeric part packed as hex. A decimal tail like 10010470 does not go in digit for digit, which is why the echo loses a character.
So before declaring victory, check how your provider registers the ONT in the first place - serial or SLID / registration ID. Writing the serial alone is not always what they match on.