CC2538: ZC(CC2538) has 12 ZED(CC2652),a new device join the ZC fail.

Can you provide sniffer log?

Hi YiKai Chen

Please check this.

zigbee log.zip

Thanks!

It's strange that IEEE address of association request and end device announcement from your ZED is ff:ff:ff:ff:ff:ff:f1:22. Can you test anther ZED to see if it can join this network?

Hi YiKai Chen

Ok,I had change it with uniflash4.4.0.

And try one again with another devcie,had a same confirm key unknown status.zigbee log1.7z

Thanks!

I see your coordinator and end device do ZCL report attribute to each other right after association and this seems your own modification on application. Can you try to join a ZED running original Z-Stack example and see if it works first?

Hi YiKai Chen

Ok,Base on this post environment,I had update a ZED[CC2652] with a original source code, had a same result.

zigbee log3.7z

Thanks!

Ryan Brown1 and Toby Pan Do you know why coordinator replies "Confirm Key, Unknown Status"?

Hi,

Are you using Z-Stack 3.0.2?

This issue is probably on the ZC.
Do you see this issue when you use a default ZC example on CC2538 (e.g. SampleLight, etc) ?

This status, 0xB3, is probably related to ZApsIllegalRequest.
Can you debug your ZC and see if this is the case? Specifically, please check if you see ((ZDO_VerifyKeyInd_t*)msgPtr)->status == ZApsIllegalRequest ?

Regards,
Toby

Hi  Toby Pan

yes,ZC chip is CC2538 ,use zstack3.0.2!

I use a GenericApp project,I had not found about souce code about what you said. 

I heard zstack update zstack3.6, CC2652 chip update SDK3.4?

The CC2538 can run the zstack3.6?

No, CC2538 cannot use z-stack in SDK 3.40.

Hi Toby Pan 

and I had not found this case ZApsIllegalRequest also in the ZC example on CC2538(SampleLight project).

Thanks!

Dear Toby,

We found the source code about key verify as below, and we don't change any code about this. Why does ZC response the verify key request is illegal?

How can we resolve the issue?

case ZDO_VERIFY_KEY_IND:
#if (ZG_BUILD_COORDINATOR_TYPE)
if(ZG_DEVICE_COORDINATOR_TYPE)
{
if( ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus == ZSuccess)
{
bdb_TCjoiningDeviceComplete( ((ZDO_VerifyKeyInd_t*)msgPtr)->extAddr );
}
}

ZDSecMgrVerifyKeyInd( (ZDO_VerifyKeyInd_t*)msgPtr );
#endif

Thank you 

Jiabo

Hi Yikai Chen

zstack3.6 can use in CC2538?

Thanks!

What's is zstack3.6? Only Z-Stack 3.0.x and Z-Stack Home 1.2.x can run on cc2538

Hi YiKai Chen

SDK3.4 had this issue?

Thanks!

What issue are you asking?

Hi YiKai Chen

this:confirm key unknown status.

Thanks!

I think Toby means to ask you to check the following code in ZDApp_ProcessSecMsg on CC2538.

    case ZDO_VERIFY_KEY_IND:
#if (ZG_BUILD_COORDINATOR_TYPE)
      if(ZG_DEVICE_COORDINATOR_TYPE)
      {
        if( ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus == ZSuccess)
        {
          bdb_TCjoiningDeviceComplete( ((ZDO_VerifyKeyInd_t*)msgPtr)->extAddr );
        }
      }
  
      ZDSecMgrVerifyKeyInd( (ZDO_VerifyKeyInd_t*)msgPtr );
#endif
      break;

You can set a breakpoint on the line "if( ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus == ZSuccess)" and check the value of ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus to see if it is ZApsIllegalRequest(0xb3).

Yes, YK is correct, please debug in that area of the code.

Also, can you try using a default ZC example? There should be no issue joining 13 devices in the default example.

Hi Toby Pan

OK,I will try it.

Thanks!

Hi YiKai Chen

Yes,I will consider  to debug it, last time I had a product capture packet.

Thanks!

Hi Toby Pan and YiKai Chen

If it is 0xb3 in that area of the code,what can I solve this issue?

Thanks!

I have no idea why you see such 0xb3 status code. Maybe wait Toby Pan to give his opinion.

First, I'd like to confirm that a default, unmodified, out-of-box ZC example produces this behavior.

This behavior really shouldn't happen. The fact that the Confirm Key is not APS encrypted is a sign that there was an error during the TCLK exchange process.

Then we can go over what possible modifications you've made on the ZC that could cause this behavior.

Another question:

When you see this behavior on your CC2538, can you check to see what the value of zgDeviceLogicalType is ?

I understand that you intend it to be a coordinator, but since this value is restored from NV (it is in zgItemTable) on a reset, it could've been corrupted if NV is not configured correctly. If that happens, then this unknown value in the Confirm Key message may occur.

Hi Toby Pan

OK, I will check it!

Thanks!

Hi Toby Pan

this confirm key unknown issue about this?

https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/847867/3135496?tisearch=e2e-sitesearch&keymatch=coordinator%252520confirm%252520key%25252C%252520status%252520known#3135496

Thanks!

Is it possible that this is related to bad RF performance as we discussed in e2e.ti.com/.../3303196

Hi YiKai Chen

this is another issue,right?it it not what we disscuss that discussed in e2e.ti.com/.../3303196

Thanks!

I mean this issue might be related to bad RF performance of your CC2538 and CC2652 custom board so you should check your RF performance first.

Hi Toby Pan

If I want to debug this issue, 12 ZED devices must be run at the same time on the power.

Or just ZC can add 12 ZED devices or even more ZED devices,unnecessary run at the same time on the power?

Thanks!

Hi Toby Pan and YiKai Chen

I had a breakpoint on ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus and watch the value of the zgDeviceLogicalType.and the wireshark log

it seem that success,but from the log I had not saw the confirm key status,but the breakpoint is run  on it,and the value is zero.

test unknown status.rar

Thanks!

\

Hi Toby Pan

yesterday I had let a ZC(CC2538) modify on the source code,and run on the 11 channel. 

let the ZED(CC2652) join the ZC join successfully uart printf the ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus

total add 15 ZED devices had no 0xb3(confrim key unknown status).

But on the channel(2405MHZ),had another kind device so  it had error packet?

case ZDO_VERIFY_KEY_IND:
#if (ZG_BUILD_COORDINATOR_TYPE)
if(ZG_DEVICE_COORDINATOR_TYPE)
{
if( ((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus == ZSuccess)
{
HalUARTWrite(HAL_UART_PORT_0, &((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus, 1);
bdb_TCjoiningDeviceComplete( ((ZDO_VerifyKeyInd_t*)msgPtr)->extAddr );
}
else
{
HalUARTWrite(HAL_UART_PORT_0, &((ZDO_VerifyKeyInd_t*)msgPtr)->verifyKeyStatus, 1);
}
}

ZDSecMgrVerifyKeyInd( (ZDO_VerifyKeyInd_t*)msgPtr );
#endif

Thanks!

verifyKeyStatus returning 0 means ZSuccess. If you remove the breakpoint and free run coordinator, can your device join coordinator successfully?

Hi YiKai Chen

yes,But Previous phenomenon had appeared 0xb3. Now had not appeared it.

Thanks!

So, does your device join successfully?

Hi YiKai Chen

yes, but the previous phenomenon also had a potential risks.

it seem that it is difficult to find and solve it.

By the way,that source code I had not modify it. 

Thanks!

Do you mean that you don't change anything but the issue just disappear?

Hi YiKai Chen

yes,it seem that  it is.

So I want to let it appear again ,what can I try to it?

Thanks!

I don't see similar issue when I test this so I cannot recommend how to reproduce your issue.

Hi YiKai Chen

OK,Now I also had no any idea to reproduce it.

Thanks!

Have you ever found anything wrong on RF performance of your coordinator and device? If you had tried to fix what I suspected in RF performance, is it possible that it also fixes this issue?

Hi YiKai Chen

Now debugging.Had no progress so far.

Thanks!