Segmentation feedback of acknowledged msg is mostly failing when sent to non-proxy device
See original GitHub issueDescribe the bug As title states, when sending segmented acknowledged messages to non-proxy devices, it is too often failing to construct back the Status.
To Reproduce Steps to reproduce the behavior:
- Provision at least 2 nodes
- Connect to proxy
- Send either
CompositionDataGet,ConfigModelPublicationSet, or any msg that would result in segmented answer to the device that is not the proxy - Witness the library failing to construct the Status msg – it can totally fail or will pass it once a retransmission from the device is done
Expected behavior The library is able to construct the Status as soon as all feedback segments has been received (eg. SEG 0 == SEG N), and the non-proxy device should not have to retransmit at this point (?).
Platform details:
- Device: any
- OS: Android 9 and above
- Library Version: 3.1.5
- Mesh SDK: 4.0
- Chipset: nrf52840 xxAA
- MTU size: 66
Logs / Screenshots I spent some time to build enough material for you. I hope it will be enough to spot any bug, or give us hint on why this behavior.
-
CompositionDataGet: compositiondataget_OK.log compositiondataget_KO.log compositiondataget_KO_2.log -
ConfigModelPublicationSet: configmodelpublicationset_OK.log configmodelpublicationset_KO.log configmodelpublicationset_KO_2.log configmodelpublicationset_full_KO.log -
Custom
ApplicationMessageakaMagicLevelSet: custom_ApplicationMessage_OK.log custom_ApplicationMessage_KO.log custom_ApplicationMessage_KO_2.log custom_ApplicationMessage_full_KO.log
log files suffixed with OK --> expected behavior
log files suffixed with KO --> unexpected behavior: all segments received from device but no Status is being constructed. But we have it once the device is retransmitting some segments
log files suffixed with full_KO --> unexpected behavior: all segments received from device but no Status is being constructed. The device seems to have received every acknowledgements as it is not retransmitting
Unfortunately, this behavior is even more problematic in our commercial application as we have implemented a FIFO for such msg with auto-retry mechanism. Meaning this kind of msg is in a FIFO, when sending a cmd, we wait for feedback and retry every 2.5 sec (retried 2 times). The success rate is below 15% because of this problem and it makes the app unusable for a lot of our features. If we increase the retry timer to 5-6sec, the success rate raises to ~60%, but it is still not enough, and is not acceptable for our customers. We may force proxy connection to raise success rate to 95%, but it is not acceptable for most features that need these segmented feedbacks, and moreover it’s blocking the power of mesh n/w.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:38 (17 by maintainers)

Top Related StackOverflow Question
sent 👍
Hi, it was labelled awaiting user input long time ago before we got a response from you. I have been busy with some other projects. I will look in to yours 😉