0

I got the sample Mqttnet code (for publish and subcribe) from GitHub https://github.com/dotnet/MQTTnet/tree/master/Samples/Client

I am sending MQTT message to hivemq.cloud free private cluster port 8883. Also, I am using the HIVEMQ web client to monitor the message.

Case 1: (Works)

  • Mqttnet subscribe code starts on Visual Studio, waiting for message
  • Go to HIVEMQ web client and send a message to the topic
  • Mqttnet subscribe receives the message no problem, payload is Base64 encoded

Case 2: (Works)

  • Mqttnet publishing code starts on Visual Studio, send a message
  • .NET code sends a message to HIVEMQ server on port 8883
  • On HIVEMQ web client, I can see the message arrives in plain text

Case 3: (Doesn't work, it crashes the subscribe .net code)

  • Mqttnet subscribe code starts on Visual Studio, waiting for message
  • Mqttnet publishing code starts on Visual Studio (another instance)
  • .NET code publishing code sends a message to HIVEMQ server on port 8883
  • On HIVEMQ web client, I can see the message arrives in plain text
  • Mqttnet subscribe code exits on Visual Studio (CRASHED!??)

I even enabled the trace and packet inspection on the subscribe code and didn't really help, it disconnecting!!??

[2023-03-10T21:34:19.5712988Z] [6] [MqttChannelAdapter] [Verbose]: TX (2 bytes) >>> PingReq
IN: 0AA=
[2023-03-10T21:34:19.6718628Z] [8] [MqttChannelAdapter] [Verbose]: RX (2 bytes) <<< PingResp
>> [2023-03-10T21:34:25.6594214Z] [8] [MqttClient] [Verbose]: Stopped sending keep alive packets.
[2023-03-10T21:34:25.6598077Z] [8] [MqttClient] [Verbose]: Disconnecting [Timeout=00:01:40]
[2023-03-10T21:34:25.6615719Z] [8] [MqttClient] [Verbose]: Disconnected from adapter.
[2023-03-10T21:34:25.6635716Z] [8] [MqttClient] [Info]: Disconnected.
[2023-03-10T21:34:25.6641304Z] [8] [MqttClient] [Verbose]: Stopped receiving packets.

Case 4: (Doesn't work, it crashes microPython code on Raspberry Pi Pico W)

  • MicroPython subscribe code (umqtt.simple) runs on Pico W
  • Mqttnet publishing code starts on Visual Studio
  • .NET code publishing code sends a message to HIVEMQ server on port 8883
  • On HIVEMQ web client, I can see the message arrives in plain text
  • MicroPython code crashed. This is the error:
 Traceback (most recent call last):
 File "<stdin>", line 65, in <module>
 File "/lib/umqtt/simple.py", line 204, in check_msg
 File "/lib/umqtt/simple.py", line 173, in wait_msg
 OSError: -1

Case 5: (Works on my Raspberry Pi Pico W)

  • MicroPython subscribe code (umqtt.simple) runs on Pico W
  • Go to HIVEMQ web client and send a message "webclient test" to the topic
  • MicroPython receives the message properly:
  connected
  ip = 192.168.0.15
  message: webclient test

I seriously cannot figure out what is wrong. Any MQTT expert can help me would be appreciated?

userb00
  • 589
  • 1
  • 8
  • 16

1 Answers1

1

I am answering my own question, finally I figured it out. It was the client ID when I was using MqttClientOptionsBuilder(). I set the same client ID in both PUBLISH and SUBSCRIBE code with the option: mqttClientOptions.ClientId

Similar goes to the micropython code. What threw me off were 2 things:

  1. HIVEMQ web client didn't have problem because it doesn't need to set any clientID, so it always receives everything
  2. I didn't expect it would actually CRASH the subscriber. So if some bad guy know a device client ID for an IoT device, they can easily crash it by sending a publish message with the same Client ID. Maybe my SUBSCRIBE code isn't robust enough for reconnecting, but I assume many cheap IoT device may have this issue.
userb00
  • 589
  • 1
  • 8
  • 16
  • This is why a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) is important; I guessed this was most likely your issue, and checked the code you linked to, but that did not set the Client ID. The [MQTT spec](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349242) says "A Server MAY allow a Client to supply a ClientId that has a length of zero bytes, however if it does so the Server MUST treat this as a special case and assign a unique ClientId to that Client.". See `Client_Connection_Samples.cs` for info on reconnecting. – Brits Mar 12 '23 at 07:46