-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]: Missing block number (Blockwise Transfer) #1359
Comments
Are you running release code for 4.3.4, or code in the latest develop branch? It appears that you are just running 4.3.4 with no patches. Fix #1288 is post release 4.3.4 |
Thanks for the prompt reply @mrdeep1. Checking against the develop branch (c88c783), I have the following exchange: if 4 blocks of data with the following block numbers are sent to the server, the server fails to return the expected error code and return 2.01 code. Block number 1: 10 Please also check the wireshark log from server. Debug Logs
|
Unfortunately, the pcap trace is only for packets coming from the server, not packets from the client to the server so am not easily able to reproduce your situation without crafting my own packets which takes time. A pcap of the client to server packets would help a lot here. This does look like an application level programming issue (within the example coap-server code) possible confused by what is happening at the libcoap layer. It would be interesting to see what effect using the -L3 option is for the coap-server. This enables the libcoap layer to do all of the block handling before it is passed up to the application layer for processing the entire body of the blocked transfer in 1 go. |
Hello, Here are the pcap trace for the client generated packets. I am not using coap-server. I have my own test harness. The harness reads the packet from file and calls |
Thanks for the client files. In your test harness, you can choose whether libcoap is going to be doing the Block1 handling to assemble the body of data, or your test harness (which is the application layer) to do the assembly of the body of data, sending back the appropriate response codes. To get libcoap to handle everything, then you need to set If you add in the line
into your test harness, this will get libcoap to do the assembly of the body of data for you, returning error codes as appropriate. That said, with COAP_BLOCK_SINGLE_BODY enabled, response 5.00 is returned for packet 1 and 4 which is returned by the application layer of my coap-server which needs to be looked at. |
Please see #1362 where the libcoap library Please note that if With Please update us with any issues found with #1362. |
Thank you for the quick fix. I will look into this and let you know as soon as possible. |
@bathooman Can this be closed now? |
Yes. Let's close this for now. Thanks. |
Environment
libcoap Configuration Summary
Problem Description
The server fails to responds with the appropriate return code in case of inconsistent block numbers. The problem is already reported previously here.
Expected Behavior
According to RFC7959:
Actual Behavior
The resource is created on the server instead of returning the expected error code.
Steps to reproduce
if 4 blocks of data with the following block numbers are sent to the server, the server fails to return the expected error code.
Block number 1: 0
Block number 2: 13
Block number 3: 2
Block number 4: 15
You can find the wireshark log attached here.
missing-blocks.zip
Debug Logs
The text was updated successfully, but these errors were encountered: