Home/Support/Support Forum/Why XBee ZB sends NWK Leave frame?
New and improved user forum site going live on 12/6 (All users will need to reset their password when the new forum is active)

Why XBee ZB sends NWK Leave frame?

0 votes
I have a ZigBee network based on XBee ZB SMT S2C with FW 0x4055 as coordinator. I am able to join 3rd party device successfully. I see that coordinator starts to send NWK Leave Frame to the end device just after joining (see frame below). Why?
[16:25:04.591511] Leave 61-88-80-F1-84-10-5E-00-00-09-10-10-5E-00-00-01-0E-C1-54-9B-40-00-A2-13-00-04-60-FF-FF Frame Information: (29 bytes) Packet Number: 3 Protocol: ZigBee Timestamp: 16:25:04.591511 Time Delta: 0.002352 Channel: 15 Length: 29 Link Quality: -46 dBm Source: USB8621 Layer: NWK Status: Normal MAC Header: (9 bytes) Frame Control: 0x8861 ···· ···· ···· ·001 = Frame Type: [0x1] Data ···· ···· ···· 0··· = Security Enabled: [0x0] No ···· ···· ···0 ···· = Frame Pending: [0x0] No ···· ···· ··1· ···· = Acknowledgement Request: [0x1] Yes ···· ···· ·1·· ···· = Intra-PAN: [0x1] Yes ···· ··00 0··· ···· = Reserved: 0x0 ···· 10·· ···· ···· = Destination Addr Mode: [0x2] 16-bit Short Address ··00 ···· ···· ···· = Reserved: 0x0 10·· ···· ···· ···· = Source Addr Mode: [0x2] 16-bit Short Address Sequence Number: 128 Destination PAN ID: 0x84F1 Destination Address: 0x5E10 Source Address: 0x0000 MAC Payload: (18 bytes) NWK Header: (16 bytes) Frame Control: 0x1009 ···· ···· ···· ··01 = Frame Type: [0x1] Command ···· ···· ··00 10·· = Protocol Version: 0x2 ···· ···· 00·· ···· = Route Discovery: [0x0] Suppressed ···· ···0 ···· ···· = Multicast Flag: [0x0] Unicast or Broadcast ···· ··0· ···· ···· = Security Enabled: [0x0] No ···· ·0·· ···· ···· = Source Route Included: [0x0] No ···· 0··· ···· ···· = Destination IEEE Address Included: [0x0] No ···1 ···· ···· ···· = Source IEEE Address Included: [0x1] Yes ··0· ···· ···· ···· = Device Initiator: [0x0] No 00·· ···· ···· ···· = Reserved: 0x0 Destination Address: 0x5E10 Source Address: 0x0000 Radius: 0x01 Sequence Number: 14 Source IEEE Address: 00:13:A2:00:40:9B:54:C1 NWK Payload: 0x6004 NWK Command ID: [0x04] Leave Leave Options: 0x60 ···0 0000 = Reserved: 0x0 ··1· ···· = Rejoin: [0x1] Yes ·1·· ···· = Request: [0x1] Yes 0··· ···· = Remove Children: [0x0] No MAC Footer: 0xFFFF Frame Check Sequence: 0xFFFF
asked Aug 12, 2015 in ZigBee PRO Featureset (and legacy ZNet 2.5) by pahanela New to the Community (30 points)

Please log in or register to answer this question.

1 Answer

+1 vote
Best answer
Perhaps the device is somehow sending inappropriate packets, or does not complete the join procedure correctly? It would be helpful to see a full trace of the join instead of just the leave packets.
answered Aug 26, 2015 by matthijs Community Contributor (78 points)
selected Oct 3, 2015 by pahanela
I have captured packets of joining process in Ubiqua. It is available by the link https://goo.gl/dAKzUO. Also screenshot is there. Should be noticed that I cannot also get address with ZDO Network Address Request. Device is using old Freescale MC13213 chip.
At the same time, in case of using 2 XBee devices everything is fine (no NWK links request, ZDO is working).
Tell me if you need some additional information.
Hm, I don't have Ubiqua, could you try saving in pcap format (Google suggests that should be supported).

From the screenshot, it seems that the coordinator sends a leave packet in  response to every data request from the device. I suspect this means that the device does not appear in the child table of the coordinator somehow. I wonder if the association was really unsuccesful, or if the device somehow didn't specify it is an end device when joining?
The reason was in incorrect SP (Cyclic Sleep Period) parameter. It was too small on coordinator, but it should be larger than polling period on end device. Consequently, association process was not finished correctly. So you was right in your suspicions.
Ah, so then the association process *did* finish correctly, but the coordinator threw the end device out of its child table again before it could send its first poll request.
Yes, more likely it is like that.