MeshStatusCallbacks.onUnknownPduReceived() when sending multiple messages to the same node.

[FluffyBunniesTasteTheBest]

Describe the bug The app stores mesh messages in a queue. A background worker takes a message from the queue and sends it into the mesh - one message every 250 milliseconds. When sending multiple messages to the same node, MeshStatusCallbacks.onUnknownPduReceived() gets called quite frequently and hence the response of some messages get lost.

Question now is, is it valid to send multiple messages to the same node in rapid succession? I.e. without awaiting the previous messages's response?

If the app sends only a single message to a given node and awaits its response, MeshStatusCallbacks.onUnknownPduReceived() never triggers, but then the responsiveness of the app is really bad.

The messages sent are ConfigRelayGet, ConfigProxyGet and two vendor specific messages that both cause a segmented acknowledged response (one message replying 30 bytes, the other 100 bytes of data). What's interesting is that logcat shows quite some V/LowerTransportLayer: Acknowledgement timer expiring, making me wonder if this could be a follow up problem of the SAR expiration timer triggering prematurely.

Expected behavior Responses from the sent messages, which arrive at LowerTransportLayer, shouldn't get lost.

Platform details:

• Happens rarely on mesh networks with a handful of nodes, but reliably on mesh networks with 35 nodes.
• Device: Any Android Device
• OS: Any Android Version >= 7.0
• Library Version: 3.2.1
• Mesh SDK: 5.0
• Chipset: nrf52832
• Softdevice S132 7.3.0
• nRF5 SDK for Mesh 5.0.0

Edit: The way it looks, this could be related to Segmentation feedback of acknowledged msg is mostly failing when sent to non-proxy device

[roshanrajaratnam]

Hi, if the message is segmented or is acknowledged you should wait for the first message to be processed. A node can already be busy processing a message or if it was out of resources it might send a block acknowledgement value with 0x00000000.

Could you check if you get a block acknowledgement with 0?

[FluffyBunniesTasteTheBest]

Sure, will do, but will take till next week, as it's only reproducible at my clients test lab.

[roshanrajaratnam]

ok, for now I am working on adding provisioning using OOB Public Key.

[FluffyBunniesTasteTheBest]

@roshanrajaratnam Please excuse the delay, it's been a busy time...

There are a lot of BlockAcknowledgementMessage: Block ack value: 7f messages logged, but all of them showing values greater than zero.

Although the vendor messages reply a lot of data (up to 30 and 100 bytes), the firmware processes them as fast as possible (it just copies the data into a send buffer that's passed to access_model_reply()), making me wonder if, perhaps, the softdevice doesn't even send the acknowledge messages while it is busy sending out data from a previous message. Just a wild guess, but what do you think about it?

Btw., the firmware uses softdevice S132 7.3.0 with nrf5 sdk for mesh 5.0.0. Are there any known issues that could explain the onUnknownPduReceived() messages?

If somehow possible, I'd like to send out multiple messages before awaiting each previous message's reply, as this would significantly improve the app's performance.