Observation regarding GATT Bearer "Data OUT" Notifications Re-assembly logic and MTU negotiations

[Srikkanth]

Part 1:
A device that is exposing Mesh Provisioning Service[as a unprovisioned device] or the Mesh Proxy Service [as a provisioned device] could
under-utilize the negotiated ATT MTU and still transmit a valid mesh GATT Proxy PDUs to the peer Proxy Client.
The nRF mesh app on Android seems to rely on the negotiated ATT MTU to identify the number of chucks a segmented packet contains.
But, whereas, as stated above there can be scenarios where the device exposing the Mesh services under-utilize the ATT MTU. In that case, it will be
not possible for the current nRF Android app to Re-assemble the received packet correctly. Yes, this could very inefficient on the server implementation but the server is not in violation of the protocol by doing so.

PFA the Part1_Updated_MeshManagerApi.zip which contains the modifications that were made to MeshManagerApi.java for the above observation.

Part 2:
Also, the "ATT Exchange MTU" operation happens after the "Data Out CCCD" is being configured. This could lead to a situation where the Server sends some valid segmented data prior to the Exchange MTU procedure is initiated.
Typically, most of the available mesh solutions/apps establish the MTU negotiations before the "Data out CCCD" is configured.

PFA the Part2_Updated_BleMeshManager.zip which contains the modifications that were made to BleMeshManager.java for the above observation.
Either one could "Push" the Exchange MTU request to the "Dequeue" after the enable CCCD command or one could "add" all the commands to "Dequeue" instead of "push" with the original code sequence for the commands not modified.

Part1_Updated_MeshManagerApi.zip Part2_Updated_BleMeshManager.zip

[Roshan Rajaratnam]

Hi Srikkanth

This is really good observation just like thst has mentioned. I would really appreciate if you could send a pull request across to our dev branch. Although, I might not agree on completely on the Part 1, because now I can see more clearly where I can improve when reassembling gatt level segmentations as both your and my solution does not seem to care if the incoming message is a part of a gatt level segmented message before appending them and I only check while trying to remove the segmentation bits and this would be wrong if two invalid messages were appended together. I guess the most correct approach would be to check the pdu type even before appending everything in to one packet, to ensure that they are part of the same message as there could be parallel messages.

Thanks again for this

Roshan