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

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

Edvin — Fri, 28 Oct 2022 12:04:46 GMT

I understand. Well, unfortunately, this is a limitation in our nRF5 SDK Mesh stack, that tese needs to be on different elements. How you want to implement it is up to you (I wouldn't say that this is more "hardcoded" than setting both to 0, but perhaps I misunderstand.

I am sorry if that is an inconvenience, but this will most likely not be changed, as the nRF5 SDK is in maintenance mode. In the new nRF Connect SDK (NCS), this is no longer a limitation.

Best regards,

Edvin

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

Dmitro Balo — Thu, 27 Oct 2022 13:44:57 GMT

Hello,

I meant this (config_client.c):

and this (config_server.c):

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

Edvin — Wed, 26 Oct 2022 07:16:51 GMT

Hello,

Can you please explain what you mean by "indexes of elements during initialization of the client and server are set by hardcode"?

Best regards,

Edvin

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

Dmitro Balo — Mon, 24 Oct 2022 12:04:16 GMT

Thanks Edvin. I did everything as you advised and now everything works fine. However, I'm a little concerned that, despite the existence of such a problem, the indexes of elements during initialization of the client and server are set by hardcode.

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

Edvin — Wed, 19 Oct 2022 10:21:50 GMT

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

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

Dmitro Balo — Fri, 14 Oct 2022 11:52:31 GMT

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.

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

Dmitro Balo — Fri, 14 Oct 2022 10:56:41 GMT

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

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

Edvin — Thu, 13 Oct 2022 13:41:49 GMT

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

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

Edvin — Fri, 07 Oct 2022 12:01:21 GMT

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