Ethereal-dev: RE: [Ethereal-dev] Wrong decoding of PER Enumerated typewithextension?
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: "Anders Broman (AL/EAB)" <anders.broman@xxxxxxxxxxxx>
Date: Wed, 8 Mar 2006 14:08:06 +0100
Hi, Yes, your correct I was to quick when I did that I think :) Brg Anders 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. NOTE - There are no PER-visible constraints that can be applied to an enumerated type that are visible to these encoding rules. -----Original Message----- From: ethereal-dev-bounces@xxxxxxxxxxxx [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Kukosa, Tomas Sent: den 8 mars 2006 13:55 To: Ethereal development Subject: RE: [Ethereal-dev] Wrong decoding of PER Enumerated typewithextension? Hi Anders, should not be the enumeration index in the extension decoded as normally small non-negative whole number instead of integer? Tom Mailcode: V55BCPWP -----Original Message----- From: ethereal-dev-bounces@xxxxxxxxxxxx [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Anders Broman (AL/EAB) Sent: Monday, March 06, 2006 12:42 PM To: Ethereal development Subject: RE: [Ethereal-dev] Wrong decoding of PER Enumerated typewithextension? Hi, Great, I think we should do it according to your proposal and do it now. Brg Anders Minor change: /* 13 Enemerated */ guint32 dissect_per_enumerated(tvbuff_t *tvb, guint32 offset, packet_info *pinfo, proto_tree *tree, int hf_index, guint32 min, guint32 max, guint32 *value, proto_item **item, gboolean has_extension, guint32 ext_min, guint32 ext_max) { proto_item *it=NULL; guint32 val; proto_item *pi; guint32 start_offset = offset; gboolean extension_present; header_field_info *hfi; if (!has_extension){ /* 13.2 */ offset = dissect_per_constrained_integer(tvb, offset, pinfo, tree, hf_index, min, max, value, item, has_extension); return offset; } /* Just get the extension bit, don't advance offset as it will be done in * dissect_per_constrained_integer */ dissect_per_boolean(tvb, offset, pinfo, tree, -1, &extension_present, &pi); if(extension_present){ /* Add extension bit to the tree */ offset = dissect_per_boolean(tvb, offset, pinfo, tree, -1, &extension_present, &pi); if (!display_internal_per_fields) PROTO_ITEM_SET_HIDDEN(pi); hfi = proto_registrar_get_nth(hf_index); /* 13.3 */ if ( ext_min == ext_max ){ /* 10.5.4 If "range" has the value 1, * then the result of the encoding shall be * an empty bit-field (no bits). */ val = max + 1; if (IS_FT_UINT(hfi->type)) { it = proto_tree_add_uint(tree, hf_index, tvb, start_offset, 1, val); } else { THROW(ReportedBoundsError); } /* byte aligned */ BYTE_ALIGN_OFFSET(offset); if (item) *item = it; if (value) *value = val; return offset; }else{ /* 13.3 ".. 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.." * * Byte align after reading Extension bit * */ BYTE_ALIGN_OFFSET(offset); offset=dissect_per_integer(tvb, offset, pinfo, tree, hf_index, &val, item); val = val + max; if (IS_FT_UINT(hfi->type)) { it = proto_tree_add_uint(tree, hf_index, tvb, start_offset, 1, val); } else { THROW(ReportedBoundsError); } if (item) *item = it; if (value) *value = val; return offset; } } /* Extension not present */ offset = dissect_per_constrained_integer(tvb, offset, pinfo, tree, hf_index, min, max, value, item, has_extension); return offset; } -----Original Message----- From: ethereal-dev-bounces@xxxxxxxxxxxx [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Kukosa, Tomas Sent: den 6 mars 2006 11:37 To: Ethereal development Subject: RE: [Ethereal-dev] Wrong decoding of PER Enumerated type withextension? 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 _______________________________________________ Ethereal-dev mailing list Ethereal-dev@xxxxxxxxxxxx http://www.ethereal.com/mailman/listinfo/ethereal-dev _______________________________________________ Ethereal-dev mailing list Ethereal-dev@xxxxxxxxxxxx http://www.ethereal.com/mailman/listinfo/ethereal-dev _______________________________________________ Ethereal-dev mailing list Ethereal-dev@xxxxxxxxxxxx http://www.ethereal.com/mailman/listinfo/ethereal-dev
- Prev by Date: RE: [Ethereal-dev] Wrong decoding of PER Enumerated typewithextension?
- Next by Date: Re: [Ethereal-dev] buildbot failure in Fedora-Core-4-IA32
- Previous by thread: RE: [Ethereal-dev] Wrong decoding of PER Enumerated typewithextension?
- Next by thread: [Ethereal-dev] Re: [Ethereal-cvs] rev 17502: /trunk/tools/lemon/: lemon.c
- Index(es):