wakaama: Endless loop when client responds with large payload without block transfer

Test scenario: A wakaama server issues a READ command to a client. When the client replies with a payload bigger than REST_MAX_CHUNK_SIZE, the wakaama server responds with “4.13 Entity too large” and advertises its configured block size with a new GET request and block2 option set. If the client does not handle the block2 GET correctly and again send a too large payload this results in an endless loop. Ideas on how this can be handled, maybe a max retry count on the server side? I tested with wakaama server and zephyr lwm2m client.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (15 by maintainers)

Most upvoted comments

It’s clearer with the capture, thx 🙏. Sorry for confusion, but this change my understanding again about the first point 😅 … My first guess was right, there is an issue with the 4.13. It must not be send by the server when receiving a too big response. (unfortunately, I think there is no way in CoAP to inform the client in this case)

About the second point (infinite loop), Regarding the RFC7959 :

To influence the block size used in a response, the requester MAY also use the Block2 Option on the initial request, giving the desired size, a block number of zero and an M bit of zero. A “CoAP” server (“in our case LWM2M client”) MUST use the block size indicated or a smaller size.

I think behavior defined in https://github.com/eclipse/wakaama/issues/536#issuecomment-775965260 should be OK

IF server receive a too big payload to a request sent without block2 option THEN it could retry with block2 option.
IF server receive a too big payload to a request sent with block2 option THEN it should consider there is nothing to do and so report the error to application layer.

If device can not use block2 option and payload is still too big, I think there is nothing more to do. This prevent infinite loop and avoid the need to add a new state (a kind of counter).

sbernard31 on Feb 9, 2021

When I think about it should be that we always ACK only, it is a response and not an request. We ACK that we have received it if there is any problem (like it is to large) it is up to the server to take appropriate action (like retrying the request as a block2).

tuve on Feb 19, 2021