Open jason-akw opened 2 years ago
I reported same issue on Q&A section, looks like we are missing something else.. stick couldn't ship withj such a massive bug...
I think you need to have active, you need mac_key
huh..I need a mac_key to change the omci software version? wut?
I got my mac key, it just bind to MAC Address
if upgrade from 220304 firmware, need erase config partition, this will use default mac address with blank mac_key, will work
I ended editing the init scripts in the firmware and force feeding the OMCI softare version this way..fucking ugly hack thou, works now., except the vlan numbering problem I had with carlitoxxpro stuff is still there,
I ended editing the init scripts in the firmware and force feeding the OMCI softare version this way..fucking ugly hack thou, works now.,
What are the benefits of editing init scripts versus changing the "version" file? Is this something you would recommend using instead?
I ended editing the init scripts in the firmware and force feeding the OMCI softare version this way..fucking ugly hack thou, works now.,
What are the benefits of editing init scripts versus changing the "version" file? Is this something you would recommend using instead?
I have to supply both SW versions for the OLT to talk to me.
@Anime4000 feeding this information via /etc/config*.xml files should also work right ? do you know which of the config*.xml is always applied no matter what ? the _hs ones are right ?
I got my mac key, it just bind to MAC Address
if upgrade from 220304 firmware, need erase config partition, this will use default mac address with blank mac_key, will work
Sorry I just bought a DFP-34X-2C2 and it's still on its way. Do I have to ask the seller my MAC_KEY
if I wish to upgrade to 220414? Or I can get it with flash get MAC_KEY
? If I have to ask them for it, what should I asked? I mentioned the license thing to them as I saw somewhere in the FW update note but they just told me I should first check if it works lol.
@x43x61x69 first get your flash get ELAN_MAC_ADDR
and flash get MAC_KEY
before doing anything
@Anime4000 feeding this information via /etc/config.xml files should also work right ? do you know which of the config.xml is always applied no matter what ? the _hs ones are right ?
or... my I idea was separate files like this:
echo "3FE46606BGCB45" > /etc/config/sw_ver
then, a new file that being called from init
scripts
#!/bin/bash
if [ -f "/etc/config/sw_ver" ]; then
echo "Found custom Software Version, Applying..."
flash set OMCI_SW_VER1 `cat /etc/config/sw_ver`
flash set OMCI_SW_VER2 `cat /etc/config/sw_ver`
fi
well script not perfect, still need validate /etc/config/sw_ver
before flash set
Try setting OMCI_OLT_MODE to 21
flash set OMCI_OLT_MODE 21
Ran into the same problem. Need OMCI_SW_VER1 to be set to a valid software version otherwise the DFP-34X-2C2 was downloading/spammed with some firmware from the OLT and then started to get very irresponsible.
I am having firmware 210702 and use it as GPON. Do not want to make an update right now, as everything else was working good.
Found out, that /bin/checkomci is causing the trouble. When called it starts setting some default values for at least OMCI_SW_VER1 and OMCI_SW_VER2 depending on the OMCI_OLT_MODE.
It is called from /etc/init.d/rc3 .
The module seems to have much more default values then 2 or 3. So setting OMCI_OLT_MODE to 3 just causes the module to set some default settings and not using custom ones.
Was not able to figure out which number is custom mode and does not override OMCI_SW_VER1 or OMCI_SW_VER2.
But I found out that setting OMCI_OLT_MODE to 21 causes an segmention fault in /bin/checkomci which prevents it from overriding OMCI_SW_VER1 or OMCI_SW_VER2. The rest of /etc/init.d/rc3 is then running fine. The module is keeping and using my OMCI_SW_VER1 and OMCI_SW_VER2.
More research needs to be done. For example if the 21 works for every firmware or if there is really a number for a custom mode which then maybe uses other registers then OMCI_SW_VER1. CUSTOM_OMCI_SW_VER1 for example.
The behavior can easily be tested with
flash set OMCI_SW_VER1 TEST; flash set OMCI_OLT_MODE X; /bin/checkomci; flash get OMCI_SW_VER1
where X is a number from 0 to 127
OMCI_OLT_MODE to 21 causes an segmention fault
That nice bug to prevent override OMCI_SW_VER#
I was set up these values:
flash set OMCI_FAKE_OK 1 flash set OMCI_OLT_MODE 3 flash set GPON_PLOAM_PASSWD flash set GPON_SN flash set GPON_ONU_MODEL H660WM flash set PON_VENDOR_ID DSNW flash set OMCI_SW_VER1 H660WMR210825 flash set OMCI_SW_VER2 H660WMR200619 flash set HW_HWVER H660WM
@akw28888 out of curious, did you get it to work? It seems that you were using Hinet (based on the configurations). Would you mind to share the configurations that you get it to work?
Also the methods mentioned by @3ooabkhxtn seems working (for 220414
and 220517
at least).
@3ooabkhxtn sounds great, I'll test it next week. @x43x61x69 It depends on what ONU you are using currently. I am using the 220417 version. It seems Hinet disabled the stupid verification for some ONU models now. So if you are using H660WM/H660C/RTF8207/RTF8217, you only need to change the SN and Password(=SLID). But if you are using I040GW/I040GA/I040GB, then you need to change SN, Password, ONU_MODEL, SW_VER, HWVER.
Had some new error messages in my /proc/kmsg. Think it breaks some VLAN stuff when using OMCI_OLT_MODE 21. Not a problem for me, haven't seen anything which was not working. But maybe someone else is wondering why vlan is having problems afterwards...
# cat /proc/kmsg
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[2514] TBD
<4>
<4>[2784] TBD
<4>
<4>[2790] TBD
<4>
<4>[2302] TBD
<4>
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[WARNING] Return Error (0x1005d:RT_ERR_RG_VLAN_USED_BY_VLANBINDING) at line:18396 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65629
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10088:RT_ERR_RG_VLAN_USED_BY_SYSTEM) at line:18390 @ return_err_mapping(9796)
<4>
<4>create ani vlan for mbcast fail, ret = 65672
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
<4>
<4>[WARNING] Return Error (0x10007:RT_ERR_RG_INVALID_PARAM) at line:18514 @ return_err_mapping(9796)
I got my mac key, it just bind to MAC Address
if upgrade from 220304 firmware, need erase config partition, this will use default mac address with blank mac_key, will work
Hello @Anime4000 , I'm dealing with the same error of @akw28888, other than traying to getting the stick work, could you please suggest, if not already published, how to erase config and restore all factory settings? Thanks
I got my mac key, it just bind to MAC Address if upgrade from 220304 firmware, need erase config partition, this will use default mac address with blank mac_key, will work
Hello @Anime4000 , I'm dealing with the same error of @akw28888, other than traying to getting the stick work, could you please suggest, if not already published, how to erase config and restore all factory settings? Thanks
here the command to factory reset...
flash_eraseall /dev/mtd3
You need to backup your ELAN_MAC_ADDR
and MAC_KEY
or VS_AUTH_KEY
before erase...
I could do tutorial, put some warning
Great tutorial @Anime4000 !
There is a way to validate the MAC_KEY
value? I noticed, after a suggested reset, that with the latest firmware in my case I had ELAN_MAC_ADDR
00E04...
but the MAC Address on the stick is 383a...
.
Tested the ODI stick on few FTTH lines but the best result I can get is:
GPON Status ONU State O5 ONU ID 0 LOID Status Initial Status
other than OMCI_SW_VERX
still not saved.
if you backup MAC_KEY
, apply it together with ELAN_MAC_ADDR
then your stick can be use, will be at least O1
invalid will stuck at O0
You need use @stich86 firmware for Software Version modification
The software version is coming from /lib/libmib.so
. You could replace the string with a hex editor and it will get the version updated.
The software version is coming from
/lib/libmib.so
. You could replace the string with a hex editor and it will get the version updated.
@devicelocksmith
wow nice finding!!! replacing string inside binary file, do need exact length or can trim or expand?
We already knew that.. I decided against this option previously ..You can use sothing like this
Even with mode 21, the stick uses it's own software version when sending the initial two requests to the ONT.
This is the OMCI message type. OMCI Protocol, ONU< Attribute Value Change - Software Image
After that it does proceed further and eventually send that message again with the correct version.
This likely isn't a huge issue, but we should still find a way around it, there's nothing in that binary with hard coded strings it just checks the mibs. Probably restores the software version due to a bug.
@Anime4000 I have my DFP-34X-2C2 stick with V1.0-220923
and the same issue (cannot set OMCI_SW_VER1
and OMCI_SW_VER2
, tried OMCI_OLT_MODE
as 1 or 21). Should I downgrade to something from here (https://github.com/Anime4000/RTL960x/tree/827f8b2c8b9a8cc1b3a050440fedd3af01788315/Firmware/DFP-34X-2C2)?
for ODI Firmware, set OMCI_OLT_MODE 21 then it can allow to set custom Software Version
This is what I did and the stick still cannot register.
Seems like some other values got borked when I played with OMCI_OLT_MODE
from 1 to 21 back and forth.
Seems like some other values got borked when I played with
OMCI_OLT_MODE
from 1 to 21 back and forth.
I have deploy a lot of ODI Stick, the flash set OMCI_OLT_MODE 21
should work to permanent OMCI_SW_VER1
and OMCI_SW_VER2
@Anime4000 did flash set OMCI_OLT_MODE 21
and set OMCI_SW_VER1
and OMCI_SW_VER2
. The stick cannot register at the ISP
Any updates to this?
REgistration can not pass because of lack of TR-069 functionality.
Hi I am using the 220304 version on DFP-34X-2C2, but I found I can not modify the OMCI_SW_VER1 and OMCI_SW_VER2.
After I reboot the stick, the OMCI_SW_VER1 and OMCI_SW_VER2 will reset to default values "V1.7.1".
I was set up these values:
flash set OMCI_FAKE_OK 1 flash set OMCI_OLT_MODE 3 flash set GPON_PLOAM_PASSWD
flash set GPON_SN
flash set GPON_ONU_MODEL H660WM
flash set PON_VENDOR_ID DSNW
flash set OMCI_SW_VER1 H660WMR210825
flash set OMCI_SW_VER2 H660WMR200619
flash set HW_HWVER H660WM