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