Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LowerTransportLayer: Acknowledgement timer expires too early, causing replies to get lost. #504

Open
FluffyBunniesTasteTheBest opened this issue May 9, 2022 · 0 comments

Comments

@FluffyBunniesTasteTheBest
Copy link

FluffyBunniesTasteTheBest commented May 9, 2022


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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant