CC2531: Z-Stack - Zigbee join problem with basic security.

Thomas Vanderlein

Part Number: CC2531
Other Parts Discussed in Thread: Z-STACK, Z-STACK-ARCHIVE

Hi!

I try to debug a connection problem we have sometimes.

A router looses the connection and do not come back for en hour/a day or more. I can see it keeps trying to join but it does not get the Transport key.

Router_P1 and Router_P2 have the coordinator as parent.

Router_C joined the net with Router_P1 as parent.

Everything is fine and working.

If Router_C has a short power fail it joins the network most of the time with Router_P1 as parent and everything works again. This is expected because Router_P1 is much closer to Router_C.

But sometimes Router_C gets no beacon from Router_P1 during joining but from Router_P2. Therefore it joins via Router_P2 instead.
I can see in TIs packet sniffer that:

Router_C gets an Association Response packet from Router_P2 and sends an ACK. Router_C is therefore en unauth child of Router_P2.
The Coordinator gets an Update Device packet from Router_P2 and sends an ACK.
The coordinator sends the Transport key to Router_P2 including a tunnel command with Router_C as end destination.
Router_P2 ACKs the Transport key packet.

So long is everything fine and works as expected.

Router_C is an unauth child of Router_P2 so I expect that Router_P2 sends the received Transport key directly to Router_C.

But this does not happen. Router_P2 sends the Transport key to Router_P1 instead. Router_P1 does not know what to do with the packet and discards it.
Router_C gets a timeout after 10 sec and restart the join procedure.

My questions:

The packet has right address information on the Zigbee-NWK layer (dest: 0xe9dd) but has wrong address information on the IEEE-MAC layer (dest: 0x7463). Why is this so?
Is this a known problem?
Why is Router_P2 sending the packet to Router_P1 instead?
Is the neighbor or routing table defect on Router_P2?
It seems the routing? decision is done in the OSAL. Is it possible to get debug from this layer?
How can I debug this further?

Coordinator 0x0000
Router_P1 0x7463
Router_P2 0x0ec2
Router_C 0xe9dd

Thanks in advance

Thomas

over 9 years ago

0 Jose Maria Alvarez over 9 years ago

Genius 3415 points

Hi Tomas,

Can you share an OTA capture of this behavior?

Regards,

0 Thomas Vanderlein over 9 years ago in reply to Jose Maria Alvarez

Prodigy 40 points

Hi Jose!

Unfortunatelly I did not get clearance for the OTA capture but I can share a Wireshark screendump of the packet (keys deleted). Does this help?

The first Source/Destination column pair is from the IEEE, the second pair from the Zigbee NWK. You can see that destinations differ in packet 881.

Thomas

0 Jose Maria Alvarez over 9 years ago in reply to Thomas Vanderlein

Genius 3415 points

Hi Tomas,

Now I have a few more questions:

Which version of the zstack are you running?
Are you using the NVM restore?
How is your mesh network topology?
What is the device 0x46F1 in the packet 879?

Regards,

0 Thomas Vanderlein over 9 years ago in reply to Jose Maria Alvarez

Prodigy 40 points

Hi!

I've got some answers.

Z-stack version:
ZigBee 2007 Release
Version 2.4.0-1.4.0
December 03, 2010

NVM restore: Yes we use that.

There are a couple more routers in the net. 0x46F1 is one of them. I simplified my description to make it easier because I don't think that the way the packet travels matters. It's only the last parent router which chooses wrong.

Your last question (mesh network topology) is unclear for us. What do you mean? Yes we use mesh, means all routers choose self the best way for a packet. Are there different types of mesh? I thought there is only one mesh.

Thanks for your time.

Thomas

0 YiKai Chen over 9 years ago in reply to Thomas Vanderlein

Guru 735695 points

Z-Stack 2.4.0 is obsolete and I suggest you to use latest Z-Stack to test again.

0 Jose Maria Alvarez over 9 years ago in reply to Thomas Vanderlein

Genius 3415 points

Hi,

Regarding to the mesh network question, to be more specific is about how the nodes are connected between each other just to see if i can reply the behavior that you have.

Regards,

0 Jose Maria Alvarez over 9 years ago in reply to Thomas Vanderlein

Genius 3415 points

Hi Thomas,

Is there any reason to not use the new zstack 3.0? There are a lot of updates made to the stack and solved issues.

Regards,

0 Thomas Vanderlein over 9 years ago in reply to Jose Maria Alvarez

Prodigy 40 points

Hi Jose,

yes there is a reason. The latest stack is to new. We have not finished to evaluate it yet. At the moment it is not working att all with our application.

It seems the described behaviour is no known bug so we have to do a workaround to fix the problem in the production line. I will retest the problem with the v3.0-stack as soon as possible but at first the v3.0-stack has to run att all.

Do someone know if there is a stack-version overview with changelogs? Which z-stack versions are released between 2.4 and 3.0?

The changelog in v3.0 seems to describe changes for v3.0 only.
TI's stack-archive at <ti.com/tool/z-stack-archive> has no information ether.

Thomas

0 YiKai Chen over 9 years ago in reply to Thomas Vanderlein

Guru 735695 points

There are Z-Stack 2.5.0, 2.5.1, 2.5.1a, Z-Stack Home 1.2.0, 1.2.1, 1.2.2, 1.2.2a and finally now Z-Stack 3.0. There are release notes in each version that describes bug fixing and change logs.

Zigbee & Thread

Zigbee & Thread forum

CC2531: Z-Stack - Zigbee join problem with basic security.