search

PelionIoT / mbed-coap

CoAP C library - Builder and Parser for CoAP messages
Apache License 2.0
29 stars 16 forks source link

Problem with blockwise transfers that are even increments of block_size #24

Closed ke6zfi closed 5 years ago

ke6zfi commented 7 years ago

Sending via blockwise response a 4096 byte packet with 1024 byte blocks, the last packet (Block 3) still sets the more flag. This is causing the server (Leshan) to fault. Appears issue is using a ">" check rather than a ">=" check on sn_coap_protocol.c:1602 and sn_coap_protocol.c:1976.

Thanks, Chris

anttiylitokola commented 7 years ago

Hi Chris,

Thanks for your report.

I tried to reproduce your problem but I couldn't get even that far. Write request goes through fine with 4096 bytes but when reading value back Leshan just timeouts. Wireshark capture shows that client is requesting more blocks but server is not sending new GET request. Can you share the steps how you were able to see this problem?

wireshark

ciarmcom commented 7 years ago

ARM Internal Ref: IOTCLT-1904

ke6zfi commented 7 years ago

Antti,

Try this version of Leshan: https://hudson.eclipse.org/leshan/job/leshan/297/artifact/leshan-server-demo.jar

I am doing a read when the issue occurs.

Notice packet 87 (Block #3) the More flag is set. This is a 4096 byte message. When Leshan tries to read Block #4 because the More bit was set, it gets back nothing (hence the really small size of Packet 89). wireshark_4096_issue

Here is my main.cpp from mbed-client-linux-example. main.cpp.txt

Read /4/0/2 after the first "Incrementing Resource Value". It will show a timeout in Leshan due to the bug, but wireshark should show it.

Let me know if you need any further info to reproduce this.

anttiylitokola commented 5 years ago

This has been fixed so closing the issue.