asn1c


asn1c: undefined reference to `SET_OF_encode_uper’

The following post is for the https://lionet.info/asn1c/ (repository: https://github.com/vlm/asn1c/)

When trying to link an ASN.1 structure that uses a SET OF, with support for Unaligned Packed Encoding Rules (UPER), we get the following error: undefined reference to 'SET_OF_encode_uper'.

Unfortunately, there is currently no solution for this problem, so we replaced the SET OF with a SEQUENCE OF.

The SEQUENCE OF type is the list (array) of simple or constructed types. The SET OF type models the bag of structures. It resembles the SEQUENCE OF type, but the order is not important: i.e. the elements may arrive in the order which is not necessarily the same as the in-memory order on the remote machines.

— From http://lionet.info/asn1c/asn1c-usage.html

Original (problematic) code

Elements ::= SEQUENCE
{
    property INTEGER,
    objects SET OF object
}

Updated (working) code

Elements ::= SEQUENCE
{
    property INTEGER,
    objects SEQUENCE OF object
}

 

Advertisements

asn1c: How do I know how big a buffer to allocate before using ‘uper_encode_to_new_buffer’?

The following post is for the https://lionet.info/asn1c/ (repository: https://github.com/vlm/asn1c/)

There is no need to compute the space needed.

If you pass the address to a pointer that is NULL pointer as the last parameter of uper_encode_to_new_buffer(asn_TYPE_descriptor_t *td, asn_per_constraints_t *constraints, void *sptr, void **buffer_r) , then it will allocate by itself the required space.

void *buffer = NULL;
asn_per_constraints_s *constraints = NULL;
ssize_t ec = uper_encode_to_new_buffer(&asn_DEF_Image, constraints, image, &buffer);


asn1c: What is the ‘write_stream’ parameter in the example code 1

The following post is for the https://lionet.info/asn1c/ (repository: https://github.com/vlm/asn1c/)

The asn1c usage manual (PDF), mentions an element called write_stream but it does not define what it is.

What write_stream is can be found in converter-sample.c  and in the manual under the name write_out:

/* Dump the buffer out to the specified FILE */
static int write_out(const void *buffer, size_t size, void *key) {
  FILE *fp = (FILE *)key;
  return (fwrite(buffer, 1, size, fp) == size) ? 0 : -1;
}

write_out is function that has the following signature write_out(const void *buffer, size_t size, void *app_key) and is used as a callback by der_encode() and other functions.

This callback receives as input the pointer to an element (const void *buffer), the size of that element (size_t size) and some context (void *app_key).
In this example, we can see that the user is using der_encode() which accepts a FILE * as the last parameter, which later is passed to write_out() as the context.


asn1c: Generating code using ‘Automatic Tags’ and negative value as default value creates invalid function names

The following post is for the https://lionet.info/asn1c/ (repository: https://github.com/vlm/asn1c/)

When compiling the following ASN.1 data structure

GeographyModule DEFINITIONS AUTOMATIC TAGS ::= BEGIN

    Coordinates ::= SEQUENCE
    {
        -- latitude from -90 till 90 degrees --
        latitude INTEGER(-9000000..9000000) DEFAULT -8000000,
        -- longitude from -180 till 179.99999 degrees, worst precision 1.1132m at equator --
        longitude INTEGER(-18000000..17999999) DEFAULT -12000000
    }

END

the use of both the AUTOMATIC TAGS option and the use of a negative value -8000000 in the position of the default value causes asn1c to create invalid function names in the Coordinates object.

For example, the above ASN.1 syntax will produce the following invalid function name int asn_DFL_2_set_-800000(int set_value, void **sptr).

Compilation command for asn1c

From folder asn1c_gps/asn1 we used the following command:

/home/developer/asn1c/asn1c/asn1c -pdu=auto -S /home/developer/asn1c/skeletons/ -fcompound-names -gen-PER ../geography.asn1

Version of asn1c

'ASN.1 Compiler, v0.9.28'

Example

Full example code demonstrating the bug can be found here ( asn1c_gps - Full example - Demonstrating Bug (179 downloads) ).

If you want to use the code and see that all other operations are fine, replace _- with _minus_ in the file Coordinates.c and the code will become valid and usable.

After you perform the above change, you can use the code in main.cpp to see the our cycle of execution that encodes and decodes an object.


asn1c: Decoding an OCTET STRING with lower bound limit on its size fails for uper_decode()

The following post is for the https://lionet.info/asn1c/ (repository: https://github.com/vlm/asn1c/)

Hello guys,

I’ve noticed that when I set a lower bound limit on the size of an octet string, it fails to decode it.
To reproduce this scenario I created a small but full example that is located here( asn1c_image - Full example - Demonstrating Bug (312 downloads) ).

The example( asn1c_image - Full example - Demonstrating Bug (312 downloads) ) is an application that uses the code generated by asn1c and has the following behavior:

  1. It will read a name of a file from the command line
  2. read the file to memory
  3. convert it to an octet string using OCTET_STRING_fromBuf()
  4. encode it to an ASN.1 structure using uper_encode_to_new_buffer(), after asn_check_constraints() succeeds
  5. save the encoded data to a file for debugging (same folder as the original file)
  6. decode the buffer from memory using uper_decode()
  7. save the decoded data to a file (same folder as the original file)

Methodology

To create/view the bug use this ASN1 data structure as input to the asn1c compiler:

ImagesModule DEFINITIONS ::= BEGIN

 Image ::= SEQUENCE
 {
  data OCTET STRING SIZE (40..81920)
 }

END

To hide the bug, use:

ImagesModule DEFINITIONS ::= BEGIN

 Image ::= SEQUENCE
 {
  data OCTET STRING SIZE (0..81920)
 }

END

The only difference between the two versions is the use of a lower limit constraint on the size of the OCTET string.

Compilation command for asn1c

From folder asn1c_image/asn1 we used the following command:

/home/developer/asn1c/asn1c/asn1c -pdu=auto -S /home/developer/asn1c/skeletons/ -fcompound-names -gen-PER ../images.asn1

Version of asn1c

'ASN.1 Compiler, v0.9.28'

Samples

Inside the archive, there are two files [test_01.png, bad_data.bin].

  • test_01.png is larger than 80K so it should always fail.
  • bad_data.bin fails only when there is a lower bound limit on the size

asn1c_image - Full example - Demonstrating Bug (312 downloads)