Rejoining Network - Association request, no response

Hi e2e community, 

I have now upgraded to Zstack 2.6.3a, but am still having the same unexpected result with end devices try to join a new network or join a network they were once associated with.  With upgrading totZstack 2.6.3a, I can see that some of the Zigbee communications quirks have been fixed, but not all. The communications behaviour has changed slightly around an Association request., but the end result is sill the same. No association is established.  I get the feeling that the use case of  end device roaming between networks has not been fully tested.  

For example I have found in Zstack 2.6.3a and ZStack 2.50 after calling
zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE);
ZDOInitDevice( 0 );
I must also reset the "ZDO_UseExtendedPANID" before a new network beacon will pass the  "ZDApp_NwkDescListProcessing()" criteria and issue an Association request issued. 

Test Network setup;
2 x Coordinator (different channels, different PanId's ), capacity set to true.
1x End device
ZStack 2.6.3a
MANAGED_SCAN
DSECURE=1
TC_LINKKEY_JOIN with pre-configured keys

Communication Behaviour;
Association fails
EndDevice issues: Association request
Coordinator: Ack (no data pending)
EndDevice issues:Data request (MAC SrcAddr Short address)
Coordinator: Ack (Data pending)
Coordinator issues: Data (Empty Payload)
EndDevice: Ack (No data pending)

Association Sucessful
EndDevice issues: Association request
Coordinator: Ack (no data pending)
EndDevice issues:Data request (MAC SrcAddr Mac Address)
Coordinator: Ack (Data pending)
Coordinator issues: Association Reponce 
EndDevice: Ack (No data pending)

From the above transcript; It appears that the issues is the End Device issuing a data request using an old short address. Instead of it MAC address as the device in not associated with the new network yet.

Any idea's on how to solve this issues?

I still use Daintree SNA 2.3.
Are you able to read these files?

So far I have found that the follwoing code snipit in "ZDApp_ProcessNetworkJoin()"is never called as an End Device.

if ( (NLME_GetShortAddr() != INVALID_NODE_ADDR) ||
(_NIB.nwkDevAddress != INVALID_NODE_ADDR) )
{
uint16 addr = INVALID_NODE_ADDR;
// Invalidate nwk addr so end device does not use in its data reqs.
_NIB.nwkDevAddress = INVALID_NODE_ADDR;
ZMacSetReq( ZMacShortAddress, (uint8 *)&addr );
}

I find that, if I set ZMacShortAddress to INVALID_NODE_ADDR when I call" ZDOInitDevice( )"  resolves the issue of the End device requesting data  with an invalid short address, after issuing an Association request. As first glance this seems to solve the problem of and the End device associates with the new network cordinator.

if ( networkStateNV == ZDO_INITDEV_NEW_NETWORK_STATE )
{
       ZDAppDetermineDeviceType();
      if(devStartMode == MODE_JOIN) {

            // Initialize default ZDO_UseExtendedPANID to the APS one. - iMonitor 
           osal_cpyExtAddr( ZDO_UseExtendedPANID, AIB_apsUseExtendedPANID );

            // Invalidate nwk addr so end device does not use in its data reqs.
            uint16 addr = INVALID_NODE_ADDR;
            _NIB.nwkDevAddress = INVALID_NODE_ADDR;
            ZMacSetReq( ZMacShortAddress, (uint8 *)&addr );

}

Code snipit:

A sniffer is required to proceed with the analysis.

Ubiqua () supports Daintree files so please download the tool and convert it to Ubiqua file (*.cubx)

Please also describe the steps to reproduce the problem, as it is not very clear the sequence of operations.

Anyways, for the device to join another network the NV area must be completely erased and the device factory reset. Did you do this? If so please describe how

I would also recommend try and do the same test by erasing the NV pages first (you can do it with SmartRFFlash Programmer).

One thing I would like to add is that PANID is not the unique identifier of the network, but it is the extended PANID. So if you have two coordinators with two different PANIDs, but same extendedPANID, the joining device will not behave correctly. 

Thanks,

TheDarkSide

Thanks for following this up.

I think you need to re-read my description or email with TI support.   
I want the devices to automatically hop networks, without user or engineer manipulation.

All the devices have been programmed fresh before testing. Easing and reprograming to get devices to change networks is not an option.
What do you mean or referring  to when saying "and the device factory reset" can i do this in code. Is there an API call for this.

[Steps Needed to Recreate Problem:]

Test Network setup;
2 x Coordinator (different channels, different Pan Id's ), capacity set to true.
1x End device
ZStack 2.6.3a
MANAGED_SCAN
DSECURE=1
TC_LINKKEY_JOIN with pre-configured keys

Test procedure;

I am using the ZDApp_StartJoiningCycle() and ZDApp_StopJoiningCycle() to manage the scan process to conserve power, as the devices can spend extended periods between networks. After 4 scanning cycles I call;
zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE);
ZDOInitDevice( 0 );
To allow the device to stop the rejoining process and allow a new join to take place on a new network.

To test the above;

Get the end device to join one of the network Coordinator. Once the end device is associated turn off the Coordinator the end device isi associated with. Watch the communications with the new coordinator.

Communication Behaviour;

Association fails
EndDevice issues: Association request
Coordinator: Ack (no data pending)
EndDevice issues:Data request (MAC SrcAddr Short address)
Coordinator: Ack (Data pending)
Coordinator issues: Data (Empty Payload)
EndDevice: Ack (No data pending)

Association Successful
EndDevice issues: Association request
Coordinator: Ack (no data pending)
EndDevice issues:Data request (MAC SrcAddr Mac Address)
Coordinator: Ack (Data pending)
Coordinator issues: Association Response
EndDevice: Ack (No data pending)

Rename the file .dcf
Only way I could get it to attach

#Format=4
# SNA v2.3.0.3 SUS:20081031 ACT:618932
#SEC_KEY:panid=-1 type=1 seqnum=0 device1="" device2="" key="01030507090b0d0f00020406080a0c0d"
#SEC_KEY:panid=-1 type=2 seqnum=-1 device1="" device2="" key="5a6967426565416c6c69616e63653039"
1 1464056473.000000 47 41883b752fffff00002512fcff000001da0a32e004004b120028270000000a32e004004b12000042761b983c23ffff 255 1 -25 25 1 0 1 32767
2 1464056488.092480 47 41883c752fffff00002512fcff000001db0a32e004004b120028280000000a32e004004b1200005d076520ad39ffff 255 1 -23 25 2 0 1 32767
3 1464056496.586880 52 41883d752fffff00002402ffff00001edc28290000000a32e004004b120000c9563cd6961accb1ab38574c04b1122baae3beffff 255 1 -26 25 3 0 1 32767
4 1464056503.181760 47 41883e752fffff00002512fcff000001dd0a32e004004b1200282a0000000a32e004004b1200005bb6f78aa73cffff 255 1 -24 25 4 0 1 32767
5 1464056518.274240 47 41883f752fffff00002512fcff000001de0a32e004004b1200282b0000000a32e004004b120000aeb889fdecefffff 255 1 -24 25 5 0 1 32767
6 1464056533.365440 47 418840752fffff00002512fcff000001df0a32e004004b1200282c0000000a32e004004b120000209720e32bc2ffff 255 1 -26 25 6 0 1 32767
7 1464056545.048000 10 030857ffffffff07ffff 255 1 -26 25 7 0 1 32767
8 1464056545.051840 28 008079752f0000ffcf00000090840a32e004004b1200ffffff00ffff 255 1 -25 25 8 0 1 32767
9 1464056545.086400 21 23c858752f0000ffff1a8dc407004b12000180ffff 255 1 -26 25 9 0 1 32767
10 1464056545.087360 5 020058ffff 255 1 -25 25 10 0 1 32767
11 1464056545.522560 12 638859752f0000405f04ffff 255 1 -26 25 11 0 1 32767
12 1464056545.523200 5 120059ffff 255 1 -25 25 12 0 1 32767
13 1464056545.526720 11 618842752f405f0000ffff 255 1 -25 25 13 0 1 32767
14 1464056545.527360 5 020042ffff 255 1 -26 25 14 0 1 32767
15 1464056545.663680 10 03085affffffff07ffff 255 1 -26 25 15 0 1 32767
16 1464056545.665920 36 00807a752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -24 25 16 0 1 32767
17 1464056545.850240 10 03085bffffffff07ffff 255 1 -26 25 17 0 1 32767
18 1464056545.853120 36 00807b752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -25 25 18 0 1 32767
19 1464056546.036800 10 03085cffffffff07ffff 255 1 -25 25 19 0 1 32767
20 1464056546.040320 36 00807c752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -32 25 20 0 1 32767
21 1464056546.222080 10 03085dffffffff07ffff 255 1 -25 25 21 0 1 32767
22 1464056546.224960 36 00807d752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -24 25 22 0 1 32767
23 1464056546.407680 10 03085effffffff07ffff 255 1 -25 25 23 0 1 32767
24 1464056546.410560 36 00807e752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -29 25 24 0 1 32767
25 1464056547.559360 21 23c865752f0000ffff1a8dc407004b12000180ffff 255 1 -24 25 25 0 1 32767
26 1464056547.560320 5 020065ffff 255 1 -23 25 26 0 1 32767
27 1464056547.998720 12 638866752f0000405f04ffff 255 1 -24 25 27 0 1 32767
28 1464056547.999360 5 120066ffff 255 1 -23 25 28 0 1 32767
29 1464056548.003840 11 618844752f405f0000ffff 255 1 -23 25 29 0 1 32767
30 1464056548.004800 5 020044ffff 255 1 -25 25 30 0 1 32767
31 1464056548.456640 47 418845752fffff00002512fcff000001e20a32e004004b1200282d0000000a32e004004b1200003a9b794ae422ffff 255 1 -24 25 31 0 1 32767
32 1464056551.521920 10 030879ffffffff07ffff 255 1 -26 25 32 0 1 32767
33 1464056551.524800 36 00807f752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -24 25 33 0 1 32767
34 1464056551.709440 10 03087affffffff07ffff 255 1 -25 25 34 0 1 32767
35 1464056551.712320 36 008080752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -23 25 35 0 1 32767
36 1464056551.896640 10 03087bffffffff07ffff 255 1 -26 25 36 0 1 32767
37 1464056551.900160 36 008081752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -25 25 37 0 1 32767
38 1464056552.083840 10 03087cffffffff07ffff 255 1 -25 25 38 0 1 32767
39 1464056552.086400 36 008082752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -25 25 39 0 1 32767
40 1464056552.271040 10 03087dffffffff07ffff 255 1 -25 25 40 0 1 32767
41 1464056552.274240 36 008083752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -29 25 41 0 1 32767
42 1464056552.459840 10 03087effffffff07ffff 255 1 -25 25 42 0 1 32767
43 1464056552.463680 36 008084752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -23 25 43 0 1 32767
44 1464056556.535360 52 418846752fffff00002402ffff00001ee3282e0000000a32e004004b120000db015d39fcc6e093d5ffcb40cb4b4f718db831ffff 255 1 -29 25 44 0 1 32767
45 1464056563.545600 47 418847752fffff00002512fcff000001e40a32e004004b1200282f0000000a32e004004b120000974e07226e79ffff 255 1 -23 25 45 0 1 32767
46 1464056571.600000 21 23c885752f0000ffff1a8dc407004b12000180ffff 255 1 -26 25 46 0 1 32767
47 1464056571.601280 5 020085ffff 255 1 -23 25 47 0 1 32767
48 1464056572.040000 12 638886752f0000405f04ffff 255 1 -26 25 48 0 1 32767
49 1464056572.040640 5 120086ffff 255 1 -23 25 49 0 1 32767
50 1464056572.044160 11 618849752f405f0000ffff 255 1 -24 25 50 0 1 32767
51 1464056572.044800 5 020049ffff 255 1 -26 25 51 0 1 32767
52 1464056575.585600 10 030899ffffffff07ffff 255 1 -25 25 52 0 1 32767
53 1464056575.590080 36 008085752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -23 25 53 0 1 32767
54 1464056575.771200 10 03089affffffff07ffff 255 1 -25 25 54 0 1 32767
55 1464056575.775040 36 008086752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -24 25 55 0 1 32767
56 1464056575.958720 10 03089bffffffff07ffff 255 1 -25 25 56 0 1 32767
57 1464056575.961920 36 008087752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -24 25 57 0 1 32767
58 1464056576.144960 10 03089cffffffff07ffff 255 1 -26 25 58 0 1 32767
59 1464056576.148480 36 008088752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -23 25 59 0 1 32767
60 1464056576.331200 10 03089dffffffff07ffff 255 1 -26 25 60 0 1 32767
61 1464056576.333760 36 008089752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -25 25 61 0 1 32767
62 1464056576.519040 10 03089effffffff07ffff 255 1 -26 25 62 0 1 32767
63 1464056576.521600 36 00808a752f0000ffcf00101a8dc407004b12000090840a32e004004b1200ffffff00ffff 255 1 -23 25 63 0 1 32767
64 1464056577.675520 21 23c8a5752f0000ffff1a8dc407004b12000180ffff 255 1 -26 25 64 0 1 32767
65 1464056577.676480 5 0200a5ffff 255 1 -25 25 65 0 1 32767
66 1464056578.113600 12 6388a6752f0000405f04ffff 255 1 -26 25 66 0 1 32767
67 1464056578.114560 5 1200a6ffff 255 1 -24 25 67 0 1 32767
68 1464056578.117120 11 61884b752f405f0000ffff 255 1 -24 25 68 0 1 32767
69 1464056578.117760 5 02004bffff 255 1 -27 25 69 0 1 32767
70 1464056578.636800 47 41884c752fffff00002512fcff000001e70a32e004004b120028300000000a32e004004b120000065191dd3b9affff 255 1 -24 25 70 0 1 32767

Hi Darren,

As mentioned, the easiest way to achieve the behavior you are describing is to clear the relevant areas of NV and perform a soft device reset. Fortunately, there are API calls we can use to do this. Please try replacing the following code:

zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE);
ZDOInitDevice( 0 );

with this:

zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE | ZCD_STARTOPT_DEFAULT_CONFIG_STATE);
SystemReset();

Let me know if this works in your application.

Really Guys,
This is equivalent to me ringing IT support and them advising to restart my computer.

I have already outlined in this thread, that restarting the device resolves the problem. I view this as a temporary fix.
I am already using a SystemReset() as the absolute worst case workaround for now, as this also upsets some of our other algorithms.   

I have also already tried  "zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE | ZCD_STARTOPT_DEFAULT_CONFIG_STATE);"  This was one of the first things I attempted. This has no effect as this only clears the NV_INIT items like the default poll rate.

Look into the problem properly.
There is a bug somewhere in the  APS to MAC interface. 
I have already given you a workaround that works. 

I'm looking for an official response from the Zstack team, for an official resolution   

Hi Jason,

I can send you our modified Z stack files,  ZDO and AF files.
I think sending you the Whole application and HAL could be problematic. 

Could you reply to my TI support tick ID: 1-2148113266  
I'll follow up with the files.

Cheers Darren

Hey Darren,

I just wanted to follow up on this issue again, I may have found something that will help you. After some tinkering I was able to reproduce the issue you experienced in the sniffer log you posted, i.e. your end device would send a data request with the short address from the previous PAN instead of the IEEE address, causing the association procedure to fail.

It turns out this issue is due to the fact that after a short address is assigned to the device in a specific PAN, the address is stored in a hardware register in addition to the NIB NV location, so you must clear it from this area as well. Out of the box, the way our stack is designed requires a user to factory reset a device before it is able to associate with a different PAN, so that is why there is not an obvious/easy way to accomplish behavior this with our APIs.

In your application, right before calling ZDOInitDevice(0), try adding the following code:

pMacPib->shortAddress = MAC_SHORT_ADDR_NONE;
MAC_RADIO_SET_SHORT_ADDR(pMacPib->shortAddress);

You will also need to include the following headers:

#include "mac_radio_defs.h"
#include "mac_pib.h"

I have tested this on a pair of SmartRF05 + CC2530EMs w/ Z-Stack HA 1.2.2a and it seems to work for me. Let me know if you're able to try this out, and if you would like I can post a more complete solution of the exact code I added to my project to test this.

Hi Jason,
Thanks for persisting and getting to the root of the problem.
Does your code have the same effect as this snippet, in the Zapp but never called. 

 // Invalidate nwk addr so end device does not use in its data reqs.
_NIB.nwkDevAddress = INVALID_NODE_ADDR;
uint16 addr = INVALID_NODE_ADDR;
ZMacSetReq( ZMacShortAddress, (uint8 *)&addr );

The above solution does not require direct calls to the MAC.
I have used the above code in my work around placing in inside the ZDOInitDevice();

if ( networkStateNV == ZDO_INITDEV_NEW_NETWORK_STATE )
{
   ZDAppDetermineDeviceType();

   if(devStartMode == MODE_JOIN)
   {
       // Initialize default ZDO_UseExtendedPANID to the APS one. - iMonitor 
       osal_cpyExtAddr( ZDO_UseExtendedPANID, AIB_apsUseExtendedPANID );

       // Invalidate nwk addr so end device does not use in its data reqs. 
       _NIB.nwkState = NWK_INIT;
       _NIB.nwkDevAddress = INVALID_NODE_ADDR;
       uint16 addr = INVALID_NODE_ADDR;
       ZMacSetReq( ZMacShortAddress, (uint8 *)&addr );
   }

    // Only delay if joining network - not restoring network state
    extendedDelay = (uint16)((NWK_START_DELAY + startDelay)
     + (osal_rand() & EXTENDED_JOINING_RANDOM_MASK));

    runtimeChannel = zgDefaultChannelList;
}

Hi Jason,

I have been trying your work around vs mine.
I find that both work arounds suffer from the same problem. They work for the first network hop. But seem to slow or prevent the detection of the new network being dropped. Preventing the next network hop. 

It would be great to get a fix root bug with when requesting a  new network Association.

Cheers Darren

Hi Darren,

I've made a few more modifications to the routine that I proposed originally. I've also attached a sniffer log showing the behavior of a ZED when I execute the code below. Could you please verify that it is the behavior that you are trying to achieve in your application?

Using a SmartRF05 + CC2530EM ZED, I mapped the following code to a hardware switch:

ZDApp_StopJoiningCycle();

zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE);

uint16 addr = MAC_SHORT_ADDR_NONE;
ZMacSetReq( ZMacShortAddress, (uint8 *)&addr );

// reinitialize the stack
macTaskInit( macTaskId );
nwk_init( NWK_TaskID );
APS_Init( APS_TaskID );
ZDApp_Init( ZDAppTaskID );

// retryCnt is in ZDApp.c and it is used in the logic to determine if an orphan
// procedure should start. If you do not reset it here, the device will not
// send orphan notification during the 3rd and subsequent associations.
retryCnt = 0;

ZDOInitDevice(0);

ZDApp_StartJoiningCycle();

To test this I started two networks on two ZCs, connected the ZED to one of them, turned off the ZC it connected to, let the ZED orphan + start beacon requesting, once I saw beacon responses from the other ZC I executed the code above and it would associate with the new network. You can see in the sniffer log that I did it sequentially in 4 different PANs.

Because this behavior isn't natively supported in Z-Stack these modifications will need to be implemented at the application level and I wouldn't really call this a "bug fix", but it should help you achieve the behavior you are aiming for.

ZED changing PANID + Parent 4 times.zip

Hi Jason,
I have just seen this post, I don't know how I missed the email notification.
I have reviewed the sniffer log. The behaviour shown is correct.

I would class the behaviour described in the forum as a bug. The behaviour demonstrated in your sniffer log use to work in the older versions of the stack.
We upgraded to the new version on the stack to resolve issues with the security authentication. When retesting the behaviour of our products I discovered the bug with the Nwk addressing when issuing an association request.

I'll give the work around a try now.

Cheers Darren

Hi Jason,
I have implemented the work around as follows. It seems to work nicely on first implressions. We will have to test is throughly of course.

Have you conducted a source review of the Init functions in this sujested fix, to check they are safe to recall over and over. As a Zstack user they are a black box to me.

Inside ZDOInitDevice()

  if ( networkStateNV == ZDO_INITDEV_NEW_NETWORK_STATE )
  {
    ZDAppDetermineDeviceType();
    if(devStartMode == MODE_JOIN) 
    {  
        //Invalidate nwk addr so end device does not use in its data reqs.     
        // reinitialize the stack
        ZDO_Init();
        APS_Init( APS_TaskID );
        //NWK
        nwk_init( NWK_TaskID );
        //MAC
        macTaskInit( macTaskId );             
        //HW Reg
        pMacPib->shortAddress = MAC_SHORT_ADDR_NONE;
        MAC_RADIO_SET_SHORT_ADDR(pMacPib->shortAddress);
        
        // retryCnt is in ZDApp.c and it is used in the logic to determine if an orphan
        // procedure should start. If you do not reset it here, the device will not
        // send orphan notification during the 3rd and subsequent associations.
        retryCnt = 0;
     }

cheers Darren

This simpler fix  with just including the reset  of  the Zapp retryCnt also seems to work.
Fixing the delay in detecting subsequent network orphaned events .

  if ( networkStateNV == ZDO_INITDEV_NEW_NETWORK_STATE )
  {
    ZDAppDetermineDeviceType();
    if(devStartMode == MODE_JOIN)
    {   
        // Initialize default ZDO_UseExtendedPANID to the APS one. - iMonitor 
        osal_cpyExtAddr( ZDO_UseExtendedPANID, AIB_apsUseExtendedPANID );
        
        //NWK
        _NIB.nwkState = NWK_INIT;
        _NIB.nwkDevAddress = INVALID_NODE_ADDR;
        //MAC
        uint16 addr = INVALID_NODE_ADDR;
        ZMacSetReq( ZMacShortAddress, (uint8 *)&addr );
        //HW Reg
        pMacPib->shortAddress = MAC_SHORT_ADDR_NONE;
        MAC_RADIO_SET_SHORT_ADDR(pMacPib->shortAddress);
        
        // retryCnt is in ZDApp.c and it is used in the logic to determine if an orphan
        // procedure should start. If you do not reset it here, the device will not
        // send orphan notification during the 3rd and subsequent associations.
        retryCnt = 0;
    }

I find with further testing that after the devices has join a new network they keep polling at the REJOIN_POLL_RATE of 440ms instead of the default poll rate of 5000secs. To resolve this I have added 

if ( ( (ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE) == 0 )
            || ( (ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE)
              && (zgChildAgingEnable == TRUE) ) )
        {
          NLME_SetPollRate( ZDApp_SavedPollRate );
        }

to

void ZDApp_ProcessNetworkJoin( void )
{
  if ( (devState == DEV_NWK_JOINING) ||
      ((devState == DEV_NWK_ORPHAN)  &&
       (ZDO_Config_Node_Descriptor.LogicalType == NODETYPE_ROUTER)) )
  {
    // Result of a Join attempt by this device.
    if ( nwkStatus == ZSuccess )
    {