You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Approximately once every 20 to 40 sent VendorModelMessageAcked messages, it happens that the reply gets lost. If it happens the following messages are logged:
2022-05-09 15:10:37.010 V/MeshManagerApi: MeshNetwork pdu sent: 0x00146F2C580B54DB6D474B68356D290C6EA26CF26564
2022-05-09 15:10:37.151 V/LowerTransportLayer: Acknowledgement timer expiring
Followed by (once for each reply segment):
2022-05-09 15:10:37.494 V/LowerTransportLayer: Ignoring message since the incomplete timer has expired and all messages have been received
If the message gets through, the following is logged instead:
2022-05-09 15:10:14.244 V/MeshManagerApi: MeshNetwork pdu sent: 0x00143181A692977E91F978E6CC206AC3E753825A02A4
2022-05-09 15:10:14.724 V/MeshManagerApi: Received network pdu: 0x001484639FFB5810D3DA434CAB36EF50CF1B61A5D161E48265C3F8EBCCDF
Followed by (once for each reply segment):
2022-05-09 15:10:14.725 V/LowerTransportLayer: Starting incomplete timer for src: 000C
What's interesting is, that in the error case, the acknowledgement timer expired already 141 milliseconds after the pdu was sent. Whereas in the OK case, the reply is received 480 milliseconds after the message was sent, making it look as if the timer expired too early.
Another interesting detail is that it never happens on the connected proxy node, but quite frequently on any other nodes, making me believe that it could be related to those two cases:
To Reproduce
The test case that triggered it uses a mesh network with five nodes. It sends a VendorModelMessageAcked message with 100 bytes of data to a node and expects a reply in five seconds. If the reply is received, it waits for 250 milliseconds before continuing with the next node. If the reply does not get through, an error is logged. The loop is running endlessly.
Expected behavior
The acknowledgement timer shouldn't fire too quickly, so the library doesn't discard any received data.
Platform details:
Device: Any
OS: Any Android
Library Version: Android-nRF-Mesh-Library 3.2.1 and Android-BLE-Library 2.4.0
The text was updated successfully, but these errors were encountered:
Describe the bug
Approximately once every 20 to 40 sent
VendorModelMessageAcked
messages, it happens that the reply gets lost. If it happens the following messages are logged:If the message gets through, the following is logged instead:
What's interesting is, that in the error case, the acknowledgement timer expired already 141 milliseconds after the pdu was sent. Whereas in the OK case, the reply is received 480 milliseconds after the message was sent, making it look as if the timer expired too early.
Another interesting detail is that it never happens on the connected proxy node, but quite frequently on any other nodes, making me believe that it could be related to those two cases:
To Reproduce
The test case that triggered it uses a mesh network with five nodes. It sends a
VendorModelMessageAcked
message with 100 bytes of data to a node and expects a reply in five seconds. If the reply is received, it waits for 250 milliseconds before continuing with the next node. If the reply does not get through, an error is logged. The loop is running endlessly.Expected behavior
The acknowledgement timer shouldn't fire too quickly, so the library doesn't discard any received data.
Platform details:
The text was updated successfully, but these errors were encountered: