Z-Stack for CC2530 Many-to-one Route and Source Route Questions

Hi,

Q1: I see something strange on the sniffer capture, how come the payload data transmitted from ZC

to ZR is not the same as the payload transmitted for ZR to ZED??

Q2: I don't know the answer yet. I'll do a little research and get back to you as soon as I have an answer.

Thanks for your concern. Since the NWK payload is security-enable, the auxiliary header should be different? I'm not sure about it.

Hi,

Can you try the same with security being disabled on ZC, ZR and ZED (disabling security during compilation)

Hi Igor, Thank you!

After I disabled security of all node, It turned out to be OK.

I notice that the NWK Source Rtg Subframe field is a little different.

zhou yong

Hi Igor,

I have another problem about security of Z-Stack for CC2530. Can you help me for that?

http://e2e.ti.com/support/low_power_rf/f/158/t/217433.aspx

zhou yong

Still waiting for help.

Hi,

I have very little experience with security in ZigBee and I don't want to mislead you

with my answer/s. Please wait for an answer from someone who knows and understands it.

I've seen a very similar problem. Quoting the Zigbee specifications directly:

3.6.3.3.2 Relaying a Source Routed Data Frame
Upon receipt of a source routed data frame from the MAC sub-layer as described
in sub-clause 3.6.3.3, if the relay index sub-field of the source route sub-frame has
a value of 0, the device shall check the destination address field of the NWK
header of the frame. If the destination address field of the NWK header of the
frame is equal in value to the nwkNetworkAddress attribute of the NIB, then the
frame shall be passed to the next higher layer using the NLDE-DATA.indication
primitive. If the destination address field is not equal to the nwkNetworkAddress
attribute of the NIB, and the receiving device is a ZigBee router or ZigBee
coordinator, the device shall relay the frame directly to the NWK header
destination using the MCPS-DATA.request primitive, otherwise the frame shall be
discarded silently.

If the relay index sub-field has a value other than 0, the device shall compare its
network address with the address found at the relay index in the relay list. If the
addresses do not match, the frame shall be discarded and no further action shall be
taken. Otherwise, the device shall decrement the relay index sub-field by 1, and
relay the frame to the address immediately prior to its own address in the relay list
sub-field.

So, it appears that in the first (broken) case, your end device sees a relay index of 0xFF, and then drops the packet according to the specification. Seems like when you disabled security, your end device sees a relay index of 0xFF, and accepts the packet.

It seems to me that the problem is in the router.  Can you confirm if your router is also running Z-stack?  If so, which version?  In my case, my router is running Ember stack; I haven't the time to build a z-stack router to test.

Hi Igor and Wong! Thank you!

Still waiting for help for the source route question.

In the first time, the router is running Ember stack and it's not my product so I can't turn the security off. My end device can't receive the message.

Then, Under Igor's suggestion, I use my own router running Z-stack and I turn the security off. My end device can receive the message.

But I need my end device to work along with the Ember router.

Oops, correction to my earlier post:

So, it appears that in the first (broken) case, your end device sees a relay index of 0xFF, and then drops the packet according to the specification. Seems like when you disabled security, your end device sees a relay index of 0xFF 0x00, and accepts the packet.

We could be more tolerant to these rogue packets by recognising that the specification does not prohibit us from checking for the Destination Address first (the 4 bytes immediately after the NWK header frame control), regardless of the value of the relayIndex.

if (NWK_destination_address == me)

  accept(); // don't care about relay_index

else

  apply_logic_depending_on(relay_index);

Alas, it seems that this is in the binary part of z-stack that we have no access to.  Any TI guys care to comment?

Fellows,

I have meet the exactly same issue. My end device is based on CC2530 and Z-Stack 2.5.1.a, but both ZC and ZR are based on Ember chip. It does not have any issue with only ZC and my end device. But once the end device rejoins the network through the Ember-based ZR, the command from the ZC to ZED is discarded in NWK layer of the ZED. I attached a picture for your reference. 

I do not know how did you guys handle this issue, it seems almost one year ago. I believe you have fixed it. Could you please share the solution with me? Thanks a lot!

Andy

At the time we discussed this directly with TI, their stand was that this was *not* a problem with ZStack, and that it was the other vendor's error in sending a bad packet. With that argument, it was reasonable to discard the packet. However, we sometimes have to take what we're given and try to work around other vendor's misbehaviour too. We eventually managed to convince TI to provide us with a custom version of ZStack 2.5.1 which contained a fix for this. Of course, we're not at liberty to share this, so you'll need to ask TI directly.

Voon,

thanks a lot for your reply, and I agree with you. We have to ask TI's help on it. Thank you very much!

Andy

Hi,

I am new to ZigBee cc2530 and zstack. I am facing with the end device that it cant receive any data /packet from either coordinator and router but it can send to router and coordinator. Don't know why 

Is the security is enable so that the end device can't receive anything? If yes , how and where can i disable it? Can anyone help me on this? Please 

Hi Teoh,

Would you specify which Z-Stack version you use?

Hi Teoh,

I don't think it is a security issue. If it were, why would you be able to have data being received by the other nodes, when sent by the ED.

What you describe is very strange as this is basic behavior so, as YK mentioned, please provide the version of stack you are using (I recommend using the latest) as well as the sample application you are exercising and whether or not you changed any of the default settings.

I would aslo recommend since this is a question that seems to be un-related to the original post, to open a new thread describing in greater details the symptoms as well the SW and HW platform you are using.

Thanks,

TheDarkSide