on_provisioning_reply doesnt get invoked in coap client

[kaushalyasat]

Hi,

I have a coap server/client system and when I send a provisioning request from the client I can see the server is sending the reply. But my 'on_provisioning_reply ()' callback doesn't get invoked. I can see the provisioning reply from the server via wireshark as well. 

My provisioning reply payload is slightly modified. I have included server's rloc and ext address on top of the servers IPV6. Before this modification, it was working. But this shouldn't be a reason not to receive a packet I guess. 

When I debug into coap.c, I can see the 'coap_reply_init ()' function getting invoked, but I dont see 'coap_reply ()' getting invoked.

During the provisioning phase, I reduce the poll period to 100ms. 

What could be wrong?

Cheers,

Kaushalya

[Marte Myrvold]

Hi Kaushalya,

My provisioning reply payload is slightly modified. I have included server's rloc and ext address on top of the servers IPV6. Before this modification, it was working

How did you add the RLOC16 and extended address to the provisioning reply?

Have you made any other changes to the samples?

Best regards,
Marte

[kaushalyasat]

Hi Marte,

Marte Myrvold said:

How did you add the RLOC16 and extended address to the provisioning reply?

	static otError provisioning_response_send(otMessage *request_message, const otMessageInfo *message_info)
	.
	.
	struct paireReplyStruct {		// Feature 13
		otIp6Address meshlocal;
		uint16_t rloc;
		otExtAddress extaddr;
	} pairReply;
	.
	.
	payload = &pairReply;
	payload_size = sizeof(pairReply);
	
	memcpy (&pairReply.meshlocal, otThreadGetMeshLocalEid(srv_context.ot), sizeof(otIp6Address));
	pairReply.rloc = otThreadGetRloc16(srv_context.ot);
	memcpy (&pairReply.extaddr, otLinkGetExtendedAddress(srv_context.ot), sizeof (otExtAddress));
	
	error = otMessageAppend(response, payload, payload_size);
	.
	.
}

I can see this working in the log hex dump of the host. So I think this is ok.

Marte Myrvold said:

Have you made any other changes to the samples?

There are lot of other changes, but I cant think any of them will influence the provisioning process.

Cheers,

Kaushalya

[Marte Myrvold]

Hi Kaushalya,

Can you upload the wireshark logs as pcap files?

kaushalyasat said:

In the instance the SED is connected to a different router than its the router it is trying to provision. (SED rloc 0x9423, the router being provisioned rloc is 0xb000)

When I check the 0x9400 router from TTM, it is grayed out and cant see any child connected to that, but from wireshark I can see other SEDs connected to it. Could it be that 0x9400 has gone to some error state? Also TTM shows 'Error - polling not possible due to incorrect state.' in the log. It doesnt show an ext address as well.

Based on this and your other ticket ( An OpenThread router shown as grayed out in TTM ) it seems likely that the issue is with the SED's parent that is grayed out. Did connecting the cable (from your other ticket) fix this issue as well? That is, did the SED receive the pairing packet after router 0x9400 had recovered? Or are you still seeing this issue?

Best regards,
Marte

[kaushalyasat]

Hi Marte,

Well, sadly I cant confirm, connecting the console connector actually fixed whatever issue in that parent router. Only thing I saw was after I connected and disconnected the console cable, the pairing packet was received and TTM shows the parent router as not grayed. The console cable has only three wires for a debug UART on the nrf52840. I connected the console cable to a laptop which was powered from its battery, so the GND connection shouldn't have influenced the parent routers GND.

Now everything is back in good shape, but I think its just a matter of time this pops back. Unfortunately we still couldn't figure out how to reproduce this error. We are using quite an old SDK, 1.2.3. Do you think this SDK could have any bugs that could lead to routers going to this state? 

Cheers,

Kaushalya

[Marte Myrvold]

Hi Kaushalya,

Then, it seems that the main issue is not related to on_provisioning_reply() but that the parent router goes offline.

kaushalyasat said:

We are using quite an old SDK, 1.2.3. Do you think this SDK could have any bugs that could lead to routers going to this state? 

Are you certain of the version? The nRF Connect SDK does not have version 1.2.3. Version 1.2 only has patch versions 1.2.0 and 1.2.1.
However, I would recommend moving to a newer version, as there is a good chance this could be a bug that has been fixed.

Best regards,
Marte

[kaushalyasat]

Hi Marte,

My bad, the SDK we were using is 2.3.0.

I am trying 2.6.0 now.

Cheers,

Kaushalya

[Marte Myrvold]

Hi Kaushalya,

I could not find any known issues that could be related to this in v2.3.0, but there could still be fixes and improvements since then. Please let me know if you are able to reproduce the issue with v2.6.0.

Best regards,
Marte