Does Californium PR 2088 harm Leshan?

[boaks]

Question

Please read the comment by SeppoTakalo.

This explains, that using different token for an blockwise transfer seems to break some function in leshan.
I'm not sure, about that, but maybe someone checks the leshan implementation. If that breaks leshan, as short term solution please adjust the application specific default value for COAP.BLOCKWISE_REUSE_TOKEN to true.

In my understanding of CoAP RFC7252, the freedom of the client to choose the token implies, that the server doesn't make assumptions about the token and the server must not bind state to it (the second part is my interpretation).

If leshan requires to bind server-side state to the token, I would appreciate, if that could be discussed in the IETF core mail list or the IETF Constrained Application Protocol (CoAP): Corrections and Clarifications.

[sbernard31]

Until now, nobody report issue about it.

If I'm not wrong this was added in Californium 3.8 ?

Leshan depends to Californium 3.8 only since v2.0.0-M11) which is pretty recent and so maybe not so used.

@JaroslawLegierski do you know if you face issue about that with Leshan 2.0.0-M11 or 2.0.0-M12 ? Maybe you are using COAP.BLOCKWISE_REUSE_TOKEN =true ?

About blockwise we are just using transparent blockwise transfer, so I'm not sure what could be specific to Leshan. My first guess if there is a problem this is not limited to LWM2M use case.

[boaks]

Until now, nobody report issue about it.

That's good the read.

About blockwise we are just using transparent blockwise transfer, so I'm not sure what could be specific to Leshan.

No, the Californium transparent blockwise transfer doesn't use the token to related the transfer's requests.
Let's see, what other reports.

[jvermillard]

It breaks some lwm2m clients (for sure, the Zephyr one)

[boaks]

It breaks some lwm2m clients (for sure, the Zephyr one)

Hm, but that should be only the case, when Californium is the CoAP client and initiates the blockwise transfer.
Because, if zephyr is the client, zephyr is free to choose the token.
Californium itself doesn't use the token to relate server side state to it. At least I'm not aware.

[jvermillard]

"lwm2m clients" not "coap clients"

Exactly, when the LWM2M server pushes a large content to the LWM2M client (POST or PUT), the LWM2M server acts as a CoAP client.

I think the Zephyr client uses the token as a way to reassemble all the packets in a "single" transaction, and if you don't do so, how you can be sure you are assembling blocks of the same transaction?
LWM2M doesn't use Etag or anything alike (to discuss this with OMA https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues

[boaks]

I think the Zephyr client uses the token as a way to reassemble all the packets in a "single" transaction, and if you don't do so, how you can be sure you are assembling blocks of the same transaction?

Let's forward that question to IETF Constrained Application Protocol (CoAP): Corrections and Clarifications. And see, what we get as answer.

[boaks]

how you can be sure you are assembling blocks of the same transaction?

AFAIK, on the coap-client side, that's defined by the etag in the response.
And on the coap-server side, there is only one ongoing transaction.

[sbernard31]

LWM2M doesn't use Etag

At least, I didn't find any reference to Etag in LWM2M v1.0.2, v1.1.1 and v1.2.1

[boaks]

If LwM2M refers to RFC7252 and RFC7959,it refers to the etag.

[boaks]

Anyway, details about RFC 7252, 7641, 7959 are in my opinion best discussed at the IETF/CORE.

[sbernard31]

I just wanted to say that LWM2M says nothing about using etag or not using it.

If etag is needed for some COAP blockwise, FETCH or observe, this is more RFC/IETF concerns. (Not specific to LWM2M)

[JaroslawLegierski]

@JaroslawLegierski do you know if you face issue about that with Leshan 2.0.0-M11 or 2.0.0-M12 ? Maybe you are using COAP.BLOCKWISE_REUSE_TOKEN =true ?

We are using the default implementation with COAP.BLOCKWISE_REUSE_TOKEN=false however we haven't encountered any specific issue till now.

[boaks]

Thanks a lot.
It' still unclear, why the zephyr lwm2m client fails and how to fix it.

[boaks]

AFAIK, the zephyr client has addressed that issue.
Though no other incompatibility issue was reported, I guess, this can be closed.
Any opinion?

[sbernard31]

I guess we can close it too.

Thx for let us know.