Open benpicco opened 3 months ago
It happens because first we assume more=true
--> [block num 0, more 1, szx 0]
. It is encoded as 3 bytes 0xd1, 0x06, 0x08
. Meaning delta 13 + 6 , length 1. Now when we correct the more
flag in coap_block_finish()
the option value becomes 0. The encoded option value unsigned integer 0 has length 0. That means 0xd1
in the previous encoding becomes 0xd0
. The byte sequence left in the packed buffer becomes 0xd0, 0x06, 0x08
. This decodes as the correct block option and the 0x08
which is a leftover of the first encoding.
The issue is that an option written to a buffer is rewritten with a smaller option length, because the option value bacame actually 0.
Thank you, that explanation makes perfect sense!
So the (long) option gets first written by coap_opt_add_block2()
, then it is overwritten later by coap_block2_finish()
with a shorter option, leaving two garbage bytes before the next option starts.
Description
When requesting 16 byte block size, the server will respond with an invalid packet.
Steps to reproduce the issue
run
examples/gcoap_fileserver
:make -C examples/gcoap_fileserver PORT=tap1 all term
create a dummy file
echo "Hello World!" > examples/gcoap_fileserver/native/me
Try to access the file via e.g.
ncget
with a 16 byte block sizeExpected results
We get the response in a single block
Actual results
We get the response in a single block, but there is some garbage after the block2 option:
gcoap_fileserver.pcapng.gz
Versions
RIOT master