ESP8266 gateway crashes when configuration reply received from child node

[mitchmitchell]

I am testing sending a configuration message to a subordinate node of my ESP8266 gateway device to setIsMetric to one and back to zero. The gateway device handles the message sent to it fine and relays it to the subordinate HyTiny which successfully changes its mode to metric and back as expected. However when the gateway receives the reply message from the HyTiny board it crashes. The message the HyTiny sends is:

SEND D=0 I=200 C=0 T=48 S= I=0 F=0.00
1240480 TSF:MSG:SEND,102-102-0-0,s=200,c=1,t=48,pt=5,l=4,sg=0,ft=0,st=OK:22

When the gateway receives this message it crashes in the call to strtok_r at line or near line 191 at the statement below because at that point the value of the pointer string is zero.

_child_id = atoi(strtok_r(const_cast<char*>(string), ",", &ptr));

This is in the function:

// contructor, tokenize a request in the format "child_id,function,value"
Request::Request(int recipient_child_id, const char* string) {

I'm afraid I don't have much to add at this point, I only just realized the crash was happening on the reply from the HyTiny rather than on the message to the gateway from the controller.

I will look further into the code to try and understand how the reply is getting constructed.

[mitchmitchell]

I believe the gateway is improperly treating the reply from the subordinate node as a configuration command to the gateway itself -- I don't know if this is because the reply is incorrectly constructed by the subordinate node or because it is being incorrectly interpreted by the gateway node as a configuration command.

[mitchmitchell]

Actually now I think the reply is properly relayed back by the gateway, here is the debug output from the ESP8266 serial port:

1592755 GWT:IMQ:TOPIC=mygateway1-in/102/200/2/0/48, MSG RECEIVED
1592764 TSF:MSG:SEND,0-0-102-102,s=200,c=2,t=48,pt=0,l=6,sg=0,ft=0,st=OK:0,42,0
1592771 TSF:MSG:READ,102-102-0,s=200,c=1,t=48,pt=5,l=4,sg=0:1522460360
1592777 GWT:TPS:TOPIC=mygateway1-out/102/200/1/0/48,MSG SENT
RECV S=102 I=200 C=1 T=48 P=
Before getting request: 200 string:
string: 0
before strtok on child_id
1073646160
before strtok on function_id
0

Exception (28):
epc1=0x4020be42 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont
sp: 3ffefa70 end: 3ffefdd0 offset: 01a0

>>>stack>>>
long stack trace here...

This is for a configuration command of "0,42,0" -- it appears the gateway is properly relaying back out via the MQTT bus. I'm really not certain about what is happening a this point.

[mitchmitchell]

Ok I stopped the crashing with apparently no other side effects by adding a check for a null string in the void SensorConfiguration::onReceive(MyMessage* message) function, see below:

void SensorConfiguration::onReceive(MyMessage* message) {
// expect a REQ, V_CUSTOM message
if (message->getCommand() != C_REQ && message->type != V_CUSTOM) return;
// parse the request
if (message->getString() == NULL) return;
Request request = Request(message->sensor,message->getString());
int function = request.getFunction();
int child_id = request.getChildId();
// if the message is for the board itself

[mitchmitchell]

I still have no idea how the function was being called with a message that resulted in no string pointer, except that I found in MyMessage.cpp that if the payload type is not P_STRING getString() returns a NULL.

const char* MyMessage::getString() const
{
	uint8_t payloadType = miGetPayloadType();
	if (payloadType == P_STRING) {
		return data;
	} else {
		return NULL;
	}
}

[user2684]

Thanks for your tests! Your check for a null string is definitely a good solution, I've labeled this as a bug and fix it in the next release. However, it is still unclear to me why this is going through the remote API. Which piece of code is triggering that SEND D=0 I=200 C=0 T=48 S= I=0 F=0.00?

[mitchmitchell]

That message was logged from the serial port on the HyTiny board (e.g. the subordinate node 102). I'll have to dig to see where it was actually triggered.

[mitchmitchell]

I believe it is coming from this line:
_node->sendMessage(CONFIGURATION_CHILD_ID,V_CUSTOM,function);
at the bottom of SensorConfiguration::onReceive(MyMessage* message)
in the HyTiny node when it receives the configuration command.

[mitchmitchell]

I added a Serial.print statement above that line on the HyTiny and tried sending a custom message with a payload "0,22,0" setIsMetric(0) and this is the output:

RECV S=0 I=200 C=2 T=48 P=0,22,0
REQ C=0 F=22 V=0.00
about to execute _node->sendMessage(CONFIGURATION_CHILD_ID,V_CUSTOM,function); with function value: 22
SEND D=0 I=200 C=0 T=48 S= I=0 F=0.00
67360 TSF:MSG:SEND,102-102-0-0,s=200,c=1,t=48,pt=5,l=4,sg=0,ft=0,st=OK:22

[mitchmitchell]

Here is the output from the ESP8266 gateway serial port when it receives the message sent by the HyTiny above (the third line is where it receives the message from the HyTiny).

22356397 GWT:IMQ:TOPIC=mygateway1-in/102/200/2/0/48, MSG RECEIVED
22356405 TSF:MSG:SEND,0-0-102-102,s=200,c=2,t=48,pt=0,l=6,sg=0,ft=0,st=OK:0,22,0
22356412 TSF:MSG:READ,102-102-0,s=200,c=1,t=48,pt=5,l=4,sg=0:22
22356418 GWT:TPS:TOPIC=mygateway1-out/102/200/1/0/48,MSG SENT
RECV S=102 I=200 C=1 T=48 P=

[user2684]

Thanks a lot, I'll dig into it and let you know in case I will not be able to reproduce it. Meanwhile I've marked it as a bug and added to the v1.8 queue. Thanks