Decoding routines generated by snacc expect extra EOC octets in a tagged CHOICE

[rbalint]

trafficstars

Hi,

A Debian user reported the issue to Debian BTS ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375470 ):

I found this bug when using snacc to generate the decoding routines for TAP 3.11 (Transfer Account Procedure Data Record Format, Specification Version Number 3. GSM Association, Official Document TD.57, 26 May 2005) and testing them with data files from an external source that are surely of this particular format. The routines returned an unexpected error:

BDecEoc: ERROR - non zero byte in EOC or end of data reached

The same files could be handled without errors by dumpasn1.

It wasn't easy to find out from where these errors come. I inserted printf() calls adjacent to the BDecEoc() calls in the generated decoding routines, and this way I finally found that:

The decoding routines expect (and check the presence of) two consecutive EOC octets where only one EOC octet is present in my test files (no, I cannot provide you with them). After deleting the extra code the files went through decoding without errors.

I haven't had the same kind of problem with earlier versions of TAP 3, so I searched for an explanation from the changes made in TAP 3 specifications from TAP 3.10 to TAP 3.11, and found that the extra EOC was expected in the decoding routine at a tagged CHOICE, which was non-tagged in earlier TAP 3 specifications.

The following is a simplified excerpt of the TAP 3.11 specification:

TAP-0311 DEFINITIONS IMPLICIT TAGS ::=

BEGIN

BasicService ::= [APPLICATION 36] SEQUENCE { serviceCode BasicServiceCode OPTIONAL, transparencyIndicator INTEGER OPTIONAL }

BasicServiceCode ::= [APPLICATION 426] CHOICE { teleServiceCode TeleServiceCode, bearerServiceCode BearerServiceCode }

BearerServiceCode ::= [APPLICATION 40] HexString --(SIZE(2))

TeleServiceCode ::= [APPLICATION 218] HexString --(SIZE(2))

HexString ::= OCTET STRING

END

Compile this by snacc. You can find the following sequence of code in the generated function BDecBasicServiceContent():

BDecBasicServiceCodeContent (b, tagId2, elmtLen2, (v->serviceCode),
&totalElmtsLen1, env);
if (elmtLen1 == INDEFINITE_LEN)
    BDecEoc(b, &totalElmtsLen1, env);
if (elmtLen1 == INDEFINITE_LEN)
    BDecEoc (b, &totalElmtsLen1, env);

One of the if sentences with its BDecEoc() call is too much, it shouldn't be there!

I haven't checked if the coding functions produce output that is compatible with the decoding functions (with extra EOC) or if they are OK.

[apconole]

I have this solved, I believe, with my version of snacc (https://github.com/orgcandman/esnacc-ng); it will be merged to https://github.com/azsnacc/esnacc-ng after some internal testing.