MQTT Keep Alive Force Disconnect - How to simulate this condition?

[Naveen PS]

Hi Guys,

I am currently using my Pi 4 as a broker, My laptop as the Client(MQTT.fx) that publishes, and my mobile that use MyMQTT app as client that subscribes.

My goal is to dissect every features of MQTT by doing packet analysis(even though the documentation is very detailed and tells everything). 

So coming back to the question, I am struggling to find a way to make the Force Disconnect Condition(No PINGRESP) to happen in my setup.

I was although able to initiate the LWT, by force closing MQTT.fx application while it was connected to the Broker(Pi). This indeed sent the LWT message across all the clients (mobile and another laptop). I was also able to view the packets moving between my Pi and the Clients by using ngrep tool in Pi's terminal.

So I would like any of you, to kindly suggest me some way to simulate Keep Alive Force Disconnect Condition like I did with LWT.

Generally what comes to my mind is the following solutions, but I don't know how to implement them.

1. PINREQ Packet shouldn't even go to the Broker - Is there any tool to block specific packets? But still I don't think if something like that still exists it will blindly block all MQTT packets instead of specific type of MQTT packets
2. Maybe can we modify the client's library to not even send a PINREQ command in the first place

Any guidance or suggestion are appreciated.

Thanks in advance

 

[Dustin Sallings]

The best way to understand the protocol itself, IMO, is to implement it.  I don't know that any specific broker or client implements every feature in every possible way.  IMO, some popular ones do things in a way that is complies with the letter of the protocol, but is far from the best way.  Error handing in particular could be greatly improved with existing protocol features.

When I want to test a broker's response to a bad condition, I write software that creates that condition.  E.g., adjust the ping req to either not be sent, or exceed the defined window.

I've hit all kinds of bizarre conditions in production and still regularly encounter obscure bugs in implementations.

Many of the protocol features I implemented didn't make much sense to me until I had a specific need (e.g., I have a pretty useful rpc-over-mqtt implementation that's solved some interesting problems for me, or some of the subscription flags, all of which I've eventually needed).

Wireshark has been a useful tool to help me understand something slightly ambiguous in the spec (or to document a bug), but it seems only useful for observing things you're already doing.  The mqtt implementation I wrote and the applications I've built on top of it have taught me quite a lot.

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/d40d400e-9d80-441f-be58-d0196ca4d640%40googlegroups.com.

[Naveen PS]

Hi Dustin,

First of all, thank you for taking your time to give a detailed response to my query. The main takeaways I get from your responses is that

1. Write my own code for the "bad" condition. - Till now I have been using tools, so I will go into the coding route to solve this issue

2. Implementation on real applications will give more context to the necessity of features of MQTT - As I am in the EdTech Industry, there is not necessarily any real life problem to solve, but just examples to drive the concept home. But now I understood the problem. I can only learn these condition when I really implement to solve some real problems(however small it might be).

3. Wireshark is just for observing what we are already doing.

Again, thanks for your time.

Naveen PS