Android-nRF-Mesh-Library: Bug in parseMeshPduNotifications

Describe the bug parseMeshPduNotifications get stuck in loop if node is not in provisioner’s config: https://github.com/NordicSemiconductor/Android-nRF-Mesh-Library/blob/e03b1eba6cf4d7bb41b1fa36d3ce8055e8df4208/mesh/src/main/java/no/nordicsemi/android/mesh/transport/BaseMeshMessageHandler.java#L113

https://github.com/NordicSemiconductor/Android-nRF-Mesh-Library/blob/e03b1eba6cf4d7bb41b1fa36d3ce8055e8df4208/mesh/src/main/java/no/nordicsemi/android/mesh/transport/BaseMeshMessageHandler.java#L126-L129

I’m not sure exactly what is intended with the while loop logic, for what I can tell it might as well be replaced with while(true), and if the node is not found this will result in an endless loop.

To Reproduce Setup a mesh, Delete node X from mesh Connect to node X as Proxy (whom is not in config anymore) Configure it as Proxy

Device will get stuck in loop of parsing message.

Expected behavior Unsure of expected behavior, since node is not in config, it should probably not be returned but method should anyhow not get stuck.

Platform details:

Device: Pixel 5
OS: Android 12L
Library Version (or Commit) 3.1.6

Logs / Screenshots

12-16 14:17:51.427 24143 24253 V BaseMeshMessageHandler: TTL for received message: 13
12-16 14:17:51.427 24143 24253 V BaseMeshMessageHandler: TTL for received message: 63
12-16 14:17:51.427 24143 24253 V BaseMeshMessageHandler: TTL for received message: 46
12-16 14:17:51.427 24143 24253 V BaseMeshMessageHandler: TTL for received message: 6
12-16 14:17:51.427 24143 24253 V BaseMeshMessageHandler: TTL for received message: 125
12-16 14:17:51.427 24143 24253 V BaseMeshMessageHandler: TTL for received message: 43
... # About 40000 lines of same print
12-16 14:18:27.592 24330 24377 V BaseMeshMessageHandler: TTL for received message: 44
12-16 14:18:27.592 24330 24377 V BaseMeshMessageHandler: TTL for received message: 10
12-16 14:18:27.593 24330 24377 V BaseMeshMessageHandler: TTL for received message: 50
12-16 14:18:27.593 24330 24377 V BaseMeshMessageHandler: Sequence number of received access message: 3756400

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 21 (14 by maintainers)

Commits related to this issue

Fixes issue #461 where the while loop was not breaking even if the node was found or not. — committed to NordicSemiconductor/Android-nRF-Mesh-Library by roshanrajaratnam 3 years ago
Fixes issue #461 where the while loop was not breaking even if the node was found or not. — committed to NordicSemiconductor/Android-nRF-Mesh-Library by roshanrajaratnam 3 years ago

Most upvoted comments

Yes, I tested as mentioned before, this seems like it has resolved it. Not sure if you’ve added some comment if it fails to decode? Would it be possible to get a release out soon this and the other new fixes?

Rawa on Jan 26, 2022

thank you!

Itxupengfei on Dec 31, 2021

Just read through your commit and also tested it, this seems more correct, but I also think there should be a print if the node was not found because this mean you have a configuration that is not in sync.

Great that it works, I will look in to adding some kind of log.

An important caveat is that this message will not be processed fully by the library and fail silently. E.g in my case I try to setup a proxy filter (e.g set exclusion filter), I will not receive a message back after this message have been processed by the library. The MeshManagerApi would log V/MeshManagerApi: Received proxy configuration message: 0x025878B62D4F2A838ACBABD067B6A32286872A75DB65 but none of the MeshStatusCallbacks would be notified. The user of the library can only assume it failed after the 30 seconds timeout specified in the mesh profile specification.

As of now there is no way of notifying the user of any messages sent from an unknown node, but this can be done by simply notifying the user by adding a callback. I will look in to this.

I’m not sure what Mesh Profile states about these types of messages. The node itself is setup with the correct network keys/application keys it, and it would function correctly in a mesh, but it is not in the Provisioner Config so it should probably not been connected to in the first place since it was not disregarded correctly after removal from the provision config. But at the same time with the usecase of multiple provisioners modifiying the mesh, it might happen anyway?

As you may know, the correct approach to delete a node from the network is by sending the ConfigNodeReset. Upon receiving the status ConfigNodeReset, the node is deleted from the list of nodes and it’s address is added to the exclusion list. However simply deleting a node will not delete any of it’s network configuration. All it does is removing from the network i.e. list of nodes and adding it’s address to the exclusion list. The idea of adding this delete API is to allow the user to delete a node from the network that may have failed due to a hardware malfunction etc. Therefore you will always be able to connect to it if the node came back to life. There is nothing much we can do about it. There’s always a possibility of multiple provisioners modifying a network but that’s more like an application specific feature that a user has the freedom to define and implement.

roshanrajaratnam on Dec 20, 2021

lol not sure if it is a great achievement 😅 Have fun fixing this !

R0m4in-dooz on Dec 17, 2021

@Rawa @R0m4in-dooz you succeeded proving me wrong!

roshanrajaratnam on Dec 17, 2021

@R0m4in-dooz may be you should create a new issue?

roshanrajaratnam on Dec 17, 2021