[Non-conformance] Handling Unreapeatable Options
bathooman opened this issue · 1 comments
Environment
- Build System: [Make]
- Operating System: [Linux]
- Hosted Environment: [None)]
libcoap Configuration Summary
libcoap configuration summary:
libcoap package version : "4.3.1"
libcoap library version : "3.0.0"
libcoap API version : "3"
libcoap DTLS lib extn : "-notls"
host system : "x86_64-pc-linux-gnu"
build with server support: "yes"
build with client support: "yes"
build with TCP support : "yes"
build DTLS support : "no"
add default names : "yes"
build using epoll : "yes"
enable small stack size : "no"
enable separate responses: "yes"
build doxygen pages : "yes"
--> Doxygen around : "yes" (/usr/bin/doxygen 1.9.1)
--> dot around : "yes" (/usr/bin/dot 2.43.0)
build man pages : "no"
build unit test binary : "no"
build examples : "yes"
install examples source : "yes"
build with gcov support : "no"
build shared library : "no"
build static library : "yes"
Problem Description
Upon receiving a CoAP message with an unrepeatable option, LibCoAP fails to behave correctly.
Expected Behavior
According to RFC7252:
'''If a message includes an option with more occurrences than the option is defined for, each supernumerary option occurrence that appears subsequently in the message MUST be treated like an unrecognized option (see Section 5.4.1).'''
Section 5.4.1 states:
'''Options fall into one of two classes: "critical" or "elective". The difference between these is how an option unrecognized by an endpoint is handled:
o Upon reception, unrecognized options of class "elective" MUST be silently ignored.
o Unrecognized options of class "critical" that occur in a Confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).
o Unrecognized options of class "critical" that occur in a Confirmable response, or piggybacked in an Acknowledgement, MUST cause the response to be rejected (Section 4.2).
o Unrecognized options of class "critical" that occur in a Non-confirmable message MUST cause the message to be rejected (Section 4.3). '''
Actual Behavior
In this case, we have a confirmable message containing three occurrences of an unrepeatable option (Uri-Port). While the correct behavior is to reject by sending a 4.02 (Bad Option) , LibCoAP proceeds with a piggybacked response.
Steps to reproduce
A confirmable CoAp message with two occurrences of Uri-Port option can be used to reproduce the non-conformance. You can find the wireshark interaction in the following.
invalid-unrepeatable-options-handling.zip
Debug Logs
/libcoap/build/bin$ ./coap-server -v 8
May 13 16:07:31.945 DEBG created UDP endpoint [::]:5683
May 13 16:07:31.945 DEBG created TCP endpoint [::]:5683
May 13 16:07:34.161 DEBG ***[::ffff:127.0.0.1]:5683 <-> [::ffff:127.0.0.1]:4040 (if1) UDP : session 0x17f5b50: new incoming session
May 13 16:07:34.161 DEBG ***EVENT: 0x4001
May 13 16:07:34.161 DEBG * [::ffff:127.0.0.1]:5683 <-> [::ffff:127.0.0.1]:4040 (if1) UDP : received 80 bytes
v:1 t:CON c:GET i:0022 {22} [ Uri-Port:25856, Uri-Port:0, Uri-Port:0 ] :: 'n\x04cove\xFF\x01A\x01\x02\x03A\x01\x00\x04\x01\xBB\x04\x01\xBBAAAAAAAAAAAAAAAAAAA".wee|||||||||||||ek~\x00\x00\xFF\xFFco>>'
May 13 16:07:34.161 DEBG call custom handler for resource ''
May 13 16:07:34.161 DEBG * [::ffff:127.0.0.1]:5683 <-> [::ffff:127.0.0.1]:4040 (if1) UDP : sent 147 bytes
v:1 t:ACK c:2.05 i:0022 {22} [ Max-Age:196607 ] :: 'This is a test server made with libcoap (see https://libcoap.net)\x0ACopyright (C) 2010--2022 Olaf Bergmann <bergmann@tzi.org> and others\x0A\x0A'
May 13 16:12:34.162 DEBG ***EVENT: 0x4002
May 13 16:12:34.162 DEBG ***[::ffff:127.0.0.1]:5683 <-> [::ffff:127.0.0.1]:4040 (if1) UDP : session 0x17f5b50: close
It is worth checking the latest code version before reporting an issue. In this case, as of v4.3.2, options that are not repeatable should be tracked as expected. Please confirm this not an issue with the later code versions.