Build log · Converge GPON · MikroTik RB5009

Replacing a Converge ONT with a GPON SFP stick

Skyworth GN630V to ODI DFP-34X-2C2 in the RB5009 SFP+ cage: the connector gotcha, VLAN 10 handoff, and the minimum config that actually worked on my line.

Published 17 May 2026

Overview

This is the write-up of replacing my Converge-issued Skyworth GN630V ONT with an ODI DFP-34X-2C2 GPON ONU SFP stick plugged directly into the MikroTik RB5009 SFP+ cage.

Converge fiber
    |
    |  SC/APC house fiber -> SC/APC to SC/UPC patch cord
    v
ODI DFP-34X-2C2 GPON SFP stick
    |
    v
RB5009 sfp-sfpplus1 -> VLAN 10 -> DHCP client -> LAN

The short version: on my line, Converge authenticated the ONU by GPON serial number only. After a factory reset, internet worked with just the original ONT's GPON serial number on the stick and VLAN handling set to transparent. No MAC cloning, model spoofing, software version spoofing, LOID, or PLOAM password was needed for this specific ONT/stick/line combination.

This was inspired by R1BNC's video and his Converge FiberX ONT replacement post. Huge thanks also to the Anime4000/RTL960x project and community work around these Realtek-based ONU sticks.

Disclaimer

This is for educational documentation of my own residential fiber line. It is not a recommendation that you modify ISP equipment, impersonate equipment on a network you do not own, or violate your service agreement.

You are dealing with optical fiber and carrier access equipment. Dirty or damaged fiber ends can degrade service. Looking into active fiber can be dangerous. Incorrect ONU identity, rapid swapping, or misconfiguration can trigger OLT alarms, rogue ONU detection, or an outage for your own service.

You are responsible for your own hardware, service, account standing, and safety. I am not liable for damaged SFP modules, routers, ONTs, fiber connectors, ISP action, downtime, or other consequences. This guide was only tested on the hardware below and on one Converge line. Treat every value as something to verify on your own service before applying it.

Tested Hardware

The connector row matters more than anything else here — it is the trap that kept the stick unused for six months. Full detail, symptoms, and the fix are in the Connector Mismatch section below.

What Actually Mattered

The minimum working stick configuration was:

1flash set GPON_SN <YOUR_GPON_SN> 2flash set VLAN_CFG_TYPE 0 3flash set VLAN_MANU_MODE 0 4reboot

For my line, these were not required:

• ELAN_MAC_ADDR or MAC_KEY cloning
• RouterOS WAN MAC spoofing
• PON_VENDOR_ID, GPON_ONU_MODEL, HW_HWVER, or HW_SERIAL_NO spoofing
• software version spoofing
• OMCI_OLT_MODE override
• LOID
• PLOAM password

The important lesson is not "everyone only needs three commands." The lesson is "prove the minimum before piling on spoofing." My original notes had a full spoof-heavy setup because I relied heavily on R1BNC's guide as my first path through the problem. Factory reset testing later proved that this particular Converge/Skyworth/ODI setup only needed the GPON serial and transparent VLAN behavior.

Connector Mismatch

This was the first real trap, and the funny reason the stick sat unused for about six months: the problem was not the GPON serial, PLOAM, LOID, or model spoofing. It was the UPC/APC connector mismatch.

APC has an angled end face. UPC is flat. The connectors may physically fit, but the optical interface is wrong. In my testing this showed up as weak or missing receive power and failed registration.

What I observed with the mismatched connector:

• GPON registration only reached O3
• Rx power reported as 0

I did not observe other registration states or intermittent internet with the mismatched connector, so treat those as separate clues rather than symptoms proven by this test.

Use a proper SC/APC to SC/UPC patch cord if your SFP stick is UPC — that is the adapter path I tested. A cleaner option is buying the APC variant of the ODI stick, commonly listed as DFP-34X-2C3. Another possible path is an SC/UPC male to SC/APC female adapter, but I did not test that one.

Gather Values

Log in to the original ONT first and write down only what you need. Do not publish these values; a GPON serial number is enough to collide with or clone your line on the same PON.

For the Skyworth GN630V I checked:

I did not find PLOAM, LOID, or LOID password values in the Skyworth admin UI, and I did not need them for this setup. Your line may differ, especially if it is provisioned on different OLT policy.

Configure Stick

Do the first configuration with the fiber disconnected. You only need management access to the SFP stick.

First, insert the ODI stick into the RB5009 SFP+ cage.

The ODI stick management IP is typically 192.168.1.1, with admin as the password. On RouterOS, prepare the SFP+ port and give the SFP interface a static address in the same 192.168.1.0/24 network first:

1/ip address add address=192.168.1.2/24 interface=sfp-sfpplus1

The stick is reachable at 192.168.1.1. RouterOS automatically adds the connected route for 192.168.1.0/24, so no manual route is needed just to reach the management page or SSH service.

The SSH server may require legacy algorithms. My local SSH config entry looks like this:

1Host odi-sfp 2 HostName 192.168.1.1 3 User admin 4 KexAlgorithms +diffie-hellman-group1-sha1 5 HostKeyAlgorithms +ssh-rsa 6 Ciphers +3des-cbc 7 PreferredAuthentications password 8 PubkeyAuthentication no

Before resetting or changing the stick, back up its current flash configuration. The web UI has a backup option, but from a shell I also like capturing flash all to a local file:

1ssh odi-sfp 'flash all' > odi-sfp-flash-backup-$(date +%Y%m%d-%H%M%S).txt

Then factory reset the config partition so the stick starts from a clean baseline. Confirm the config partition's mtd number on your own stick first — the index can differ across stick variants and firmware, and erasing the wrong mtd can brick the module. Check cat /proc/mtd and match the partition labelled for config before running flash_eraseall:

1ssh odi-sfp 2 3cat /proc/mtd # verify which mtd is the config partition 4flash_eraseall /dev/mtd3 # mtd3 on my stick — confirm yours 5reboot

The reboot can take up to two minutes. Before running it, open another terminal and keep a ping running so you know when the stick is reachable again:

1ping 192.168.1.1

After the reset, apply or verify the firmware patch I used. My stick is a Realtek RTL9601D-based ODI DFP-34X-2C2; do not use this firmware on a stick with a different chipset.

This patch step was inherited from R1BNC's guide. I am not sure it is strictly necessary for this Converge line: my final minimum-config test was done after a factory reset, but the stick still appeared to be running the patched firmware image. So this proves the setup works on 220923FS; it does not prove that stock firmware would fail.

See the upstream RTL960x DFP-34X-2C2 firmware README for firmware notes and the 220923FS patch details.

Firmware file:

1M110_sfp_ODI_220923FS.tar

Upload that .tar from the stick's web UI firmware upgrade page, then let the stick reboot. If the patch is already installed, skip the upload and just verify it from SSH:

1cat /etc/version 2ls /etc/scripts/fix_speed.sh /etc/scripts/fix_vlan_tag.sh

Expected version marker:

1V1.0-220923

The 220923FS tar uses the same V1.0-220923 version string as the base firmware, so the more useful check is the presence of fix_speed.sh and fix_vlan_tag.sh. The README documents optional activation files under /etc/config, but I did not need to enable those toggles for this working configuration.

Then apply the minimum settings over SSH (ssh odi-sfp) — the same three flash set commands from What Actually Mattered above (GPON_SN, VLAN_CFG_TYPE 0, VLAN_MANU_MODE 0, then reboot). The same wait applies to this reboot. Keep the ping running until 192.168.1.1 responds again.

Verify after reboot:

1flash get GPON_SN 2flash get VLAN_CFG_TYPE 3flash get VLAN_MANU_MODE

VLAN_CFG_TYPE=0 and VLAN_MANU_MODE=0 keep the stick from doing its own VLAN manipulation. VLAN 10 must pass through to RouterOS so the RB5009 can run the DHCP client on the VLAN interface.

RouterOS

Put the DHCP client on VLAN 10 over sfp-sfpplus1.

1# Converge internet VLAN observed from the original ONT. 2/interface vlan add interface=sfp-sfpplus1 name=converge-wan vlan-id=10 3 4# DHCP from Converge. 5/ip dhcp-client add interface=converge-wan disabled=no 6 7# Let defconf firewall/NAT treat this as a WAN. 8/interface list member add list=WAN interface=converge-wan

Swap the ONT

Once the stick and RouterOS are configured, move the fiber handoff to the RB5009:

Connect fiber through the correct APC-to-UPC patch cord.

If you need to roll back, put the fiber back into the Skyworth ONT.

Verify

Check the GPON state first:

1diag gpon get onu-state

The target is:

1ONU state: Operation State(O5)

Then check DHCP on RouterOS:

1/ip dhcp-client print 2/ping 8.8.8.8

Working state for my setup was:

• ODI stick reaches Operation State(O5)
• RouterOS DHCP client binds on converge-wan
• internet works through the RB5009 SFP+ port

If the stick says O5 but RouterOS DHCP stays searching, look at VLAN handling first. In my testing, O5 with no DHCP was caused by the stick not passing VLAN 10 transparently.

Telemetry & Health Monitoring

RouterOS cannot read useful optical telemetry from this stick directly: no SNMP, no usable SFP DDM, and Tx power shows up as -inf. The values are available from the stick's Boa web UI, so I put the polling, RouterOS disk-log rotation, rollups, and dashboard in a small RouterOS container instead: marfillaster/gpon-telemetry (docker.io/marfillaster/gpon-telemetry:alpine-arm64).

Command Reference

Useful stick commands:

1diag gpon get onu-state 2flash get GPON_SN 3flash get VLAN_CFG_TYPE 4flash get VLAN_MANU_MODE 5cat /tmp/omcilog

References

• R1BNC video: replacing ISP ONT with own hardware
• R1BNC post: Replacing ISP ONT with our own hardware, Converge FiberX
• Anime4000/RTL960x
• RTL960x DFP-34X-2C2 firmware README

Comments

Comments are powered by GitHub Discussions and require a free GitHub account to post.