Wireshark · Ethereal-dev: [Ethereal-dev] Wrong decoding of PER Enumerated type with extension?

["Anders Broman" <a.broman@xxxxxxxxx>]

Hi,
I have a (k12)RANAP trace which displays as malformed the affected ASN.1
code is:

asn1/ranap/ranap.asn:
PagingCause ::= ENUMERATED {
        terminating-conversational-call,
        terminating-streaming-call,
        terminating-interactive-call,
        terminating-background-call,
        terminating-low-priority-signalling,
        ...,
        terminating-high-priority-signalling
}
The trace is encoding "terminating-high-priority-signalling" as 0x80 reading
X.691 section 13:
13.1    The enumerations in the enumeration root shall be sorted into
ascending order by their enumeration value, and shall then be assigned an
enumeration index starting with zero for the first enumeration, one for the
second, and so on up to the last enumeration in the sorted list. The
extension additions (which are always defined in ascending order) shall be
assigned an enumeration index starting with zero for the first enumeration,
one for the second, and so on up to the last enumeration in the extension
additions.

NOTE - ITU-T Rec. X.680 | ISO/IEC 8824-1 requires that each successive
extension addition shall have a greater enumeration value than the last.

13.2    If the extension marker is absent in the definition of the
enumerated type, then the enumeration index shall be encoded. Its encoding
shall be as though it were a value of a constrained integer type for which
there is no extension marker present, where the lower bound is 0 and the
upper bound is the largest enumeration index associated with the type,
completing this procedure.

13.3    If the extension marker is present, then a single bit shall be added
to the field-list in a bit-field of length one. The bit shall be set to 1 if
the value to be encoded is not within the extension root, and zero
otherwise. In the former case, the enumeration additions shall be sorted
according to 13.1 and the value shall be added to the field-list as a
normally small non-negative whole number whose value is the enumeration
index of the additional enumeration and with "lb" set to 0, completing this
procedure. In the latter case, the value shall be encoded as if the
extension marker is not present, as specified in 13.2.

I guess the encodings should be " Extension bit set and value = 0, range of
value is 1 so according to:

10.5.4	If "range" has the value 1, then the result of the encoding shall be
an empty bit-field (no bits).

This looks OK(?)

To decode this properly I suppose a new dissect_per_enumerated() has to be
made and asn2eth needs to supply both the range for the enumeration root and
the extension to this funktion?

Best regards
Anders