Comments (9)
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
from libcoap.
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
Block number 2: 0
Block number 3: 10
Block number 4: 10
Please also check the wireshark log from server.
Debug Logs
Apr 15 11:13:11.685 DEBG created UDP endpoint 0.0.0.0:5683
Apr 15 11:13:30.528 DEBG ***0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : session 0x44a060: new incoming session
Apr 15 11:13:30.528 DEBG ***EVENT: COAP_EVENT_SERVER_SESSION_NEW
v:1 t:CON c:PUT i:4b2d {01} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:10/M/32, Size1:111, Request-Tag:0xa9fa532b ] :: 'helllohellohellollllooooollloooo'
Apr 15 11:13:30.528 DEBG call custom handler for resource 'example_data' (3)
Apr 15 11:13:30.528 WARN No cache entry available for the non-first BLOCK
Apr 15 11:13:30.529 DEBG * 0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : netif: sent 5 bytes
v:1 t:ACK c:5.00 i:4b2d {01} [ ]
v:1 t:CON c:PUT i:4b2e {02000000000003} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:0/M/32, Size1:111, Request-Tag:0xa9fa532b ] :: 'oeeeeeeedasfdsafdsafdsfdsdsadsad'
Apr 15 11:13:57.113 DEBG ** 0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : lg_srcv 0x44d020 initialized
Apr 15 11:13:57.113 DEBG call custom handler for resource 'example_data' (3)
created cache_entry
Apr 15 11:13:57.113 DEBG * 0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : netif: sent 14 bytes
v:1 t:ACK c:2.31 i:4b2e {02000000000003} [ Block1:0/M/32 ]
v:1 t:CON c:PUT i:4b2f {03000000000003} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:10/M/32, Size1:111, Request-Tag:0xa9fa532b ] :: 'sadsdasdsadsadsadsadsadsadsadsad'
Apr 15 11:15:15.175 DEBG ** 0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : lg_srcv 0x44d020 released
Apr 15 11:15:15.175 DEBG * 0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : netif: sent 25 bytes
v:1 t:ACK c:4.08 i:4b2f {03000000000003} [ ] :: 'Missing block'
v:1 t:CON c:PUT i:4b30 {04000000000003} [ Uri-Path:example_data, Content-Format:application/link-format, Block1:10/_/32, Size1:111, Request-Tag:0xa9fa532b ] :: 'sadsadsadsadsad'
Apr 15 11:15:26.286 DEBG call custom handler for resource 'example_data' (3)
Apr 15 11:15:26.286 DEBG * 0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : netif: sent 11 bytes
v:1 t:ACK c:2.01 i:4b30 {04000000000003} [ ]
Apr 15 11:15:28.434 DEBG ***0.0.0.0:5683 <-> 0.0.0.0:9090 UDP : session 0x44a060: closed
from libcoap.
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.
from libcoap.
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 coap_handle_dgram()
for each packet.
from libcoap.
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 COAP_BLOCK_SINGLE_BODY
.
If you add in the line
coap_context_set_block_mode(COAP_BLOCK_USE_LIBCOAP | COAP_BLOCK_SINGLE_BODY);
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.
from libcoap.
Please see #1362 where the libcoap library coap_handle_request_put_block()
has been re-written / updated to handle the corner cases that your packets were testing.
Please note that if coap_context_set_block_mode()
is not called at all in your server test harness, or just coap_context_set_block_mode(COAP_BLOCK_USE_LIBCOAP)
is called, all request packets will get passed to the application layer where it is the responsibility of the application layer to decide what to do with missing or re-ordered packets.
With coap_context_set_block_mode(COAP_BLOCK_USE_LIBCOAP | COAP_BLOCK_SINGLE_BODY)
, the libcoap layer is doing all he necessary checking.
Please update us with any issues found with #1362.
from libcoap.
Thank you for the quick fix. I will look into this and let you know as soon as possible.
from libcoap.
@bathooman Can this be closed now?
from libcoap.
Yes. Let's close this for now. Thanks.
from libcoap.
Related Issues (20)
- Request token is unexpectedly replaced with nonsense HOT 15
- Q-Block support detection fails in some cases HOT 5
- [Non-conformance] Handling CoAP Invalid Versions HOT 2
- No callback if DTLS connection with OpenSSL server and client fails due to PSK mismatch HOT 3
- Add coap_get_resource_from_uri_path() to man pages. HOT 2
- HTTP/S Support for Proxy URIs in CoAP to HTTP Proxy HOT 4
- [Non-conformance] Handling Unreapeatable Options HOT 1
- Incorrect header passed to response_handler after finishing Replay Window scenario. HOT 7
- Actively denying a new session HOT 4
- Failing to set mtu when WOLFSSL_DTLS_MTU is enabled HOT 1
- Assertion !lock->in_callback failed in coap_lock_lock_func() during application shutdown HOT 10
- Build with wolfSSL not loading certificates on server side HOT 3
- Memory leak in LwIP function `coap_udp_recvs` HOT 1
- PDU use after free when sending an OSCORE message with OSCORE disabled at build time HOT 5
- coap-client binary PSK HOT 17
- [Question] Proxy-scheme and proxy-uri example with coap-client and coap-server applications HOT 6
- Make coap_print_wellknown customizable HOT 6
- Wrong
- Access Token option addition to libcoap HOT 1
- Clarification on cancelling a block-wise request in the middle of transaction at client's end HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libcoap.