I certainly wouldn't say the MTP3 standard is stupid though in a perfect
world I would like it to auto-detect (I've had similar ideas to what
Ronnie said but haven't had time and have been afraid of the performance
penalty).
There are undoubtedly other things which could be more easily automated,
though. Something easy would be for TCAP to auto-detect its standard
(based on TCAP message type: the ANSI message types are unique from the
ITU ones and they're at the same location in the message).
I would love, though, for this business (to which I've contributed!) of
finding TCAP or RANAP and GSM-MAP/IS41/CAP/INAP based on SSN to go away.
It's one of the most common questions I get (why doesn't Ethereal
recognize my GSM-MAP message as GSM-MAP?). Note that this was the
crucial preference to viewing the CAP sample.
Michael Tuexen wrote:
The only crucial preference for MTP-3 is the standard it complies to.
ITU/ANSI/Chinese. I would not call that stupid...
So which preferences do you think are stupid and should be removed?
Best regards
Michael
On May 2, 2005, at 12:22 PM, Jeff Morriss wrote:
ronnie sahlberg wrote:
i tried that capture. no matter what i do i cant get it to display
anything above the SCCP layer. in particular, nothing i tried can get
it to display that packet as camel.
Setting TCAP's SSN preference to "5-12,200" gets you at least as far
as TCAP (this capture appears to be on an odd pair of SSNs: 152 and
200).
You might also have to set the Camel preference to include SSN 200 (I
say "might" because I appear to have compile problems at the moment
so I can't check myself).
why are there so many stupid preferences for MTP3 and friends?
Is it really impossible to get the dissector to figure out itself,
heusristically, which encoding is used?
Impossible? No. I'd love for that to happen. But I certainly don't
have time. :-( I suppose others have the same problem.
-J
On 5/2/05, Jacques, Olivier (OCBU-Test Infra)
<olivier.jacques@xxxxxx> wrote:
Can you update the patch to use value_strings such as the
other value strings in packet-camel-templace.c and i will check it
in.
Also, when using these value_strings use a proper
proto_tree_add_item() to add them instead of the
proto_tree_add_text().
This makes the dissector much better and makes filtering work.
If not, please send me an example capture file and i can
refactor the patch as described above.
I haven't looked at the changes, but there is a Camel capture on the
wiki:
http://wiki.ethereal.com/SampleCaptures?
action=AttachFile&do=get&target=
camel.pcap
It contains a releasecall operation.
Olivier.
_______________________________________________
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