Error code 4.08 is not being returned when previous block is missing.
Closed this issue · 4 comments
Environment
- Build System: [Make]
- Operating System: [Linux]
- Operating System Version: [Debian GNU/Linux 12 ]
- Hosted Environment: [None]
libcoap Configuration Summary
`$ ./configure --prefix=/home/libcoap_2023_10_22/libcoap/build --disable-manpages
#define PACKAGE_NAME "libcoap"
| #define PACKAGE_TARNAME "libcoap"
| #define PACKAGE_VERSION "4.3.1"
| #define PACKAGE_STRING "libcoap 4.3.1"
Problem Description
The server is not producing the error code 4.08 when it receives the final block and some block is missing.
Expected Behavior
According to RFC7959:
"If not all
previous blocks are available at the server at the time of processing
the final block, the transfer fails and error code 4.08 (Request
Entity Incomplete, Section 2.9.2) MUST be returned. "
Actual Behavior
I don't receive the error code 4.08, i receive the code 0.00 when the server receives the final block and a block is missing.
Steps to reproduce
You can use the server and client examples in the example folder. Do a PUT request to the server, with a block size of 32 and a total size of 111 for the whole payload. The second block that is being sent to the server has a block number of 2 and not 1 which means that block number 1 is missing.
Debug Logs
First block server receives:
v:1 t:CON c:PUT i:5f8b {01} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:0/M/32, Size1:111, Request-Tag:0xa529346b ] :: 'helllohellohellollllooooollloooo
Produces:
v:1 t:ACK c:2.31 i:5f8b {01} [ Block1:0/M/32 ]
Second block server receives:
v:1 t:CON c:PUT i:5f8c {02000000000003} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:2/M/32, Size1:111, Request-Tag:0xa529346b ] :: 'oeeeeeeedasfdsafdsafdsfdsdsadsad'
Produces:
v:1 t:ACK c:2.31 i:5f8c {02000000000003} [ Block1:2/M/32 ]
Third block server receives:
v:1 t:CON c:PUT i:5f8d {03000000000003} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:3/_/32, Size1:111, Request-Tag:0xa529346b ] :: 'sadsadsadsadsad'
Produces:
v:1 t:ACK c:0.00 i:5f8d {} [ ]
@sabor12345 Thanks for raising this. I am unable to reproduce you getting an empty ACK back with the examples coap-server, so you must be running the server with some normally unused option.
#1288 Has a fix to report 4.08 if a Block1 request is received and the previous Block1 was not received. Please try this out.
Hi!
I think i got an empty ACK back with the examples coap-server because in the server i used:
static uint32_t block_mode = COAP_BLOCK_USE_LIBCOAP | COAP_BLOCK_SINGLE_BODY;
I tried out your fix, and it works now. I just want to ask if you fixed this after I reported this issue, I want to know just for my report? (I guess you fixed it after i reported because fix has number #1288).
@sabor12345 I fixed this after you raised this.
The only reason I can think of the empty ACK is that the PUT handler you are using does not update the response PDU code before returning from the PUT handler.
Can this be closed now?