Wireshark-dev: [Wireshark-dev] Calling payload dissector from AMQP dissector
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 ‘ 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. |
- Prev by Date: Re: [Wireshark-dev] How do I indicate that a commit or MR fixes an issue?
- Next by Date: [Wireshark-dev] can't compile wireshark version 4.0
- Previous by thread: Re: [Wireshark-dev] How do I indicate that a commit or MR fixes an issue?
- Next by thread: [Wireshark-dev] can't compile wireshark version 4.0
- Index(es):