Decoding CAM data succeeds but reponds with failure

[mennowo]

Hello,

currently I am using the UPER ASN.1 decoder from vanetza to decode some ASN.1 encoded CAM data. In order to do this, I created a C++ console app in Visual Studio 2022, and added the code from 'vanetza/common' and 'vanetza/as1' to it. With some minor changes and tweaks, this hapily builds. Then I can decode my data:

// base64 ASN.1 CAM data: AQIEs52FxB4AWpesRQ3QCjmf///8I7d0PgDSr8FN/j/p7QczyX9f/7A=
// decoded bytes
unsigned char buffer[41] = {
 0x01, 0x02, 0x04, 0xB3, 0x9D, 0x85, 0xC4, 0x1E, 0x00, 0x5A, 
 0x97, 0xAC, 0x45, 0x0D, 0xD0, 0x0A, 0x39, 0x9F, 0xFF, 0xFF, 
 0xFC, 0x23, 0xB7, 0x74, 0x3E, 0x00, 0xD2, 0xAF, 0xC1, 0x4D, 
 0xFE, 0x3F, 0xE9, 0xED, 0x07, 0x33, 0xC9, 0x7F, 0x5F, 0xFF, 
 0xB0 };
auto ok = vanetza::asn1::decode_per((asn_TYPE_descriptor_t&)(asn_DEF_CAM), (void**)(&cam), (void*)(buffer), 41);

This actually works, there is (correct) data in the structure. However the return value always gives false, which is due to uper_get_nsnnwn from uper_support.c returning -1 (line 84). Looking further, this seems to be caused by the decoder reading an incorrect value for CurvatureCalculationMode (ie. too high).

I am wondering if you have seen this kind of issue before. Maybe I can just ignore the return value and look at the data in the structure. And/or is this an inherent limitation in the way the ASN.1 UPER data is decoded in the asn1c code? Ie. because ASN extension markers may not be (fully) supported in asn1c.

[riebl]

Honestly speaking, I have never encountered this kind of issue before. I know that asn1c has its shortcomings but up to now, I have not found a better (open) alternative.

My understanding of ASN.1 is that CurvatureCalculationMode ::= ENUMERATED {yawRateUsed(0), yawRateNotUsed(1), unavailable(2), ...} should accept any integer value, including those large than 2. Hence, in my opinion, you have either found a bug or an (unfortunate) asn1c design decision.

[v0-e]

Vanetza is currently using the ASN.1 definition provided in the CAM standard v1.4.1. This standard mandates that the protocolVersion should be 2. This is the first byte of an UPER-encoded CAM. What you have there is protocolVersion = 1, indicating that the buffer was most likely encoded using a previous CAM ASN.1 definition. Try for example the ASN.1 definition provided in standard v1.3.2 and you will probably be able to decode it correctly.

[mennowo]

Thanks for both responses. I will try to decode using the 1.3.2 definitions, you are right that data is using the older version. I had trouble using the code generated with asn1c directly, as opposed to using the code from Vanetza, but I will give it another go!