http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1976
------- Comment #2 from guy@xxxxxxxxxxxx 2007-11-08 11:53 GMT -------
The stack trace is
#3 0x039b2729 in dissect_ber_integer64 (implicit_tag=1, actx=0xbfffde14,
tree=0x7a53350, tvb=0x7a538f0, offset=1, hf_id=26098, value=0xbfffdad8) at
packet-ber.c:1193
#4 0x039b2768 in dissect_ber_integer (implicit_tag=1, actx=0xbfffde14,
tree=0x7a53350, tvb=0x7a538f0, offset=0, hf_id=26098, value=0x47f1bb0) at
packet-ber.c:1210
#5 0x03ec98e7 in dissect_ldap_MessageID (implicit_tag=1, tvb=0x7a538f0,
offset=0, actx=0xbfffde14, tree=0x7a53350, hf_index=26098) at ldap.cnf:69
#6 0x039b2065 in dissect_ber_tagged_type (implicit_tag=0, actx=0xbfffde14,
tree=0x7a53350, tvb=0x7a538bc, offset=0, hf_id=26098, tag_cls=1 '\001',
tag_tag=16, tag_impl=1, type=0x3ec98a2 <dissect_ldap_MessageID>) at
packet-ber.c:352
#7 0x03ecc25e in dissect_ldap_AbandonRequest (implicit_tag=0, tvb=0x7a538bc,
offset=0, actx=0xbfffde14, tree=0x7a53350, hf_index=26098) at ldap.cnf:714
#8 0x039b2cad in dissect_ber_choice (actx=0xbfffde14, parent_tree=0x7a52c78,
tvb=0x7a53888, offset=0, choice=0x4a54700, hf_id=26079, ett_id=7560,
branch_taken=0x47f1bb4) at packet-ber.c:2661
#9 0x03ecc58d in dissect_ldap_ProtocolOp (implicit_tag=0, tvb=0x7a53888,
offset=0, actx=0xbfffde14, tree=0x7a52c78, hf_index=26079) at ldap.cnf:82
#10 0x039b70ad in dissect_ber_sequence (implicit_tag=0, actx=0xbfffde14,
parent_tree=0x7a533e0, tvb=0x7a53820, offset=0, seq=0x4a54620, hf_id=26073,
ett_id=7559) at packet-ber.c:1589
#11 0x03eccf8e in dissect_ldap_payload (tvb=0x7a537ec, pinfo=0x95192f8,
tree=0x7a533e0, ldap_info=0x961cff8, is_mscldap=0) at ldap.cnf:723
#12 0x03ecd1a5 in dissect_ldap_pdu (tvb=0x7a537ec, pinfo=0x95192f8,
tree=0x7a55cd8, is_mscldap=0) at packet-ldap-template.c:921
#13 0x03d99bad in tcp_dissect_pdus (tvb=0x7a5371c, pinfo=0x95192f8,
tree=0x7a55cd8, proto_desegment=1, fixed_len=4, get_pdu_len=0x3ecdf4e
<get_normal_ldap_pdu_len>, dissect_pdu=0x3ecdf83 <dissect_normal_ldap_pdu>) at
packet-tcp.c:1963
#14 0x03ece4a0 in dissect_ldap_tcp (tvb=0x7a5371c, pinfo=0x95192f8,
tree=0x7a55cd8) at packet-ldap-template.c:1400
and the hf_id in dissect_ber_integer64() is 26098 in my system, which maps to
(gdb) print hf_id
$1 = 26098
(gdb) print proto_registrar_get_nth(hf_id)
$2 = (header_field_info *) 0x47f2d44
(gdb) print *$2
$3 = {
name = 0x446b288 "abandonRequest",
abbrev = 0x446c654 "ldap.abandonRequest",
type = FT_NONE,
display = 0,
strings = 0x0,
bitmask = 0,
blurb = 0x446c668 "ldap.AbandonRequest",
id = 26098,
parent = 26033,
ref_count = 0,
bitshift = 0,
same_name_next = 0x0,
same_name_prev = 0x0
}
The ASN.1 for AbandonRequest is
AbandonRequest ::= [APPLICATION 16] MessageID
dissect_ldap_AbandonRequest() passes on to dissect_ber_tagged_type() the
hf_index for ldap.AbandonRequest and a pointer to dissect_ldap_MessageID().
dissect_ber_tagged_type() then passes that hf_index on to
dissect_ldap_MessageID(), which passes them on to dissect_ber_integer(), but
that's not a valid filterable field, as it's of type FT_NONE.
Should the hf_index for ldap.MessageID be passed on? Or should a separate
filterable field for the MessageID field in an abandonRequest be defined, and
that field somehow passed on to dissect_ldap_MessageID()?
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
