Hello,
I few weeks ago I mentioned we were working on adding the ability to call other
dissectors from the AMQP dissector. We have this work complete and are ready
to create a PR.
The basic model is the same as in the MQTT dissector. There is a new
preferences entry, "Protocol Preferences -> Advanced Message Queueing Protocol
-> Message Decoding ..." which is registered via uat_new(). In these
preferences, which are saved and restored by wireshark, the user can create a
table of rows:
"Match criteria" "Topic pattern" "Payload protocol" "Additional Data".
Our use case sets 'protobuf' as the payload protocol, and it is expected the
additional data will be used to select a protobuf type definition from files
co-located with the preferences file. However any other dissector may be
invoked and additional data may be null or whatever is required by that
dissector.
The interesting part is where to query this table. The AMQP protocol, unlike
many other protocols, introduces payload as a parameter ("Data") just like all
other parameters that may appear the protocol header. AMQP parameters include
a parameter identifier, an encoding-type, length, and then the value.
For dissecting purposes the 'encoding-type' is the important part, so the AMQP
dissector simply uses the 'parameter identifier' to set a field label. The
dissector is chosen by the 'encoding type' which for Data is always leads to
'dissect_amqp_1_0_variable' for further dissection. There are several
encoding-types for this but they all lead to the same place. However other
parameters are free to use any of these encodings as well.
This means in our implementation, while dissecting any of the variable types,
we must also now check the `hf_amqp_type' and if it matches 'hf_amqp_1_0_data'
look to see if there is a matching entry for data dissection.
The fact 'hf_amqp_type' is passed to these parameter dissectors anyway suggests
this is acceptable.
However if feels inelegant, to be generous. Making dissection decisions inside
a general dissector is a side effect that might not be expected. I am open to
suggestions for a better approach. Or shall we just create the PR and review
it there.
Regards,
Ragnar Paulson
________________________________
Confidentiality notice
This e-mail message and any attachment hereto contain confidential information
which may be privileged and which is intended for the exclusive use of its
addressee(s). If you receive this message in error, please inform sender
immediately and destroy any copy thereof. Furthermore, any disclosure,
distribution or copying of this message and/or any attachment hereto without
the consent of the sender is strictly prohibited. Thank you.
___________________________________________________________________________
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
