Message-type error

[sabor12345]

Hi!

I have tested your library and found an issue which i would like to report.

cantcoap

Commit e7bb846

Problem Description

In a coap message, the message type is not used correctly.

Expected behavior

According to RFC7252 (https://www.rfc-editor.org/rfc/rfc7252) the message types can used as in the image below. :

Actual Behavior

For instance, a confirmable message can be of type reset.

The server receives this message and proceeds.

Valid CoAP PDU received
__________________
PDU was constructed from buffer of 500 bytes
PDU is 15 bytes long
Message Type: Reset
Token length: 4
Code: 0.01 GET
Message ID: 5
Token of 4 bytes.
   Value: 0x03020101 
2 options:
OPTION (1/2)
   Option number (delta): 11 (11)
   Name: URI_PATH
   Value length: 4
   Value: "test"
OPTION (2/2)
   Option number (delta): 12 (1)
   Name: CONTENT_FORMAT
   Value length: 1
   Value: ")"
No payload.

Some questions:

Can you confirm this behavior? Were you aware of it? Is it intentional or an oversight?

Sincerely Sabor

[staropram]

Thanks sabor I will look into this and get back to you

4 Apr 2023 15:35:09 Sabor @.***>:

Hi!

Im testing a protocol that is using your implementation of COAP. The version that is used is commit: cce97e5[https://github.com/staropram/cantcoap/commit/cce97e570bfc918583ee7f2a3baf17ce9b754754]. Now i have started to test your implementation (commit cce97e5[https://github.com/staropram/cantcoap/commit/cce97e570bfc918583ee7f2a3baf17ce9b754754]) and i found this bug.

According to the RFC (https://datatracker.ietf.org/doc/rfc7252/) :

"The basic exchanges of the four types of messages are somewhat orthogonal to the request/response interactions; requests can be carried in Confirmable and Non- confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages."

In this case, when i send a message of type "reset" which is not empty, the message has a method code (it is a request), token value, options, and a payload, it is still processed by the server.

I think reset messages should be used in the case as mentioned in the RFC: "A Reset message indicates that a specific message (Confirmable or Non-confirmable) was received, but some context is missing to properly process it."

This is what is received on the server side:

[https://user-images.githubusercontent.com/50404269/229824933-7f892453-0661-4e6a-8895-74dc0f2f1a6f.png][image][https://user-images.githubusercontent.com/50404269/229824933-7f892453-0661-4e6a-8895-74dc0f2f1a6f.png][https://user-images.githubusercontent.com/50404269/229824933-7f892453-0661-4e6a-8895-74dc0f2f1a6f.png]

And this is what is created on the server side and received on the client side:

[https://user-images.githubusercontent.com/50404269/229825279-67753ffb-1dcc-4a71-9be5-87d4b7f7ed88.png][image][https://user-images.githubusercontent.com/50404269/229825279-67753ffb-1dcc-4a71-9be5-87d4b7f7ed88.png][https://user-images.githubusercontent.com/50404269/229825279-67753ffb-1dcc-4a71-9be5-87d4b7f7ed88.png]

Sincerely Sabor

— Reply to this email directly, view it on GitHub[https://github.com/staropram/cantcoap/issues/29], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AADJFRVUSE2Q4WM7QUNHLD3W7QWRLANCNFSM6AAAAAAWSZ2EVI]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AADJFRRIVXK7QEAECVBS66DW7QWRLA5CNFSM6AAAAAAWSZ2EVKWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGFFSKS4.gif]

[staropram]

what is it you are recommending?

[sabor12345]

Hi!

Maybe you could have a check, checking that a request is only of type Confirmable or Non- confirmable.

Also, a check that a message of type reset should only be sent as a reply to an Confirmable message or Non-confirmable message when some context is missing to process the received message.

Sincerely Sabor

[staropram]

thanks for checking the library rigorously against the specs, you've done a great job here.

at the moment i'm not sure when I'll get a chance to look at fixing them