Re: [Wireshark-dev] payload_proto_id in SCPT dissector

2019-08-17 Thread João Valverde
On 17/08/19 11:16, Peter Wu wrote: On Fri, Aug 16, 2019 at 10:09:43AM +0100, João Valverde wrote: Using a hash table is an indirect method of passing data. A void pointer function argument is a direct method of passing data. So why would the former present problems with nested TLS traffic

Re: [Wireshark-dev] payload_proto_id in SCPT dissector

2019-08-17 Thread Peter Wu
On Fri, Aug 16, 2019 at 10:09:43AM +0100, João Valverde wrote: > > > On 15/08/19 23:48, Peter Wu wrote: > > The problem was introduced with v3.1.1rc0-144-gede7be3440 ("TLS: allow > > dissectors to set the appdata protocol via the data param"). Since that > > commit, the "data" parameter of TCP

Re: [Wireshark-dev] payload_proto_id in SCPT dissector

2019-08-16 Thread João Valverde
On 15/08/19 23:48, Peter Wu wrote: The problem was introduced with v3.1.1rc0-144-gede7be3440 ("TLS: allow dissectors to set the appdata protocol via the data param"). Since that commit, the "data" parameter of TCP is interpreted as a string. The problem is that the SCTP dissector can also

Re: [Wireshark-dev] payload_proto_id in SCPT dissector

2019-08-15 Thread Peter Wu
The problem was introduced with v3.1.1rc0-144-gede7be3440 ("TLS: allow dissectors to set the appdata protocol via the data param"). Since that commit, the "data" parameter of TCP is interpreted as a string. The problem is that the SCTP dissector can also call the TLS dissector with a non-NULL

Re: [Wireshark-dev] payload_proto_id in SCPT dissector

2019-08-15 Thread Anders Broman
Hi, It is the SCTP PPI which is defined by IANA Payload protocol identifier: M3UA (3) { _data_chunk_payload_proto_id, { "Payload protocol identifier","sctp.data_payload_proto_id", FT_UINT32, BASE_DEC, VALS(sctp_payload_proto_id_values), 0x0,