Ethereal-dev: RE: [Ethereal-dev] Wrong decoding of PER Enumerated type with extension?
Hi Anders,
I will update asn2eth in accordance with your changes in packet-per.
But I guess we should change dissect_per_enumerated() /now or later/
It does not support ENUMARATED where values differs from indexs
Cause ::= ENUMERATED {
cause0,
cause20 (20),
cause30 (30),
...
cause100 (100)
}
My proposal is following
- remove 'guint32 min' parameter as it is always 0
- rename 'guint32 max' to 'root_num' and value will be number of root
items
- remove 'guint32 ext_min' parameter as it is always 0
- rename 'guint32 ext_max' to 'ext_num' and value will be number of
extension items
- add new parameter 'guint32 *value_map' which maps indexe to values /if
NULL root vaules matches indexes and extension values matches
root_num+index/
for upper example it would be:
root_num = 3
ext_num = 1
value_map = {0, 20, 30, 100}
Any commets?
Regards,
Tomas
Mailcode: V55BCPWP
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Anders Broman
Sent: Saturday, March 04, 2006 5:49 PM
To: ethereal-dev@xxxxxxxxxxxx
Subject: [Ethereal-dev] Wrong decoding of PER Enumerated type with
extension?
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
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
