INTEGER_decode_aper decode failed for 3GPP 38.473 f1ap ASN

[xiangyunzhou]

The 3GPP ASN definition as below: MaxDataBurstVolume ::= INTEGER (0..4095, ..., 4096.. 2000000)

When the value is 3000 which was encoded as "00 0B B8" by ASN.1 Studio (https://www.oss.com), but decode by asn1c as "11" (0B), seem our asn1c consider the filed is 2byts as "Can encode 21 (3 bytes) in 2 bits (src/INTEGER_aper.c:68)", but actual it is 3 bytes. Also, wireshark could decode "00 0B B8" as 3000 correctly.

detail debug log as below: Decoding member "maxDataBurstVolume" in NonDynamic5QIDescriptor (src/constr_SEQUENCE_aper.c:130) Decoding NativeInteger MaxDataBurstVolume (APER) (src/NativeInteger_aper.c:21)

Integer with range 21 bits (src/INTEGER_aper.c:54) Can encode 21 (3 bytes) in 2 bits (src/INTEGER_aper.c:68)

Got length 1 (src/INTEGER_aper.c:75) Aligning 5 bits (src/aper_support.c:13)

Got value 11 + low 0 (src/INTEGER_aper.c:91) NativeInteger MaxDataBurstVolume got value 11 (src/NativeInteger_aper.c:38) Freeing INTEGER as a primitive type (src/asn_codecs_prim.c:16)

[v0-e]

Took a look at it and seems that this issue affects both the encoder and decoder. The main problem here is that the compiler seems to mash both the root constraint (0..4095) and the extended constraint (4096..2000000) into one (0..2000000).

I'm not really familiar with APER though looks like that X.691 (13.1 2021) mandates that if some INTEGER value (3000 here) is included in the root constraint (0..4095 here) then it should be encoded as if the extension marker (...) would not be present. That is, encode the value as if there is only the root constraint.

A fix for this would include:

1. have the compiler output (to MaxDataBurstVolume.c here) all constraint bounds to asn_per_constraints_s, with information if a constraint is root or not;
2. add the respective root constraint checking logic to the APER INTEGER encoder and decoder.

[xiangyunzhou]

Took a look at it and seems that this issue affects both the encoder and decoder. The main problem here is that the compiler seems to mash both the root constraint (0..4095) and the extended constraint (4096..2000000) into one (0..2000000).

I'm not really familiar with APER though looks like that X.691 (13.1 2021) mandates that if some INTEGER value (3000 here) is included in the root constraint (0..4095 here) then it should be encoded as if the extension marker (...) would not be present. That is, encode the value as if there is only the root constraint.

A fix for this would include:

1. have the compiler output (to MaxDataBurstVolume.c here) all constraint bounds to asn_per_constraints_s, with information if a constraint is root or not;
2. add the respective root constraint checking logic to the APER INTEGER encoder and decoder.

Thank you very much for you reply, I’m really appreciate. I will check the codes per your suggestion, though I'm not familiar to APER also.

[mouse07410]

@v0-e would you consider taking a stab at this and making a PR?

@xiangyunzhou IMHO that's an example of misuse of ASN.1, by defining structures so convoluted that a simple compiler like this one fails to groom them correctly.

[xiangyunzhou]

@v0-e works you consider taking a stab at this and making a PR?

@xiangyunzhou IMHO that's an example of misuse of ASN.1, by defining structures so convoluted that a simple compiler like this one fails to groom them correctly.

Yes, I don't like this complex definition also. And after further investigate, seems INTEGER (0..4095, ..., 4096.. 2000000) has the same encoder rule as INTEGER (0..4095, ...), but our asn1c parses this definition as INTEGER (0..2000000)

[mouse07410]

Since there doesn't seem to be anything I can reasonably do about this issue, I'm going to close it. Please feel free to re-open, if there's something new, or a suggestion how to fix it.

[xiangyunzhou]

Since there doesn't seem to be anything I can reasonably do about this issue, I'm going to close it. Please feel free to re-open, if there's something new, or a suggestion how to fix it.

I understand it is hard to fix, so I would only workaround this special case at my project, thanks also the same.