-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mqttClient error: invalid operation. Wemos D1 Mini #112
Comments
I suspect this is a buffer overflow or uninitialised variable or something similar. Trivial changes to the data can make it fail or run successfully. |
Thanks for the report. I'll try to reproduce this on my set-up. The error being reported, invalid operation, appears to be coming from the MQTT parser of received data. It indicates that the first byte of a message from the broker is an invalid MQTT opcode (either 0 or 15). |
I wasn't able to reproduce the same error. Here's what I tried:
That would work for a bit and then eventually fail with a "fragmented receive unimplemented" exception. That is a reminder to me to implement fragmented MQTT receive. So I did. That's committed. Now the flow runs solidly for me on ESP8266 (several minutes, no exceptions, messages continuously received). I don't think this is the same error you saw, as it would have cause the ESP8266 to reboot instead of reporting "mqttClient error: invalid operation. I think you are running a different MQTT Broker, probably something local. Should I try to match that? Other ideas for how I might be able to reproduce this? |
No, that isn't the same problem. For me the flow fails immediately on the first message received. I am using mosquitto locally. I will see if I can make it fail with the public test broker. |
Ok, I have it failing with test.mosquitto.org.
I build and run it on a Wemos D1 Mini using
and as soon as I click the Inject node, xsbug shows |
@colinl – with your updated instructions, I can reliably reproduce the problem! It happens in the simulator as well as the ESP8266, so it isn't an MCU induced issue. I'll try to fix this later today. |
There was a bug in the parser in the short-circuit for 0 length payloads. Your test payload has a length of 256 bytes and the length of 0 in the first byte erroneously triggered the short-circuit. The mistake is here. The fix will be live tomorrow. If you want to verify it before then, here's the updated version: // remaining length
case 1:
byte = socket.read();
parse.length = byte & 0x7F;
if (byte & 0x80)
parse.state = 2
else {
parse.state = parse.operation << 4;
if (!parse.length) { // no payload - handle immediately (PINGREQ, PINGRESP, DISCONNECT)
if (this.#parsed(parse))
return;
parse = {state: 0};
}
}
break; I've confirmed this works on both the simulator and ESP8266. Thanks again for taking the time to isolate this to a simple test case. That made fixing this very straightforward. |
I seem to have a knack of hitting issues like that. |
Excellent, I applied the patch and it is working well. |
Woohoo! |
Have you had a chance to commit this? I am not seeing it yet. |
Thanks for the reminder. Friday got busy. We posted the update earlier today. |
Latest source from repo tested. |
Excellent, thank you. |
I have a trivial flow consisting just of an mqtt In node feeding a debug node, running on a Wemos D1 Mini.
For some particular combinations of topic and data then every time I publish the data to that topic, in xsbug I see
mqttClient error: invalid operation
and in the mosquitto log I see the client disconnect and reconnect again
If I change the topic or the data then it works fine, which is very odd. So far this is the only combination of topic and data that I have found that fails:
topic: "tydwr/mcu/config"
and data
This is the flow in the D1 Mini
This is the Inject node used to publish the data from the machine running the broker
I am running the latest node-red-mcu pulled from github. I am not using the node red plugin for this test.
The text was updated successfully, but these errors were encountered: