Let's do something interesting here with Wireshark and WebSphere MQ. MQTT is a published wire level protocol. You can find the specification here. The MQTT applications could be running remotely or required logging may not be adopted in the application to debug problems. To observe what data is exchanged with MQTT client and server wireshark tool is very helpful tool. The analysis is required when the client cannot be inspected for a problem in MQTT.. also to observe if there are duplicate messages flowing.
Wireshark is a popular network protocol analyzer tool. It helps in debugging problems at network level and also help in optimizing the data flowing over the network. It helps spotting problems like network delays, find security issues and debug protocol implementations, etc. Wireshark can either used at the client side or the server side. For this blog its assumed that you have a MQTT client and Server running preferably on different machines. The MQTT client will connect and publish QOS 0 message and then subscribe to the topic and disconnect. The server could be micro broker or WebSphere MQ Telemetry Server.
Capturing the wireshark trace
- Download, Install and Run the Wireshark tool
- Go to Capture -> Interfaces... and click "Start" on the network adapter that is used.
- The system where the Wireshark is running could be either the client or the server. In this example, I have run the MQTT client on system where Wireshark is installed. Now use the MQTT client while the wireshark is capturing the trace.
- Stop the Wireshark trace and export (File -> Export...) to text file so that it can be analyzed easily after the test has completed.
Understanding wireshark trace
Easiest way to get started is to search for the client ID. The client ID is always unique and easy to understand if the client has be active during the time the wireshark trace was captured. Now let's look at the first operation from the MQTT Client, ie CONNECT:
0000 10 1f 00 06 4d 51 49 73 64 70 03 02 00 3c ....MQIsdp...<
0000 00 11 6d 71 74 74 5f 6e 65 65 6b 72 69 73 68 5f ..mqtt_neekrish_
0010 31 5f 32 1_2
Here "10" represents the CONNECT packet, then followed by the remaining length "1f" which evaluate to 31. Now followed by Variable header. MQIsdp represents the protocol name. "03" gives important information about the connect options. "03" represents the MQTT V3 specification version and "02" will evaluate to "00000010" in the binary. Hence only the clean session flag is set. Next "00 3c" gives the keep alive timer. 3c in hex is 60 in binary. Hence the client has chosen 60 seconds to be the keep alive. After this its followed by the client identifier as you can see
Now let's look at CONNACK for the acknowledgment:
0000 20 02 00 00 ...
Here "20" represents CONNACK and 02 is the remaining length and the following "00" represents connection accepted.
Then following line in the trace represents the PUBLISH from the client:
0000 30 17 00 09 74 65 73 74 54 6f 70 69 63 0...testTopic
0000 54 65 73 74 20 4d 65 73 73 61 67 65 Test Message
Here "30" represents the PUBLISH with QOS 0. Its followed with remaining length and "testTopic" is the topic to which the message will be published. Then its followed with the message itself
Similarly the SUBCRIBE can be found in the trace:
0000 82 0e 00 03 ....
0000 00 09 74 65 73 74 54 6f 70 69 63 00 ..testTopic.
Here "82" represents the SUBSCRIBE with QOS 1... This is not the requested QOS... The requested QOS is last byte "00".
The SUBACK would be usually found following this:
0000 90 03 00 03 00 .....
For the DISCONNECT (e0) look for
0000 e0 00 ..
Several observations can be made... You can see that the header information is very short in all the MQTT verbs. Also referring to the MQTT specification, the complete data can be decoded in a non-secure MQTT connection. Hence you can see the wireshark can be used to easily analyze the MQTT messages sent or received to WebSphere MQ Telemetry or any other MQTT Server.
Post your comments if you find this interesting and helpful :)