It would be nice to fix this in a way that could be used from Lua, to
make Lua dissectors first-class citizens and allow them to talk to C
dissectors (and vice-versa).
On 30/05/21 11:36, Graham Bloice wrote:
When I made that change to MQTT I failed to notice that it called
other dissectors with different data pointers, and although
specifically modified for SparkplugB, felt that passing the topic as
data was sufficiently general to be useful.
As others have noted, I guess the issue here is that to be more
specific about when to call a sub-dissector those sub-dissectors need
to register with the "parent" dissector using arbitrary fields and
arbitrary values to determine when and how the sub-dissector should be
called.
A more minimal solution could be for MQTT to declare an enum of "data"
pointer types and a special registration routine and sub-dissectors
register with that routine passing in one of the enum types and then
in MQTT before calling a sub-dissector check that "data pointer type"
table.
On Sat, 29 May 2021 at 08:33, Anders Broman <a.broma...@gmail.com
<mailto:a.broma...@gmail.com>> wrote:
Hi,
Yes the method is fragile. At the time of development I think it
was proposed to pass a struct containing a string and the void
pointer where the string could be used as a identifier. But that
was voted down.
Regards
Anders
Den lör 29 maj 2021 09:26Guy Harris <ghar...@sonic.net
<mailto:ghar...@sonic.net>> skrev:
On May 29, 2021, at 12:12 AM, Anders Broman
<a.broma...@gmail.com <mailto:a.broma...@gmail.com>> wrote:
> Shouldn't the caller be calling with the right data type or
NULL? So a bug in the MQTT disector?
How can the MQTT dissector determine what the right data type
*is* - especially given that the dissectors aren't wired in,
there's a UAT preference that lets the user configure it.
This is where the current mechanism for passing data between
dissectors goes crashing to the ground.
MQTT passes a topic string, which is just a string, to the
dissectors it calls.
JSON expects to be passed a pointer to an http_message_info_t.
JSON registers its non-heuristic dissector by name, and allows
it to be used with Decode As... for UDP ports.
It might *look* safe if you check the UDP dissector and the
dissectors that use "media_type" and "grpc_message_type", but
the "registers its non-heuristic dissector by name" mean there
are no guarantees, given that another dissector that passes a
pointer to something *other* than an http_message_info_t to
dissectors that are specified by name in a UAT.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list
<wireshark-dev@wireshark.org <mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev
<https://www.wireshark.org/lists/wireshark-dev>
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
<https://www.wireshark.org/mailman/options/wireshark-dev>
mailto:wireshark-dev-requ...@wireshark.org
<mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list
<wireshark-dev@wireshark.org <mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev
<https://www.wireshark.org/lists/wireshark-dev>
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
<https://www.wireshark.org/mailman/options/wireshark-dev>
mailto:wireshark-dev-requ...@wireshark.org
<mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
--
Graham Bloice
Software Developer
Trihedral UK Limited
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
