search

Anime4000 / RTL960x

Hacking RTL960x based xPON ONU Stick to suite your Universal OLT
The Unlicense
662 stars 111 forks source link

ODI DFP-34X-2C2 ONT and possible issue with VLAN operation instructions #248

Open tonusoo opened 9 months ago

tonusoo commented 9 months ago

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:

ODI_DFP-34X-2C2_ONT_in_O5

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>
ToTheCLI commented 9 months ago

Try firmware M110_sfp_ODI_240202.tar

tonusoo commented 9 months ago

Thanks, I upgraded the firmware to V1.1.6-240202:

ODI_DFP-34X-2C2_device_status

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.

Anime4000 commented 9 months ago

have you change the mac address of the stick?

tonusoo commented 9 months ago

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.

alexojegu commented 9 months ago

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_*?

ToTheCLI commented 9 months ago

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

rasMUX commented 8 months ago

Try flash set OMCC_VER 134

tonusoo commented 8 months ago

@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.

qatar2030 commented 7 months ago

can someone please provide me firmware M110_sfp_ODI_240202.tar

ToTheCLI commented 7 months ago

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 commented 6 months ago

@tonusoo did it work for you?

tonusoo commented 6 months ago

@myepezg Do you mean the firmware upgrade to V1.1.6-240202? If yes, then this did not help.

myepezg commented 6 months ago

@tonusoo Ok ok. And did any method work for you?

davinunes commented 5 months ago

the firmware upgrade work for me