Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 1976] "DISSECTOR_ASSERT_NOT_REACHED" failures in packet-ber.c from LDAP

[bugzilla-daemon@xxxxxxxxxxxxx]

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.