CC1352P: End device pairing issue through router

For some reason, attaching the files does not work. You can find the sniffer logs here:
https://1drv.ms/u/s!AuGD3z8N0GWFsq589zARbJjW8h51HA?e=2SbaxC

Hey Peter,

Thank you for providing the sniffer logs.  I can see that the ZC has permit join enabled and withholds a good link with 0x4583 at the time of the join failure.  There is a missing MAC Sequence number (83) from the ZC which very well could be the Tunnel: Transport Key in question, however I cannot be certain whether the sniffer/router missed this packet or it was never transferred over-the-air from the ZC due to an internal failure like CSMA/CA collision.  Either is unlikely but it is not possible to know more without further debugging the ZC directly.  It is also concerning that only one Link Status message, which should be sent every 15 seconds, comes from the ZC in a 35-second window. There is no exceptional difference between the working & dysfunctional join processes. Please have the customer further monitor their system for any other erratic behavior, if replicable then it will be easier to debug.

Regards,
Ryan

Hi Ryan,

I was now able to reproduce the issue in the office and I have noticed something interesting. Just as a reminder, the problem is that end devices joining through a router do not receive but a Remove in some cases.

This is the message of the coordinator opening the network with timeout 60 seconds at 14:35:33:

This is the beacon of the plug which will let the new device in (Association Permit: yes):

This is the beacon of our coordinator saying "no":

Exactly after 60 seconds the coordinator will close the network as if nothing happened:

We have reviewed the sniffer log several times and we cannot find any reason why the coordinator shall close the network before the timeout of 60 seconds and actually, looking at the last screenshot, the network appeared to be open all that time.

Any idea what is happening here? Our feeling is that this happens very often with 5x stack and we did not experience this issue with 4x versions. But that could also be due to always more customers using it.

Attached please find the debug log of the Linux server and the full sniffer log.

Regards
Peter

8132.zigbee.log

It won't let me add the file, so here is the link to the cubx:
https://1drv.ms/u/s!AuGD3z8N0GWFsrBUBHWWnojal1IeTg?e=UZvfbA

Have you logged the gateway ZdoMgmtPermitJoinReq command which is sent to the ZNP?  Can you debug the ZNP to determine how MT_ZdoMgmtPermitJoinRequest -> ZDP_MgmtPermitJoinReq -> ZDO_ProcessMgmtPermitJoinReq -> ZDSecMgrPermitJoining is processed?  It may be possible that the permit join request is broadcast across the network but not applied locally.

Regards,
Ryan

Hi Ryan, 

We can but we have to wait for the situation to comenback again. 

In the meantime, as I think you idea of the permit being broadcasted but not applied, did you ever faced such issue and if yes, what did you do?

Probably you will answer to look exactly at the code you told us to debug, but at least I wanted to try to speed up things. 

Have a nice evening

Peter 

Hi Shuyang.

This sounds very interesting, we will have a look!

Regards
Peter

Thanks for the feedback Shuyang!

Peter,

Please further monitor afDelete usage to make sure that endpoint zero is never removed by the application.

Regards,
Ryan

Hi Shuyang Zhong,

We have been looking for the code that we must eliminate to avoid this error, but we still cannot find it. Please, do you remember the code that had to be removed?

Thank you very much in advance

BR,

Randy

Hi Randy,

Did you start with afDelete(pEp->epDesc.endPoint) under the case type == SERVER_DISCONNECT in zstackpb.c?

Regards,
Ryan

Hi Ryan,

We already found this part that you comment. We added the condition to prevent Endpoint 0 from being removed. We have tested, and everything works fine so far. Hopefully it continues like this. Thank you very much for the help.

BR,

Randy