Description
I am trying to replace my ISP's HGU (Movistar Spain) with an ODI DFP-34X-2IY3 SFP ONT stick (Realtek RTL8672 chipset) plugged directly into a Ubiquiti Cloud Gateway (UCG) Fiber.
While the stick successfully achieves a stable O5 state on the GPON network, the data plane seems completely blocked. The UniFi gateway is unable to establish the PPPoE connection, failing at the discovery phase.
Environment
- ISP: Movistar Spain (GPON 1 Gbps, Internet on VLAN 6, PPPoE authentication).
- Router: Ubiquiti UCG Fiber (WAN port manually forced to 1Gbps FDX, Tagged VLAN Management set to Allow All).
- SFP ONT Stick: ODI DFP-34X-2IY3 (Hardware V2.0).
- Tested Firmwares:
M114_sfp_ODI_hybrid_220916 and M114_sfp_ODI_hybrid_220527.
Configurations & Steps Taken
1. Full HGU Identity Emulation (Askey RTF3505VW)
To bypass potential OLT manufacturer restrictions, I cloned the original hardware identity via Telnet:
flash set PON_VENDOR_ID ASKY
flash set GPON_ONU_MODEL RTF3505VW
flash set HW_HWVER RFT3505VW
flash set OMCI_SW_VER1 GL_g2.8_100XNQ
flash set OMCI_SW_VER2 GL_g2.8_100XNQ
# Correctly formatted using ASKY + last 8 hex characters of the HGU MAC
flash set GPON_SN ASKYXXXXXXXX
2. VLAN Tagging Strategies
I tested both bridging approaches to isolate hardware switch tagging issues:
- Transparent Mode (Bridge): VLAN disabled on the stick's
nas0_0 interface; VLAN ID 6 tagged directly on UniFi's WAN configuration.
- VLAN Translation Mode: VLAN enabled (ID 6, 802.1p: 0) on the stick's
nas0_0 bridge; VLAN disabled (untagged) on UniFi's WAN.
3. OMCI & Compatibility Flags
Applied the standard workaround variables for Spanish OLTs:
flash set OMCI_OLT_MODE 1
flash set OMCI_FAKE_OK 1
flash set OMCC_VER 160
flash set OMCI_TM_OPT 1
Symptoms & Logs
- GPON Layer: Sychronization is flawless. ONU State is O5, Rx Power is around -20 dBm, Tx Power is ~1.9 dBm, and a valid ONU ID is assigned by the central.
- Gateway Logs (
journalctl on UCG Fiber):
ppp0[1303]: Timeout waiting for PADO packets
ppp0[1303]: Unable to complete PPPoE Discovery
- Internal Stick Counters: Checking
ifconfig and /proc/rtk_rg/pkt_tx_rx_cnt via Telnet shows that PADI packets from the gateway are hitting the host interface (eth0), but the TX counters on the WAN/PON side (nas0_0) remain at absolute zero.
Conclusion / Suspected Cause
This looks like a "Fake O5" scenario where the local OLT (likely a restrictive Alcatel/Nokia headend) accepts the PLOAM authentication but silently refuses to provision the GEM Ports or open the L2 bridge for VLAN 6 due to an unfulfilled OMCI MIB configuration workflow.
Is there any missing flash set variable, an issue with the bridge interface mapping in the Realtek SDK, or a specific OMCI MIB patch required for this hardware revision to open the data plane under strict OLTs?
Description
I am trying to replace my ISP's HGU (Movistar Spain) with an ODI DFP-34X-2IY3 SFP ONT stick (Realtek RTL8672 chipset) plugged directly into a Ubiquiti Cloud Gateway (UCG) Fiber.
While the stick successfully achieves a stable O5 state on the GPON network, the data plane seems completely blocked. The UniFi gateway is unable to establish the PPPoE connection, failing at the discovery phase.
Environment
M114_sfp_ODI_hybrid_220916andM114_sfp_ODI_hybrid_220527.Configurations & Steps Taken
1. Full HGU Identity Emulation (Askey RTF3505VW)
To bypass potential OLT manufacturer restrictions, I cloned the original hardware identity via Telnet:
2. VLAN Tagging Strategies
I tested both bridging approaches to isolate hardware switch tagging issues:
nas0_0interface; VLAN ID 6 tagged directly on UniFi's WAN configuration.nas0_0bridge; VLAN disabled (untagged) on UniFi's WAN.3. OMCI & Compatibility Flags
Applied the standard workaround variables for Spanish OLTs:
Symptoms & Logs
journalctlon UCG Fiber):ifconfigand/proc/rtk_rg/pkt_tx_rx_cntvia Telnet shows that PADI packets from the gateway are hitting the host interface (eth0), but the TX counters on the WAN/PON side (nas0_0) remain at absolute zero.Conclusion / Suspected Cause
This looks like a "Fake O5" scenario where the local OLT (likely a restrictive Alcatel/Nokia headend) accepts the PLOAM authentication but silently refuses to provision the GEM Ports or open the L2 bridge for VLAN 6 due to an unfulfilled OMCI MIB configuration workflow.
Is there any missing
flash setvariable, an issue with the bridge interface mapping in the Realtek SDK, or a specific OMCI MIB patch required for this hardware revision to open the data plane under strict OLTs?