DEFAULT field with UPER encoding not managed correctly + help to debug the compiler

[QuentinDLZ]

Hello, Thanks for the tool that you developed!

I am having a similar issue as #378. In my case, I am trying to receive CPMs as defined by the ETSI TR 103 562 from a node which didn't use the asn1c compiler. Unfortunately for me, the CPM decoding results almost everytime in failure. The results I obtain:

• If I do not include any optional containers in the CPM, the message is decoded succesfully.
• If one optional container such as PerceivedObjectContainer is included, the decoding fails.

At the same time, some CAMs are transmitted by the node as well and the decoding never fails. By looking a bit in the main difference between CAM and CPM asn1 definitions, I noticed that the CAM does not use the DEFAULT type of field while the CPM yes. Moreover, by looking into the code generated by asn1c, I obtained an unexpected result. For example: driveDirection DriveDirection DEFAULT forward (see OriginatingVehicleContainer) is compiled as DriveDirection_t driveDirection; (see the complete code generated in this Vanetza link). When looking into the OSS asn1 compiler documentation, I found this document which states that both OPTIONAL and DEFAULT fields should work in a similar way. However, this does not seem the case with asn1c. I would expected that driveDirection DriveDirection DEFAULT forward would be compiled as DriveDirection_t *driveDirection; using the UPER encoding rules.

Shortly, I am expecting DEFAULT fields to be considered similarly to OPTIONAL ones but this is not the case.

I tried a naive approach of replacing all DEFAULT by OPTIONAL but the decoding still failed.

Does anyone know a fix or could help me by indicating a way of how to solve this issue?

Thanks in advance! Q

[riebl]

I can confirm this issue, however, I suspect that the SEQUENCE SIZE(1..128, ...) OF PerceivedObject OPTIONAL construct is handled erroneously. Note that other ETSI ITS message types such as CAMs use constructs such as SEQUENCE (SIZE(0..40)) OF PathPoint to cover empty lists. I still have to investigate this issue further and will report back here.

Update: The extension marker SIZE(, ...) seems to be ignored by asn1c. If a sequence actually contains 3 elements, the leading presence bit plus 7 bit for size number are encoded this way (correctly):

• SIZE(1..128, ...) -> 0x02 (2 + lower bound 1 = 3)
• SIZE(0..127, ...) -> 0x03 (3 + lower bound 0 = 3) asn1c ignores the encoded presence bit and thus the 7 most significant bits are interpreted as sequence length: 0x02 is believed to be a length of 2, 0x03 a length of 1. You can check this misbehaviour by looking at the respective list.count.

[riebl]

See also #383 for a very similar problem description.

[riebl]

290 mentions a manual fix for this problem. This ticket is open for over two years by now. Time to get this fixed finally ;-)

[QuentinDLZ]

Thank you very much @riebl , It solved my issue!