OMCI message transfer to OpenOmci Adapter (tested with BBSIM)

Remark: I choose bbsim component, but I did not make sure that the problem is really in there!

 

The issue concerns the transfer of OMCI messages from BBSIM via OLT Adapter towards the ONU Adapter.

Finally, with the versions we currently test with, in the ONU Adapter the OMCI message is received as (BaseFormat) 48 byte message, where the OMCI trailer is completely set to 0.

This obviously has not been a problem with the existing py ONU Adapter. But when we build on the (CBowling) OMCI lib in our GoAdapter the library refuses to decode these frames. This library requires to have the OMCI trailer length correctly set to 40 (0x28), which in my point of view is legitimate and needs to be accepted. The FCS of the OMCI trailer instead is not required (I did not check if its presence would be accepted - short lookup at fragments seems FCS is expected to be 0, which also make sense as FCS is mostly handled within hardware front-end receiver/transmitter).

 

In our traces we can see that the OMCI frames are already handled without the OMCI trailer length in the OLT Adapter device handler, we receive them the same way on the ONU adapter.

E.g. the OLT Adapter log entry looks like this:

{"level":"debug","ts":"2020-03-31T13:56:47.120Z","caller":"core/device_handler.go:844","msg":"recv-omci-msg","instanceId":"adapter-open-olt-75bf8d5f48-4vtrh","pkg":"core","intfID":0,"onuID":1,"omciTransactionID":2,"omciMsg":"00022f0a0002000000000000000000000000000000000000000000000000000000000000000000000000*0000*00000000"}

According to standard and the needs of our adapter code the frame as example has to look like this:

"omciMsg":"00022f0a0002000000000000000000000000000000000000000000000000000000000000000000000000*0028*00000000"

 

Meanwhile I provided an autocorrection for the frames in our OnuAdapter code, but I would expect, that the issue should be solved on the origin.