Hi,
I have found the problem, so I did add the same protection, found in
expert.c, again "read filter" in the tcap tap. Thanks for pointing this bug.
I did rename the decoding function for ANSI and ITU as suggested.
And by the way, I did correct when a dissector want's to unregister it's
ssn.
As the ITU, and ANSI table for sccp.ssn is common, you can not
unregister an ssn(ITU) in the SCCP table if it is used by an ANSI
subdissector.
For the use of se_tree, I will see, but a bit later..
Regards
Florent
Jeff Morriss wrote:
Wow, that was fast, thanks!
By the way, why not rename these functions with "ANSI" and "ITU" in the
name?
+/*
+ * Call ITU Subdissector to decode the Tcap Component
+ */
static int
dissect_tcap_TheComponent(gboolean implicit_tag _U_, tvbuff_t *tvb, int offset, asn1_>
[...]
+/*
+ * Call ANSI Subdissector to decode the Tcap Component
+ */
+static int
+dissect_tcap_TheComponentPDU(gboolean implicit_tag _U_, tvbuff_t *tvb, int offset, as>
(maybe there's a good reason they're named that way, but...)
Also, while I was testing the patch on an ANSI TCAP capture I had handy,
I noticed that if I use a read filter ("wireshark -r /some/file -Rsccp"
for example), none of the TCAP statistics stuff works--I get a bunch of
noise about sessions starting in frame 0 and the responses don't get
matched to the queries. Maybe there's some code in there that assumes
that frame numbers are continuous (e.g., frame 3 follows frame 2) which
may not be the case if you have a read filter? If you don't have any
immediate ideas, maybe I'll file a bug report so we don't forget.
One other thing that I've read before:
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=20758
is that the g_hash's should be replaced with se_tree's (see
README.binarytrees). Something to think about going forward.
Anyway, checked in rev 22415, merci!
Attachment:
patch_tcap.tar.gz
Description: GNU Zip compressed data