Obs Con blockwise fails to transmit 2nd block

[ke6zfi]

An observed resource is pushing a 6kb Opaque, the first 1024byte block (Block 0) gets sent, the server (Leshan), acknowledges with an empty message, then requests "End of Block 1". However the response to the "End of Block 1" (with the same MID as the request), is Block 0. I am able to successfully read the 6kb Opaque, and in that cause after the End of Block 1, Block 1 is sent. From looking at the debug messages, the code seems to take a different path processing the End of Block 1 coming from an observation push, then coming from a read request. I believe this code path is causing it to start over in the message sending process.

[ciarmcom]

ARM Internal Ref: IOTCLT-1678

[anttiylitokola]

Hi,

Thanks for your report. I haven't able to reproduce your issues yet using Leshan server. In my tests the whole blockwise is not working against Leshan, even the basic GET request is returning timeout(500). Block size is set to 1024b and I have resource which contains more than 2000 bytes.

Can you share the Leshan server version that you are using? I tried with following one: https://hudson.eclipse.org/leshan/job/leshan/349/

I have verified that the same example code is working fine against our Connector, both GET and notifications are working fine.

[ke6zfi]

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

Here is my packet trace, showing Leshan reporting it wants Block 1, but getting Block 0 again from the mbed-client. obs_fail_pcap.zip

My hacked up mbed-client-linux-example: main.cpp.txt

To duplicate: Compile the mbed-client-linux-example replacing source/main.cpp with the above file.

• Run the above leshan-server-demo.jar,
• Load http://localhost:8080 in a browser
• Run mbed-client-linux-example, very quickly under the Leshan Clients packet, click on ENDPOINT_NAME. Go down to Object 10245 Resource Test, click observe. This need to happen before the first update (so the packet is still small). In wireshark you should see the issue occur.

---

• Kill both the client and leshan.
• Run Leshan
• Run the client
• From the Leshan web UI, after the resource has updated (wait 15 seconds), press read, you should now see a array of data returned, and Wireshark show the correct blockwise sequence.

Thanks!

[anttiylitokola]

Hi, There is now fix proposal under review if you would try it out. https://github.com/ARMmbed/mbed-coap/pull/15

[ke6zfi]

Thanks for sending me that fix, it seems to be working the correct sequence now. However it does have a different problem. The blockwise packets content length vary, some are 1024, some are a little bigger and a little less. I have attached a new version of main.cpp that sequences the data. If you look at the traces, the packets > 1024 have extra data, the packets < 1024 are missing data. When I do a read, all the blocks are 1024 bytes and correct. - Thanks main.cpp.txt

[anttiylitokola]

Thanks for your finding. There is now fix available and package length should be correct now, Fix is there in the same PR.

[JanneKiiskila]

Fixes are now merged to mbed-coap master. Closing this issue now.

Thank you for your support!

[JanneKiiskila]

https://github.com/ARMmbed/mbed-os/pull/4332 - pull request going on to mbed-OS as well.