EquipmentID/HardwareVersion with null characters

[tdmadam]

Hello all,

I came into possession of an ONT that I would like to clone on an SFP module G-010S-A. I managed to configure most of the parameters. When analyzing the OMCI file from the old terminal, I got the following values.

OMCI Hardware Version: PTIR762-32.7 OMCI Equipment ID: DBU2988344SK

In a similar way, I analyzed the G-010S-A OMCI Hardware Version is created by combining HardwareVersion+ICS 10+2 characters OMCI Equipment ID is created by the combination of CleiCode+Mnemonic 10+10 characters

ONTUSER@SFP:~# ritool set HardwareVersion  "PTIR762-32"
ONTUSER@SFP:~# ritool set ICS ".7"
End OMCI result: 0x505449523736322D33322E37

ONTUSER@SFP:~# ritool set CleiCode "DBU2988344"
ONTUSER@SFP:~# ritool set Mnemonic "SK          "
End OMCI result: 0x44425532393838333434534B2020202020202020
Should be:       0x44425532393838333434534B0000000000000000

Since the string length DBU2988344SK does not fill 20 characters I was forced to use spaces instead of null characters 0x00. If I don't use quotes and spaces the second part of the string will be thrown somewhere in the middle DBU2988344 SK

Does anyone know how to instert null characters using the ritool command?

[hwti]

The padding behavior is quite inconsistent...

How do you get the final OMCI result ? Which firmware do you use ?

From ritool set / ritool get, it seems :

• CleiCode has a fixed length of 10 (at least for ritool), setting a smaller values pads with spaces on the left
• Mnemonic has a length between 8 and 12, setting a value smaller than 8 pads with spaces on the left

With the default values, I see :

• the omcli console gives Eqpt Id: BVL3A8JNAAG010SA
• /logs/omci.log has :

getOmciOntvalues: original RI cleicode = BVL3A8JNAA, length = 10
getOmciOntvalues: Mnemonic = G-010S-A
getOmciOntvalues: onu equipid(CleiCode+Mnemonic) = BVL3A8JNAAG010SA

I'm not sure how the padding is done at the end.

It is impossible to pass nul characters in an argument, since the arguments are nul-terminated strings. But since the original G-010S-A got transformed into G010SA, you should try ritool set Mnemonic "SK------".

[tdmadam]

For my testing I use two firmwares:

3FE47111BFHB32 which allows me to use ritool to edit variables and 3FE46398BGCB22 which gives me the ability to capture raw OMCI messages, but I cannot use ritool to edit.

I wrote about my experience with OMCI capture here: https://github.com/tdmadam/OMCI-for-SFP-Stick/blob/main/modules/G010SA.md

The ritool set Mnemonic "SK------" seems to be a step in the right direction, it created three null characters after SK and then appended the remaining --- to the end. I will continue testing using spaces and --- characters.

[hwti]

The omcimsg.txt is referenced in the parser binary of all versions. Perhaps there is a command to enable it.

If your issue with ritool on 3FE46398BGCB22 is not allow to modify it., you only need ritool set OperatorID 0000 . On this version, ritool values, except OperatorID, can only be changed for OperatorID 0000 or 9999.

[tdmadam]

Thanks. It worked great.

[hwti]

Do you still have issues with the Equipment ID ?

[tdmadam]

Just a little. I stay with ritool set Mnemonic "SK------" It's not perfect, but it does what I need. At least I don't have to switch between firmwares now.

>>> bytes.fromhex('44425532393838333434534B0000002D2D2D0000')
b'DBU2988344SK\x00\x00\x00---\x00\x00'
>>> 

The final hurdle is the image0_version and image1_version variables stored in /configs/image_version, for which the firmware must be modified so that they are not overwritten.

I was hoping image versions could be updated with fw_setenv. Perhaps I should try the Chinese firmware for the G-010S-A, which I read is highly customized by one of the OEM developers.

[hwti]

So the - removal terminates the string, but doesn't clear the whole buffer. So it would work or not, depending on how the OLT does the check.

On boot, /etc/rc.d/S43update_image_version.sh => /etc/init.d/update_image_version.sh => /etc/init.d/image_version.sh will update /configs/image_version from /usr/etc/buildinfo. But the script doesn't quote strings, so it can be tricked to set your own versions without having to modify the firmware. For example, you can add a -a -z image0image1 line to /configs/image_version :

• The script will tell it doesn't need to update the version (without any error, thanks to the nice injection 😄).
• The OMCI deamons will read values from the usual image0_version=xxx / image1_version=xxx lines, which can be modified (I didn't check the behavior with different length).

Unless there are several "Chinese firmware", it's a cross-flash, with something which looks more derived from the stock Lantiq SDK than the G-010S-A image.

[tdmadam]

For example, you can add a -a -z image0image1 line to /configs/image_version :

* The script will tell it doesn't need to update the version (without any error, thanks to the nice injection smile).

* The OMCI deamons will read values from the usual `image0_version=xxx` / `image1_version=xxx` lines, which can be modified (I didn't check the behavior with different length).

That' s clever. Works great for my case, making the G-010S-A configurable and the module has the means to troubleshoot.

Thanks!