ODI DFP-34X-2C2 ONT and possible issue with VLAN operation instructions
tonusoo opened this issue · 14 comments
I'm using ODI DFP-34X-2C2(firmware version V1.0-220923) ONT as a replacement for the ISP-provided Huawei HG8010H ONT. The ODI DFP-34X-2C2 ONT is authenticated and in the operational state:
# diag gpon get onu-state
gpon get onu-state
ONU state: Operation State(O5)
RTK.0> command:#
#
Same can be seen from the web interface:
According to omcicli mib get 84, the OLT has assigned the VLAN tagging filter data:
# omcicli mib get 84
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VlanTagFilterData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x01
FilterTbl[0]: PRI 0,CFI 0, VID 1
FilterTbl[2]: PRI 0,CFI 0, VID 4
FwdOp: 0x04
NumOfEntries: 2
=================================
=================================
EntityID: 0x02
FilterTbl[0]: PRI 0,CFI 0, VID 4
FwdOp: 0x04
NumOfEntries: 1
=================================
#
Once I disable the VLAN tag investigation for the tagged frames with omcicli mib set 84 0x01 FwdOp 0x02(Open OMCI Specification pages 69 - 72) and create the VLAN interfaces in the router, then both the Internet connectivity(VLAN 1) and IPTV service(VLAN 4) seem to be working perfectly fine. Example from a Linux-based router:
root@r1:~# # 192.168.1.200/24 is for the DFP-34X-2C2 management
root@r1:~# ip -4 a sh dev wan1
6: wan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.1.200/24 brd 192.168.1.255 scope global wan1
valid_lft forever preferred_lft forever
root@r1:~#
root@r1:~# ip -4 a sh dev wan1.1
10: wan1.1@wan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.0.2.158/28 brd 192.0.2.159 scope global dynamic wan1.1
valid_lft 1610sec preferred_lft 1610sec
root@r1:~#
root@r1:~# ip -4 a sh dev wan1.4
11: wan1.4@wan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.250.186.4/18 brd 10.250.191.255 scope global dynamic wan1.4
valid_lft 14104sec preferred_lft 14104sec
root@r1:~#
Publicly routable IPv4 addresses in the output above are obfuscated and IPv6 addresses are not shown.
However, both in case of Huawei HG8010H ONT and Huawei MA5671A SFP ONT, there was no need for the VLAN interface for VLAN 1. In other words, the Internet traffic was untagged and IPTV traffic was in the VLAN 4(details are described here).
What might cause the behavior described above? Could it be that the OLT does not send the VLAN operation instructions to ONT? For example, in case of ODI DFP-34X-2C2 there seems to be no instructions:
# omcicli mib get 171
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ExtVlanTagOperCfgData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#
.. while in case of Huawei HG8010H there seems to be something:
WAP>omcicmd mib show meid 171 instid 65535
-------------------------------------------------------
Me(171)(Extend Vlan Tag) has 1 instances, instance size is 40
-------------------------------------------------------
Instance ID = 0x0001, Instance Content:
02830000 81008100 6843d400 01010000 00000000 00000000 00000000 00000000
-------------------------------------------------------
success!
WAP>
Try firmware M110_sfp_ODI_240202.tar
Thanks, I upgraded the firmware to V1.1.6-240202:
Unfortunately, the VLAN tagging filter data and Extended VLAN tagging operation configuration data are identical to old firmware version V1.0-220923:
# omcicli mib get 84
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VlanTagFilterData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x01
FilterTbl[0]: PRI 0,CFI 0, VID 1
FilterTbl[2]: PRI 0,CFI 0, VID 4
FwdOp: 0x04
NumOfEntries: 2
=================================
=================================
EntityID: 0x02
FilterTbl[0]: PRI 0,CFI 0, VID 4
FwdOp: 0x04
NumOfEntries: 1
=================================
#
# omcicli mib get 171
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ExtVlanTagOperCfgData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#
After upgrading the firmware to V1.1.6-240202, I enabled the OMCI_LOGFILE, imported the hex dump to Wireshark with OMCI plugin installed and finally saved the messages to pcap-ng file.
In total, there were 976 OMCI messages logged, but only 26 of those have a unique managed entity class name(OMCI specification pages 507 - 516):
martin@lab-svr:~$ tshark -r ODI_DFP-34X-2C2_fw_240202_omcilog.pcapng -T fields -e omciproto.me_class_str | sort -u
Ethernet frame extended PM (014e)
Ethernet PM History Data (0018)
Ethernet PM History Data 2 (0059)
Ethernet PM History Data 3 (0128)
FEC PM History Data (0138)
GAL Ethernet profile (0110)
GEM interworking Termination Point (010a)
GEM Port Network CTP (010c)
GEM Port PM History Data (010b)
MAC bridge port configuration data (002f)
MAC bridge port filter preassign table (004f)
MAC Bridge Port PM History Data (0034)
MAC Bridge Service Profile (002d)
Multicast GEM interworking termination point (0119)
OLT-G (0083)
ONT Data (0002)
ONT-G (0100)
Priority queue-G (0115)
Reserved for future standardization (351) (015f)
***TBD*** (78) (004e)
T-CONT (0106)
Threshold Data 1 (0111)
Threshold Data 2 (0112)
Traffic Scheduler-G (0116)
Virtual Ethernet interface point (0149)
VLAN tagging filter data (0054)
martin@lab-svr:~$
As seen above, looks like the OLT did not send the Extended VLAN tagging operation configuration data. In addition, I looked for the non-zero result code(OMCI specification pages 520 - 521) in messages sent by ONU to OLT:
martin@lab-svr:~$ tshark -r ODI_DFP-34X-2C2_fw_240202_omcilog.pcapng -Y "omciproto.msg_type_ar == 0 and frame[22:1] != 0" -O omci
Frame 58: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: Send_00 (20:53:45:4e:44:00), Dst: Receive_00 (20:52:45:43:56:00)
OMCI Protocol, ONU< Create - Reserved for future standardization (351)
Transaction Correlation ID: 38560
Message Type = Create
0... .... = Destination Bit: 0x0
.0.. .... = Acknowledge Request: 0x0
..1. .... = Acknowledgement: 0x1
...0 0100 = Message Type: Create (4)
Device Identifier: 0x0a
Message Identifier, ME Class = Reserved for future standardization (351), Instance = 257
Managed Entity Class: Reserved for future standardization (351) (015f)
Managed Entity Instance: 0x0101
Result: Unknown managed entity (04)
Trailer
CPCS-UU and CPI: 0x0000
CPCS-SDU Length: 0x0028
CRC32: 0x89e1a54b
Frame 302: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: Send_00 (20:53:45:4e:44:00), Dst: Receive_00 (20:52:45:43:56:00)
OMCI Protocol, ONU< Create - Reserved for future standardization (351)
Transaction Correlation ID: 39362
Message Type = Create
0... .... = Destination Bit: 0x0
.0.. .... = Acknowledge Request: 0x0
..1. .... = Acknowledgement: 0x1
...0 0100 = Message Type: Create (4)
Device Identifier: 0x0a
Message Identifier, ME Class = Reserved for future standardization (351), Instance = 257
Managed Entity Class: Reserved for future standardization (351) (015f)
Managed Entity Instance: 0x0101
Result: Unknown managed entity (04)
Trailer
CPCS-UU and CPI: 0x0000
CPCS-SDU Length: 0x0028
CRC32: 0x6781d909
Frame 546: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: Send_00 (20:53:45:4e:44:00), Dst: Receive_00 (20:52:45:43:56:00)
OMCI Protocol, ONU< Create - Reserved for future standardization (351)
Transaction Correlation ID: 40187
Message Type = Create
0... .... = Destination Bit: 0x0
.0.. .... = Acknowledge Request: 0x0
..1. .... = Acknowledgement: 0x1
...0 0100 = Message Type: Create (4)
Device Identifier: 0x0a
Message Identifier, ME Class = Reserved for future standardization (351), Instance = 257
Managed Entity Class: Reserved for future standardization (351) (015f)
Managed Entity Instance: 0x0101
Result: Unknown managed entity (04)
Trailer
CPCS-UU and CPI: 0x0000
CPCS-SDU Length: 0x0028
CRC32: 0xd37cb2ce
Frame 790: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: Send_00 (20:53:45:4e:44:00), Dst: Receive_00 (20:52:45:43:56:00)
OMCI Protocol, ONU< Create - Reserved for future standardization (351)
Transaction Correlation ID: 40898
Message Type = Create
0... .... = Destination Bit: 0x0
.0.. .... = Acknowledge Request: 0x0
..1. .... = Acknowledgement: 0x1
...0 0100 = Message Type: Create (4)
Device Identifier: 0x0a
Message Identifier, ME Class = Reserved for future standardization (351), Instance = 257
Managed Entity Class: Reserved for future standardization (351) (015f)
Managed Entity Instance: 0x0101
Result: Unknown managed entity (04)
Trailer
CPCS-UU and CPI: 0x0000
CPCS-SDU Length: 0x0028
CRC32: 0xf685d6fa
martin@lab-svr:~$
So there were four occurrences where ONU signaled a failure back to OLT. All four are related to managed entity ID 351. Example of a message sent by the OLT triggering the Unknown managed entity response is following:
OMCI Protocol, OLT> Create - Reserved for future standardization (351)
Transaction Correlation ID: 38560
Message Type = Create
0... .... = Destination Bit: 0x0
.1.. .... = Acknowledge Request: 0x1
..0. .... = Acknowledgement: 0x0
...0 0100 = Message Type: Create (4)
Device Identifier: 0x0a
Message Identifier, ME Class = Reserved for future standardization (351), Instance = 257
Managed Entity Class: Reserved for future standardization (351) (015f)
Managed Entity Instance: 0x0101
Attribute List
Trailer
CPCS-UU and CPI: 0x0000
CPCS-SDU Length: 0x0028
CRC32: 0xa3e8db2f
However, I doubt that this reserved managed entity class has something to do with Extended VLAN tagging operation configuration data.
have you change the mac address of the stick?
have you change the mac address of the stick?
Do you mean the ELAN_MAC_ADDR setting? If yes, then I did try to change this. I tried with both the lan mac and wan mac seen in the output of Huawei HG8010H display productmac command. MAC_KEY was also updated accordingly.
As a workaround at this stage, I'm running a systemd service on my Linux-based router which runs a script adjusting the forward operation if needed:
#!/usr/bin/env bash
exec 2>/dev/null
while true; do
filter_data=$(timeout 5 sshpass -p admin ssh admin@192.168.1.1 "omcicli mib get 84 0x01")
if grep -qs "^FwdOp: *0x04$" <<< "$filter_data"; then
timeout 5 sshpass -p admin ssh admin@192.168.1.1 "omcicli mib set 84 0x01 FwdOp 0x02"
fi
sleep 10
done
This restores the connectivity, for example, after the SFP ONT reboot.
Excuse me @ToTheCLI, where did you get the firmware M110_sfp_ODI_240202.tar? I can't find anywhere to download the latest versions, maybe an official site.
Is the version M110_sfp_ODI_240202.tar hybrid? which seem to be the ones recommended at https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/ Is this indicated by the nomenclature M110_* or M114_*?
Excuse me @ToTheCLI, where did you get the firmware
M110_sfp_ODI_240202.tar? I can't find anywhere to download the latest versions, maybe an official site.
In the Discord thread for the realtek chipset
Try flash set OMCC_VER 134
@rasMUX Thanks! In case of flash set OMCC_VER 134 I indeed receive the Extended VLAN tagging operation configuration data. However, the ONT stays authenticated(O5 state) only for few seconds:
# diag gpon get onu-state
gpon get onu-state
ONU state: Standby State(O2)
# diag gpon get onu-state
gpon get onu-state
ONU state: Serial Number State(O3)
# diag gpon get onu-state
gpon get onu-state
ONU state: Ranging State(O4)
# diag gpon get onu-state
gpon get onu-state
ONU state: Operation State(O5)
RTK.0> command:#
# diag gpon get onu-state
gpon get onu-state
ONU state: Operation State(O5)
# diag gpon get onu-state
gpon get onu-state
ONU state: Operation State(O5)
# diag gpon get onu-state
gpon get onu-state
ONU state: Standby State(O2)
RTK.0> command:#
#
Cycle above seems to repeat forever. diag gpon get onu-state commands were executed roughly a second apart.
The configuration I'm using can be seen below:
flash set GPON_SN HWTC00112233
flash set PON_VENDOR_ID HWTC
flash set OMCI_OLT_MODE 3
flash set GPON_ONU_MODEL HG8010H
flash set HW_HWVER 2B2.A
flash set OMCI_SW_VER1 V1.7.1
flash set OMCI_SW_VER2 V1.7.1
flash set OMCC_VER 134
flash set OMCI_FAKE_OK 1
flash set ELAN_MAC_ADDR 80d4a5112233
flash set MAC_KEY 400c594b278d89035dc3db37bbc45d0e
flash set HW_CWMP_MANUFACTURER 'Huawei Technologies Co., Ltd'
flash set HW_CWMP_PRODUCTCLASS SFU
The values of GPON_SN and ELAN_MAC_ADDR were obfuscated. In case I change the OMCC_VER back to its default value of 128, then the ONT authenticates just fine.
In addition, I have tried with various other OMCC_VER values like 136 or 160 but the authentication problem persists.
can someone please provide me firmware M110_sfp_ODI_240202.tar
can someone please provide me firmware M110_sfp_ODI_240202.tar
M110_sfp_ODI_240202_Extract_Tar_File.zip
Extract the .tar File from the archive
@myepezg Do you mean the firmware upgrade to V1.1.6-240202? If yes, then this did not help.
the firmware upgrade work for me