Skip to content
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

coap_packet_t - type of payload_len member #618

Closed
piotr276 opened this issue Jun 9, 2021 · 6 comments
Closed

coap_packet_t - type of payload_len member #618

piotr276 opened this issue Jun 9, 2021 · 6 comments

Comments

@piotr276
Copy link

piotr276 commented Jun 9, 2021

Hello,

Using wakaama client from examples I am implementing some basic firmware update functionality. I have added my implemenation to the "write" method of the firmware object. Sending files from the leshan server to my client is working fine, but surprisingly the maximum file size is limited to ~ca. 65 kB (u16 payload size). Is this intended?

I can see that in the coap_packet_t struct, the member payload_len is defined as uint16_t. But in many other places in wakaama client example code, the payload_len is defined as int or size_t.

For example:

void lwm2m_handle_packet(lwm2m_context_t* contextP, uint8_t* buffer, int length, void* fromSessionH);

is using "length" as int and in this function we have casting from int to u16 which looks strange to me:

packet.c -> line 476

coap_error_code = coap_parse_message(message, buffer, (uint16_t)length);

Could you be so kind and provide some clarification why the payload_size is defined in coap_packet_t as u16? Is this a requirement of CoAP protocol?

After I have changed this u16 to u32, everything working fine (at least in my "playground") and I am able to send files larger than ~65 kB succesfully.

@sbertin-telular
Copy link
Contributor

This limit probably came from the maximum UDP packet size of 65535 bytes. Anything larger will need to use block transfers. In practice, most packets should be much smaller to avoid fragmentation. I'm not familiar with the block handling, so I'll let someone else comment on that and where it may be limited by the payload length.

@piotr276
Copy link
Author

piotr276 commented Jun 9, 2021

You are right, but in the wakaama client -> the CoAP block size is set by defautl to 1024, so anyway for files larger than 1024 the block-wise transfer is triggered. IMO this should be possible also for files larger than 65 kB, but it is not due to this limitation in coap_packet_t (or I am doing something wrong - I am using "write" from the leshan demo server so the "write" method from client's firmware object is called - in my simple implementation I just copy the buffer content to the file). Without any changes in coap_packet_t struct for files larger than 65 kB there is an COAP_406_NOT_ACCEPTABLE in response for write operation from leshan server which is because there is a casting from int to u16, so the payload size is truncated and due to that, wrong size is passed further which ends in fail in one of if statements.

@mlasch
Copy link
Contributor

mlasch commented Sep 23, 2021

@piotr276 you're doing it right, this is also an issue on the server side. Writes larger than 65kB will be truncated because of the implicit type conversion. No error is reported, the write will just finish ordinarily.

My suggestion would also be to increase the payload_len preferably to size_t which would allow larger writes. size_t is already used in some parts of Wakaama to store buffer lengths. The UDP packet size limit should not be an issue because block transfer will be used anyways as you said above.

@tuve
Copy link
Contributor

tuve commented Sep 27, 2021

I agree we should change the payload_len to size_t, this is just an oversight that it did not change when we introduced block transfer.

mlasch added a commit to mlasch/wakaama that referenced this issue Sep 27, 2021
Use size_t to store the message instead of a 16bit variable

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit to mlasch/wakaama that referenced this issue Sep 27, 2021
Use size_t to store the message instead of a 16bit variable

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit to mlasch/wakaama that referenced this issue Sep 28, 2021
Use size_t to store the message instead of a 16bit variable

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit to mlasch/wakaama that referenced this issue Sep 29, 2021
Use size_t to store the message instead of a 16bit variable

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit to mlasch/wakaama that referenced this issue Sep 29, 2021
Use size_t to store the message instead of a 16bit variable

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit to mlasch/wakaama that referenced this issue Oct 4, 2021
Use size_t to store the message instead of a 16bit variable

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit to mlasch/wakaama that referenced this issue Oct 4, 2021
Use size_t/ssize_t to store the message buffer sizes instead of
a uint16_t and int types.

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
@mlasch
Copy link
Contributor

mlasch commented Oct 4, 2021

PR #632 should fix this issue. @piotr276 feel free to have a look.

mlasch added a commit to mlasch/wakaama that referenced this issue Oct 4, 2021
Use size_t/ssize_t to store the message buffer sizes instead of
a uint16_t and int types.

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
mlasch added a commit that referenced this issue Oct 5, 2021
Use size_t/ssize_t to store the message buffer sizes instead of
a uint16_t and int types.

Signed-off-by: Marc Lasch <marc.lasch@husqvarnagroup.com>
@mlasch
Copy link
Contributor

mlasch commented Oct 12, 2021

@piotr276 I close this issue, as the fix was merged.

@mlasch mlasch closed this as completed Oct 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants