strange behaviours on Network Address Request

[pipiche38]

I have an End Device CMS-323 which does'nt report anymore. However in sniff the guy is still around, but it looks like the Elelabs with zigpy-bellows doesn't cooperate.

If you look at packet 6368, the device is doing a broadcast to do a Network Address Request. The IEEE use here is the IEEE of the coordinator, an Elelabs Shield

Then when looking at packet 6377, the coordinator is doing a Route Request

Finally packet 6406 the end device is doing it's Data Request

Looks like the rest of the network works fine Network Key: "b0:a0:7a:5c:b2:f2:5e:59:f2:71:cb:ed:fa:13:a4:f5" CMS-SiliconLabs-Issue.pcapng.zip

[MattWestb]

This device 0x4d1a is not working with IT coordinators as direct child we is knowing. But in this case its using one router 0x66c0 and the router is broadcasting the network address request after is have acked in 154= OK. Then is one broadcast its passive acked so we dont have any 154 ack from the coordinator but as you is saying is the coordinator trying getting the rout to 0x4d1a and the network is not replaying with one replay it have founding it so the coordinator can not sending somthing to the 0x66c0 and letting the 0x4d1a in the network. If one device is not getting any Network Address response it shall silent leaving the network = OK

For see onlyt the sed and its parent use this as filter: (wpan.dst16 == 0x66c0) || (wpan.src16 == 0x66c0) || (wpan.dst16 == 0x4d1a) || (wpan.src16 == 0x4d1a)

I think your problem is "only" routing problem then the coordinator is not finding the device that is joining the device Jennic_00:01:fe:57:bb (00:15:8d:00:01:fe:57:bb) / 0x66c0 then most of the other router shall knowing where the 0x66c0 is and in 6381 is broadcasting the router request from 0x0000 to finding its child 0x4d1a but is not sending any response to 0x0000 = the bad device is Jennic_00:01:fe:57:bb (00:15:8d:00:01:fe:57:bb) / 0x66c0.

Can you share what device 0x66c0 Xiaomi or one OSRAM plug ?

[pipiche38]

Device 0x66c0 is a innr / SP120 Plug 0x4d1a is in the Associated Devices of the 0x66c0 0x4d1a is also in the Routing Table of 0x66c0

and the device 0x66c0 seems to work perfectly ..

[MattWestb]

Only that is not reporting its children then the coordinator asking for one of it as in sequence 6381. The coordinator must sending one OK for the Network Address Request and it shall being done with unicast and it cant doing that then is not finding the route the child is having.

Can you power off the Innr plug and sniffing then the SED is jumping to one new parent and see if its looks better ? I like see the Network Address Request and the response from the (new) parent.

I can having wrong that Network Address Request is not requiring one response from the coordinator then the device is have the network key but you is still having router problems in the network

Only for info: Older Philips HUE lights is not deleting there children and is reporting them also then they have jumping to one new parent and have broadcasting one Network Address Request -> all router shall deleting it and only the new parent shall keeping it and reporting it to the coordinator on request and that can making problems then one SED is being reported using more routers as parent.

[pipiche38]

OK. I'll keep you posted. I cannot make the test for now, but will be able to do it in 2 or 3 weeks from now. The test will consist into

• sniffing the traffic
• unplug the innr plug and see what is happening

It is always a pleasure to read your investigations. Thanks a lot