On Tue, Oct 08, 2002 at 03:21:26AM -0700, Guy Harris wrote:
> On Fri, Sep 20, 2002 at 10:59:47AM -0600, Greg Morris wrote:
> > Please see attached diffs for most NDS decodes. I am still working on
> > the rest but I wanted to get my work to date submitted for review. I
> > know there is more then likely a lot of cleanup that can be done but I
> > haven't taken the time yet. Please let me know what you think,
>
> There's a fairly nasty bug in the changes to "packet-ncp2222.inc".
And there's another bug as well:
In "dissect_nds_request()", there's code that does
if(resolve_eid) {
/* For NDS requests with just an EID, resolve name from hash table. */
request_eid_value = ncp_eid_hash_lookup(conversation, global_eid);
if (request_eid_value) {
global_object_name = request_eid_value->object_name;
if (check_col(pinfo->cinfo, COL_INFO))
{
col_append_str(pinfo->cinfo, COL_INFO, ", Object Name - ");
col_append_str(pinfo->cinfo, COL_INFO, global_object_name);
}
}
}
near the end.
However, "ncp_eid_hash_lookup()" looks up the EID in the
"ncp_req_eid_hash" hash table - but that hash table is destroyed by
"ncp_postseq_cleanup()", called after the sequential pass through the
packets.
This means that if you read in a capture, and then run a display filter
that causes the code in question in "dissect_nds_request()" to be run,
you will get a bunch of warnings from GLib about "g_hash_table_lookup()"
being called with a null hash table pointer, and the lookups presumably
fail and return null.
