Coordinator send a broadcast frame ,but the parent don’t gave the broadcast to his child(end device)

It is useful to know the difference between broadcast address 0xFFFC, 0xFFFD, and 0xFFFF.

hi, YK Chen,thanks for your reply
i know the difference between broadcast address 0xFFFC, 0xFFFD, and 0xFFFF.
in my psd file ,DAA1 rebroadcasting the frame (at p.nrb=74) ,is 0xFFFF, so why it's child 8343 ask his parent for some data, DAA1 say i have no data for your

Do you change the default value of NWK_INDIRECT_MSG_TIMEOUT?

no

i think i found the bug in 2.5.1.a and in home 1.2.1 the bug come from

ZDApp_AnnounceNewAddress()

Not really understand what you mean. Can you explain?

From your trace I do not see any reason why the parent would not send the broadcast to its child. I just tested this scenario on with a 2.5.1 sample app Router and it forwarded the message as expected.

Can you try sending a unicast message to the child to make sure that you can communicate at the network level?

Has there been any child swapping behavior that could have caused the parent to think the child is no longer a child?

Also I notice that the write attr undivided messages are corrupted, there are not enough bytes. Is there any issue in your application? If you have a memory leak or a pointer over flow this could lead to stack variables being corrupted and unexpected behavior.

Regards,
TC.

Please provide more information regarding the bug you suspect in ZDApp_AnnounceNewAddress().

Regards,
TC.

Also I notice that the write attr undivided messages are corrupted, there are not enough bytes. Is there any issue in your application? If you have a memory leak or a pointer over flow this could lead to stack variables being corrupted and unexpected behavior.

i don't understand whate ,can you tell me which p.nrb it is

in Z-Stack Developer's Guide.pdf page=5

When a “Device Announce” is received, the association and binding tables are updated with the new short address,
routing table information is not updated (new routes must be established). If a parent determines that the “Device
Announce” pertains to one of its end device children, but it didn’t come directly from the child, the parent will
assume that the child moved to another parent.

not in ZDApp_AnnounceNewAddress(). just inZDO_ProcessDeviceAnnce() it call a RTG_RemoveRtgEntry( Annce.nwkAddr, 0 ); to updated routing table information

this is not right as Z-Stack Developer's Guide.pdf said

in response to "i don't understand whate ,can you tell me which p.nrb it is"
it is 66, my ZigBee packet sniffer is decoding this message as a ZCL write attr undivided messages. Are you using ZCL cluster or is this some proprietor message?

jie liao said:

in Z-Stack Developer's Guide.pdf page=5

When a “Device Announce” is received, the association and binding tables are updated with the new short address,
routing table information is not updated (new routes must be established). If a parent determines that the “Device
Announce” pertains to one of its end device children, but it didn’t come directly from the child, the parent will
assume that the child moved to another parent.

not in ZDApp_AnnounceNewAddress(). just inZDO_ProcessDeviceAnnce() it call a RTG_RemoveRtgEntry( Annce.nwkAddr, 0 ); to updated routing table information

this is not right as Z-StackDeveloper's Guide.pdf said

I think you are getting confused. ZDApp_AnnounceNewAddress() is used to send a device announce message, the paragraph you quoted from the users guide is referring to what is done when ZStack received a Device Announce.

Is this the basis for suspecting a bug in ZDApp_AnnounceNewAddress()? If so I do not think this is correct.

Regards, TC. 

I see this thread has diverged a little from your original issue. Can you please try the following things:

1. Start with a Zstack application with no modifications other than the security, ch etc needed to make it join your coord.
2. make sure that you erase the flash during download so that no network parameters are not restores from NV (in the case that NV_RESTORE is enabled).
3. make a packet trace of the association and sending of broadcast.

If this does not work please send me the packet trace.

one thing that could have caused this is that the Coord was powered cycled without NV_RESTORE after the device had joined, which made it forget it's children. It then created a network, the child orphan joined and thought it was still associated to the parent Coord and carried on sending data requests. The Coord did not have the child in its child table so did not forard any broadcasts.

In a real product NV_RESTORE should be enable on all devices, the devices will associate once and child tables are stored in NV.

Regards,
TC.