Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[leshan-dev] Leshan Server stops sending packets during firmware updates

Hi

Client : Wakamma client
Server : Leshan Server

We have been observing that Leshan server stops sending packets during a firmware upgrade process.

It happens in situations as below -

Example sinario:

server sends packet #20
server does not receive an ACK for packet #20
server again sends the same packet: packet #20
server receives and ACK packet #20
server sends next packet : packet #21
server receives second ACK for second packet #20
server stops sending packets entirely.

Meanwhile client for some reason has not received packet #21.


Below from Coap messages log:
------------------------------------------------------------------------------------------------------------------------------------
Time   Coap Mesg MID  Token Options
------------------------------------------------------------------------------------------------------------------------------------
14:53:41.009  CON-PUT 10021 1ebdc8 Uri-Path: 5, 0, 6 - Block1:  ? - Content-Format: 1544
14:53:41.199  ACK-2.04 10021 1ebdc8 Block1:  ?
14:53:41.199  CON-PUT 10022 1ebdc8 Uri-Path: 5, 0, 6 - Block1:  ? - Content-Format: 1544
14:53:41.388  ACK-2.04 10022 1ebdc8 Block1:  ?
14:53:41.388  CON-PUT 10023 1ebdc8 Uri-Path: 5, 0, 6 - Block1:   - Content-Format: 1544
14:53:43.577  CON-PUT 10023 1ebdc8 Uri-Path: 5, 0, 6 - Block1:   - Content-Format: 1544
14:53:43.613  ACK-2.04 10023 1ebdc8 Block1: 
14:53:43.613  CON-PUT 10024 1ebdc8 Uri-Path: 5, 0, 6 - Block1:   - Content-Format: 1544
14:53:43.743  ACK-2.04 10023 1ebdc8 Block1: 
Nothing after this. Server stop sending packets.


Console output:
Feb 24, 2016 10:53:43 PM org.eclipse.californium.core.network.Matcher receiveResponse
INFO: Duplicate response for open exchange: ACK-2.04   MID=10023, Token=1ebdc8, OptionSet={"Block1":"(szx=5/512, m=false, num=336)"}, no payload
Feb 24, 2016 10:53:43 PM org.eclipse.californium.core.network.Matcher receiveResponse
WARNING: Possible MID reuse before lifetime end: 1ebdc8 expected MID 10024 but received 10023


Currently we have circumvented this problem by ignoring duplicate packets and not sending ACKs for duplicate packets.

Is that the correct approach ?

Is this a bug in Californium ? What is the correct approach/solution for this problem ?

Thanks


Back to the top