The configuration client does not receive confirmation for a message with opcode 0x03

[Dmitro Balo]

Mesh SDK 5.0, SoftDevice S140 v7.2.0, NRF52840, SEGGER
------------------------------------------------------------------------------------
Hello! I have a similar problem. However, it manifests itself under other conditions. I have a node that has a configuration client and a configuration server at the same time, and it is convenient for me to use the configuration client to configure other models on the same device. All the functionality of the configuration client works well, I send messages to the server, the configuration happens and I get a status message back, but not a message about setting the publish address. I found out that the message with the 0x03 opcode is successfully received by the server, processed and it sends a response (send replay). But the access layer does not receive this status message and, accordingly, I receive a callback on the timeout event. Please help solve this problem! Thank you!

[Edvin]

Hello,

Is this something that I can replicate using your project? If so, would it be possible to send it (or a strip down project) so that I can look at what's going on?

Best regards,

Edvin

[Edvin]

I got your project. Can you please try to check the debug logging in access.h, and see whether you can see the message you are looking for there, and why it is not passed on to access_reliable_message_rx_cb()?

BR,
Edvin

[Dmitro Balo]

Hello, here's some more debug information. After sending a message with code 0x03, the server successfully:
- receives message 0x03
- handles it by setting the publish address
- successfully sends response CONFIG_OPCODE_MODEL_PUBLICATION_STATUS = 0x8019
I can confirm this because the send_publication_status function is executed and reaches:

send_reply(this_handle, p_incoming, CONFIG_OPCODE_MODEL_PUBLICATION_STATUS, (const uint8_t *) &response,
PACKET_LENGTH_WITH_ID(config_msg_publication_status_t, sig_model), nrf_mesh_unique_token_get());

However, my access level never receives this response, because this code never breaks:

I have turned on access level debug logging to DBG1 level and it confirms all of the above:

<t:     357752>, skif_uart_driver.c,  503, Set publication on target, in model#1 to handle: 2, and app_key_idx: 0
<t:     357809>, access.c,  260, RX: [aop: 0x0003]
<t:     357814>, access.c,  283, RX: Msg: 010002C0000004420101A06500
<t:     368255>, access.c,  432, TX: [aop: 0x0003] 
<t:     368260>, access.c,  433, TX: Msg: 03010002C0000004420101A06500
<t:     368309>, access.c,  260, RX: [aop: 0x0003]
<t:     368314>, access.c,  283, RX: Msg: 010002C0000004420101A06500
<t:     378741>, access.c,  432, TX: [aop: 0x0003] 
<t:     378746>, access.c,  433, TX: Msg: 03010002C0000004420101A06500
<t:     378794>, access.c,  260, RX: [aop: 0x0003]
<t:     378799>, access.c,  283, RX: Msg: 010002C0000004420101A06500
<t:     399712>, access.c,  432, TX: [aop: 0x0003] 
<t:     399717>, access.c,  433, TX: Msg: 03010002C0000004420101A06500
<t:     399766>, access.c,  260, RX: [aop: 0x0003]
<t:     399771>, access.c,  283, RX: Msg: 010002C0000004420101A06500
<t:     441655>, access.c,  432, TX: [aop: 0x0003] 
<t:     441660>, access.c,  433, TX: Msg: 03010002C0000004420101A06500
<t:     441708>, access.c,  260, RX: [aop: 0x0003]
<t:     441713>, access.c,  283, RX: Msg: 010002C0000004420101A06500
<t:     525541>, access.c,  432, TX: [aop: 0x0003] 
<t:     525546>, access.c,  433, TX: Msg: 03010002C0000004420101A06500
<t:     525594>, access.c,  260, RX: [aop: 0x0003]
<t:     525599>, access.c,  283, RX: Msg: 010002C0000004420101A06500
<t:     685433>, skif_uart_driver.c,  715, Generic config client ack timeout

[Dmitro Balo]

It looks like the 0x8019 response is not being sent and the problem is here (transport.c):

But I don't know how to solve it. 

[Edvin]

Hi,

Sorry for the late reply. I discussed this with our Mesh team, and it is actually a known limitation in the nRF5 SDK for mesh implementation. Please see bullet point number 2 here:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v5.0.0%2Fmd_RELEASE_NOTES.html&anchor=release_notes_500_limitations

So you should try moving the configuration client over to the next element (and keep the configuration server on the primary element).

Try that, and let me know if it doesn't work.

Best regards,

Edvin