Closed sesponda closed 4 years ago
Hi @sesponda ,
Here is okay.
Initialising the CoapPacket class would fix the exception.
My ESP8266(ESP-12F) and ESP32 works well, but your point is right.
Please send a PR, I think maybe add CoapPacket() {optionnum = 0; payloadlen = 0; tokenlen = 0; token = NULL; messageid = 0;};
at CoapPacket class in coap-simple.h .
The branch that attempts to execute server callbacks should not be run if the packet is not a request type
You could check CoapPacket &packet
and reply/ignore response packet to the client. In this library, request type handling and processing entrust to the application after endpoint url matching(endpoint url not found is COAP_NOT_FOUNT error response).
Thank you.
Hello,
I'm using the library with an esp8266 project. If I use just the client, ignoring all UDP input processing (i.e. not calling
loop()
) everything works fine. However, when usingloop()
sometimes the controller resets due to an exception accessing memory (stack trace and analysis below at the end).The offending line seems to be https://github.com/hirotakaster/CoAP-simple-library/blob/1945070cccdb3254775b9679c1bc40621c9b8451/coap-simple.cpp#L276
More debugging revealed the following:
(COAP_HEADER_SIZE + packet.tokenlen < packetlen)
can be false, thus the branch at https://github.com/hirotakaster/CoAP-simple-library/blob/master/coap-simple.cpp#L245 is not executed. Therefore,packet.optionnum
is not initialised.https://github.com/hirotakaster/CoAP-simple-library/blob/master/coap-simple.cpp#L275 (for non ACK packets).
for
loop would attempt to parse options beyond the maximum expected.If I initialise the
CoapPacket
fields to zero, the problem is fixed.Another, unrelated problem (which I'm not sure deserves another issue) is that it seems my CoAP server (different system) replies with packets type=0 (CON) code=2.31 (success/continue). The code assumes that all non-ACK packets are GET/PUT/POST/DELETE, so it will reply to these packages sending
COAP_NOT_FOUNT
. I'm new to CoAP so I'm not sure if what the other server is doing is really valid (maybe is doing this to keep checking the device?). However, I think the code could still be improved to avoid sending NOT_FOUND for non-request packets.In summary, I think:
CoapPacket
class would fix the exception.Stacktrace:
Analysis: