Long time no see devRant. This rant is dedicated to an MQTT implementation we use. Mosquitto, mqtt.js - FUCK YOU.

I spent the last fucking 30+ hours trying to find why the bloody fuck the stupid server / client won't connect to the shitty mqtt broker. From changing all possible config, enabling & disabling specific code nothing abso-fucking-lutely works.

But then it will randomly decide to connect to the fucking broker, not causing any issues at all. And each fucking day when I wake up again and think to myself: oh today I can actually leave when it is still somewhat bright outside - NOPE. Because guess what? The fucking shitty abomination doesn't work anymore.

I just love these types of problems that are almost impossible to debug because the only logs you get is: "SERVER disconnected". It's impossible to get a proper reason out of this shit show, it's just turned into randomly guessing what the error could be (and especially where it could be).

And each time I got it to work, tested it and let the testing team know that they can start testing it will just stab me in the back and be like "fuck you, I'm not working any more". Luckily it's not like the deadline is next week... otherwise work is great, trust me.

  • 0
    Holy shit, I'm gonna have MQTT at uni this year. Now I'm scared!
  • 1
    @Khazbs MQTT is in general a really nice system. But it depends on your sever config etc. how nicely it works. The concept in general is quite good. I’m just ranting out of frustration. You shouldn’t be scared based on rants 😛
  • 1
    @tombjarne Oh well, thanks! And best of luck to you overcoming the matters.
  • 0
    @Khazbs haha thanks 😁. Trying but it’s not really resolving. It’s always stressful with deadlines close by…
  • 2
    That looks like a timeout issue with either mqtt or the network. We usually handle those by keeping short connections instead of a long one. Not too experienced with MQTT though, so I am just guessing.
  • 1
    Have you tried increasing the timeouts and enabling (frequent) heartbeats? If all else fails, try to not reuse the connection but create a new connection on each tick (just for testing purposes).

    One thing that happened to us was the broker decided to close the connection which was (ofc) not picked up the clients until it was too late. And, at the time, they weren't able to simply reconnect.

    Also try to add more logging if possible... Good luck!
  • 0
  • 0
    @IntrusionCM on an Apache server?
  • 1
    @SuspiciousBug I tried actually, but that did not help :/ Bit thanks for the thought!
  • 1
    @tombjarne you can run tcpdump on the server and transfer it to your local machine. Tshark if you know what you're looking for is Wireshark for the CLI.

    If space on the server is an issue, streaming the tcpdump directly via SSH is possible.
  • 1
    @IntrusionCM good thought, although it might not even reach the server due to some error (probably some misconfiguration with the proxy and web sockets). But I’ll give it a try 👌✌️
  • 1
    @tombjarne as long as it is not encrypted traffic, you should see if it's going out and wether it reaches destination or not.

    I had many cases where Wireshark wasn't necessarily the solution, rather the muse to give me the right inspiration....

    Be it that TCP packages were sent on the wrong port (configuration fuckups on snowflake machines where one didn't find the "right" configuration in an ocean of possibilities), it definitely didn't get routed properly, etc etc.

    Many hate Wireshark, which I cannot understand. Complex, yes. But incredibly useful.
  • 1
    @IntrusionCM Wireshark is one of those tools one really needs to learn how to appreciate. Definitely agree on that, and as you said really useful. I used it in some other security scenarios before. Oh and luckily the MQTT parcels are not encrypted
Add Comment