Is it possible to get down block size for BLOCK1

[joakimeriksson]

I am testing some firmware upload code where i add a large hex-string to the leshan server's GUI and do a write (on the firmware object). But Leshan sends of with a block size of 512 and I would like to get it down to 256 or 128. Base on the RFC 7959 the recommended approach is to respond with a ENTITY TOO LARGE response code and set the SIZE1 option to the size i prefer. Is this implemented in Leshan? It just showed me a failure - "Unable to write resource /5/0/0 for abcde : 500 Invalid Response:Client [abcde] returned unexpected response code [4.13] for [WriteRequest...".

Is this a known issue or am I doing something wrong?

[boaks]

First at all:
Using a blockwise write request to /5/0/0 will show much more trouble, then using /5/0/1.

To your question:
The details of RFC7959 are not reflected in LWM2M 1.0.
So currently, this would not work "out of the box".

If to want to "patch", the mapping from LWM2M to CoAP is implemented in the module
"leshan-server-cf" and there in the class "CaliforniumLwM2mRequestSender.send's".
These methods are using a CoAP "Message Observer", which receives the CoAP Response in
buildResponse, there you can "catch the error code and adjust the "retry".

Though I only use /5/0/1, my "constrainded" client just provides its preferred blocksize using block2 in the request.

[sbernard31]

Leshan sends of with a block size of 512 and I would like to get it down to 256 or 128

You can configure the block size to use at startup but this will affect all resources and all devices.
See LeshanServerBuilder and NetworkConfig.
See PREFERRED_BLOCK_SIZE, MAX_MESSAGE_SIZE and MAX_RESOURCE_BODY_SIZE.

If you are using LeshanServerDemo you can use the californium.properties file to set that.

Base on the RFC 7959 the recommended approach is to respond with a ENTITY TOO LARGE response code and set the SIZE1 option to the size i prefer

Leshan uses the Californium "magical/transparent" block wise implementation. And this is not implemented. Maybe this should be added to californium.

About using coap blockwise to send firmware package, you should have look at this issue too : #367 (comment).

[sbernard31]

I open an issue on scandium : eclipse-californium/californium#395

[joakimeriksson]

Question: is there any possibility for Californium to handle different block1 sizes on different connections - e.g. can one lwm2m device signal a small block size for the BlockLayer handling while another have a larger block-size. My thinking is that devices could have attributes that tell the LWM2M server what sizes to use for block1 as it is too late to tell when a large block already arrived. (I know this kind of is a Californium question - but as this thread moved over there also I guess it is still also relevant here).

[boaks]

So, what are you trying?
Finding out, that block1 from a LWM2M server (fat endpoint to constrained endpoint) has a lot of issues? Sure! If you want to collect all the issues, feel free to spent your time in finding them out.

If you want to use LWM2M for firmware updates successfully, I recommend to use "/5/0/1" and block2 :-).

[sbernard31]

is there any possibility for Californium to handle different block1 sizes on different connections.

No possibility if you're using transparent block-wised.

can one lwm2m device signal a small block size for the BlockLayer handling while another have a larger block-size

This works well with block2, for block1 we should implement #395.

My thinking is that devices could have attributes that tell the LWM2M server what sizes to use for block1 as it is too late to tell when a large block already arrived.

AFAK, the only thing which looks like that in CoAP spec is what you described before ....

If you want working solution now, you should follow boaks' advice.
If you want to make work block1, propose a PR for californium because for now this is not the priority.

[jiangyoudi]

I am testing some firmware upload code where i add a large hex-string to the leshan server's GUI and do a write (on the firmware object). But Leshan sends of with a block size of 512 and I would like to get it down to 256 or 128. Base on the RFC 7959 the recommended approach is to respond with a ENTITY TOO LARGE response code and set the SIZE1 option to the size i prefer. Is this implemented in Leshan? It just showed me a failure - "Unable to write resource /5/0/0 for abcde : 500 Invalid Response:Client [abcde] returned unexpected response code [4.13] for [WriteRequest...".

Is this a known issue or am I doing something wrong?

would you give me a firmware upload demo use 5/0/0? I can not get good idea. always get respose "Unable to write resource /5/0/0 for 4IP53OBZ0GGOORI : 400 Invalid request:Unable to convert hexastring [] to byte array for resource /5/0/0"

[sbernard31]

@joakimeriksson, just in case you're still interested in this. I created a PR about this : eclipse-californium/californium#1357