Encoding of such a datatype leads into a bitshift of one to the left of the first decoded value after the start of the sequence (when compared to Wireshark as reference decoder).
Decoding of a valid CPM results into a bitshift to the right of the first decoded value after the start of the sequence (when compared to Wireshark as reference decoder).
Likely Cause
The additional "..." seems to be important and needs to be respected by the decoder/encoder. But this seems not be implemented into the Generator
Unsuccessful Workarounds
removing the "..." in the asn1 definition will not fix the problem. The newly generated code is exactly the same. Hence this issue is most likely part of the core components of the generator.
Possible Solutions
none
Status
If you want to use specifications of that type, we suggest to use another Generator for the messages. Thank you though for trying to opt for this FOSS!
Issue
A defintion of SEQUENCESIZE(1..128, ...) can not be decoded/encoded (see CPM v2.1.1)[https://github.com/virtual-vehicle/vehicle_captain_its_asn1_specifications/blob/master/experimental/CPM-PDU-Descriptions.asn].
Setup
Generator: https://github.com/brchiu/asn1c.git (velichkov_s1ap_plus_option_group_plus_adding_trailing_ull)
Problem Description
Encoding of such a datatype leads into a bitshift of one to the left of the first decoded value after the start of the sequence (when compared to Wireshark as reference decoder).
Decoding of a valid CPM results into a bitshift to the right of the first decoded value after the start of the sequence (when compared to Wireshark as reference decoder).
Likely Cause
The additional "..." seems to be important and needs to be respected by the decoder/encoder. But this seems not be implemented into the Generator
Unsuccessful Workarounds
Possible Solutions
none
Status
If you want to use specifications of that type, we suggest to use another Generator for the messages. Thank you though for trying to opt for this FOSS!