Quoting Guy Harris <gharris@xxxxxxxxxxxx>:
> On Mon, Jan 08, 2001 at 11:48:59PM +0100, Michael
Tüxen wrote:
> > I'm working on the SCTP/M3UA interaction. If the
SCTP dissector does not
> > know the upper layer protocol it dissects the
payload inside a data_chunk
> > inside the sctp packet. If there is an M3UA payload
>
> How does the SCTP dissector determine whether there's
M3UA payload or
> not? Is it just checking the Payload Protocol
Identifier field in a
> DATA chunk?
>
No it uses a port number based dissector table
and calls dissector_try_port to call the upper
layer dissector. The Payload protocol identifier
is currently not used for determining the upper
layer protocol. (May be in a future version.)
> If so, perhaps the right way to handle this is to
create a dissector
> table "sctp.ppi" (or whatever), have the M3UA
dissector register itself
> in that table, and have the SCTP dissector call
"dissector_try_port()"
> on the Payload Protocol Identifier. If
"dissector_try_port()" returns
> false rather than true, it'd dissect the payload as
data.
That is how it works now, but port number based as
TCP and UDP does.
>
> That wouldn't work right at the moment; however, I've
That is why I'm asking all these questions.
just checked in
> changes to have all dissectors that register
themselves in a dissector
> table pass the protocol ID of their protocol as an
argument to
> "dissector_add()", so if I were to change
"dissector_try_port()" to
> ignore dissectors if the protocol is disabled (rather
than calling
> "dissect_data()"), that would cause
"dissectory_try_port()" to return
> false.
>
This would be great and solves all my problems (with
this part of the SCTP dissector).
> (It would also, for example, allow some *other*
dissector to dissect the
> frame, which could come in handy for cases where both
source and
> destination ports have dissectors associated with them
- if Ethereal
> picks the wrong dissector, disabling the wrong one
would be one way to
> get it to pick the right dissector, although it's a
bit of a brute-force
> way of doing it, and having a GUI option to explicitly
choose a
> different dissector - which might, by default, select
the "other port's"
> dissector if both ports have dissectors associated
with them - might be
> better.)
>
So, should I rely on you and assume that
dissector_try_port returns false, if there is no
dissector registered for that port number or is
currently disabled (DISPLAY_AS_DATA)? This would be
fine for me!
Best regards
Michael
