Leshan sever sending ClientSleepException exactly after 93 seconds of Registration.

[madhushreegc]

Leshan versio - leshan-1.0.0-M10

Leshan server is not resetting the state of client after receiving a response from device for a downlink message for a queue mode device.

Even though the LWM2M client is not sleeping , Leshan is throwing ClientSleepingException .

setAwake is called only for Update/register request.

Procedure to reproduce issue.

1. Register a device with binding mode as UQ.
2. send downlink after 60 seconds and received ack(This should reset the timer of sleeping device)
3. Send downlink again after 60 seconds(client not sleeping ) . Request does not reach device . ClientSleepingException is thrown.

[sbernard31]

send downlink after 60 seconds and received ack(This should reset the timer of sleeping device)

You mean you are using separated response, right ?
You acknowledge the request but never send the response (in your step to reproduce) ?

If I'm right, currently it's the expected behavior (I mean this is why we try to code), we are waiting for a response (piggyback or separated).
Reading the specification (§2.1 Queue Mode Operation), I think we respect it :

In order to find out whether a message was successfully delivered from
the LwM2M server to the LwM2M client the LwM2M server has to rely on a response. 
This response tells the server that the message has been received and processed
(regardless of what the result of the processing was). 
A response can be conveyed to the server in two ways:
- ACK piggybacking the response, or
- Separate CON/non-CON containing the response.

and

Due to the congestion control approach used by CoAP the LwM2M Server has to wait 
for a response to a request before sending out the next request from
 the queue since [CoAP] limits the number of simultaneous outstanding interactions to 1.

Anyway, even If (I think) we respect the specification, I agree that it could make sense to reinitialize the counter on ACK, but unfortunately this is not so easy because of the current code organization...

So, before to consider a massive code changes, I would like to understand to which kind of real usecase this is about ?
I mean

• why using 60s before to send the first request ?
• why sending a second request before to receive the first response (I mean if you wait for the first response client will be considered as awake again).

[madhushreegc]

Yes, this issue is with real device and receiving the piggybacked response for every down link(Write request) . Application is sending a downlink request for every 60s and receiving the response from device . Even after receiving piggybacked response the awake timer of client is not getting refreshed .

[sbernard31]

Ok so if this is a piggybacked response this looks like a bug. I will look at this deeper.

[sbernard31]

I created a PR which should fix this : #714

Could you check if this works for you ?

[madhushreegc]

Sure . I will check and let you know.

[madhushreegc]

I checked . Its working . Thank you for the fix.

I found one more issue . Leshan is considering 93 seconds as default sleeping time . This should be from MAX_TRANSMIT_WAIT=247500 from Californium.properties right?

[sbernard31]

You want synchronized the Leshan wait time with the californium.properties value ?

I will look at this.

[sbernard31]

@madhushreegc could you review/test if #716 sounds OK for you ?
(you can comment direct in the PR)

This should be from MAX_TRANSMIT_WAIT=247500 from Californium.properties right?

It seems the default value in californium is 93s too as defined in the RFC7252.

[sbernard31]

#716 is now integrated in master.