Could it not do something like :
Have the preference as a default only.
Then assume that in many cases the entire PDU will be available in the
trace so we can set up catching of exceptions and try the encodings
one by one.
Once (hopefully early in the trace) one of them decodes the entire
payload with no error or exception, then assume it is that encoding.
Then create a conversation and register that this particular
conversation is using encoding x.
I added a similar test to try to autodetect whether headerdigest was
in use or not for iscsi since i got too tired of changing the
preference everytime i was sent a new capture file and it had the
"wrong" setting compared to my preferences.
ok, i accept, autodetection of headerdigest in this case is much
simpler than for telco signalling but heuristics to autodetect
settings are superior to explicit preference settings for users that
only look at other peoples captures.
(and who dont know what settings are used)
On 5/2/05, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
> Not if you only look at the MTP3 information. The main difference is
> the length of fields. You could try to dissect the whole stack and
> if it works, it might be OK. But we have not the complete SS7 stack
> in ethereal...
>
> On the other hand, you know which standard you run on a link. It has
> to be configured. And you can not mix them on a link.
>
> Best regards
> Michael
>
> On May 2, 2005, at 12:39 PM, ronnie sahlberg wrote:
>
> > is it possible to implement heuristics that will autodetect which
> > standard is used?
> >
> >
> >
> > On 5/2/05, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> 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
> >>
> >>
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >
>
>