On Fre, 12. Jan 2001, Guy Harris <gharris@xxxxxxxxxxxx> wrote:
>On Fri, Jan 12, 2001 at 08:56:50PM +0100, Michael Tüxen wrote:
>> Dear all,
>> please find attached patches to support the payload protocol identifier
>> field of
>> SCTP data chunks in a way similiar to port numbers.
>
>Checked in, but...
>
>> Please not that
>> dissector_try_proto_id does NOT set the match_port field.
>
>...with a change to make "{old_}dissector_try_port()" save and restore
>"pinfo->match_port", so that when it calls the subdissector
>"pinfo->match_port" is set to the port that matched, but when it returns
>it's back to the value it had, rather than a new routine that doesn't
>modify "pinfo->match_port".
>
>_______________________________________________
>Ethereal-dev mailing list
>Ethereal-dev@xxxxxxxxxxxx
>http://www.ethereal.com/mailman/listinfo/ethereal-dev
Dear Guy,
I just checked the CVS repository. Please apply the attached patch to
packet-m3ua.c.
It defines the payload proto id for M3UA and registers the dissector
under this id.
I forget to send it yesterday.
I saw that you call
dissector_try_port(sctp_ppi_dissector_table, ...)
instead of the suggested
dissector_try_payload_proto_id(sctp_ppi_dissector_table, ..
The problem with your solution is, that dissector_try_port sets the
pinfo->match_port
to the parameter port, which would be the payload_proto_id and NOT the
source or
destination port. So I deleted this line of code and the name of the
modified function
was dissector_try_payload_proto_id. It is only to avoid the possible
misinterpretation
of pinfo->match_port in call subdissectors. Both function should save
pinfo->current_proto
and pinfo->match_port.
The other "clear" method would be to introduce pinfo-
>match_payload_proto_id, which is
an "overkill" I think.
So I would suggest again introducing the function
dissector_try_payload_proto_id which
behaves slightly different from dissector_try_port.
Best regards
Michael
--
e-mail: Michael.Tuexen@xxxxxxxxxxxxxxxxxAttachment:
packet-m3ua.c.patch
Description: Binary data