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

[kaushalyasat]

One other observation I found today is, unfortunately, this works some times!!! Now this is even worst. I haven't done anything to the code from yesterday to today. How can we explain this?

[Marte Myrvold]

Hi,

Do you see any difference when it works and when it does not? Are the steps different, or are there any differences in packets being sent, etc.?

Best regards,
Marte

[kaushalyasat]

Hi Marte,

Only difference I see is the client's provision reply call back doesnt seem to execute. I can see from wireshark that the provision reply is actually send from the host. No changes to code whatsoever. 

But strange as may be, I can't recreate this condition any more, meaning it is working now. I dont like these self healing problems. 

I will keep you posted if I can see this issue again. For the time being I guess I have to park this.

Thanks for your help.

[kaushalyasat]

Hi Marie,

Today also it occurred. I can assure your the code has not changed between provisioning working and not working instances.

Based on wireshark logs and console messages, the connection of the SED to the final destination is as follows.

SED (0x9423) <-> parent router (0x9400)  <->.... <->0xb000 (destination router)

From 0xb000 router, I can see its sending the pairing packet. But on wireshark I see only this. (packet 34078/83/98). 

I can see the following when it works. In this instance the detination router (0xb000) is directly connected to the provisioning SED (0xb001).

But when its not working (the SED doesnt receive provisioning reply) I see only retransmission as follows.

I can see in the retransmission packet, there are no data.

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.

Can you get any clue from this?

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