ZBOSS stack fails to update short address for a bind entry

[theorlangur]

This is a continuation of this ticket. nrf54l15 zigbee end-device is bound with its On/Off client cluster to a On/Off server cluster of another ZigBee smart lamp.

I can see with a wireshark sniffing that this device sends when appropriate On or Off commands to the short address it takes apparently from internal table.

Now it happened so that for some reason (irrelevant to this case) that smart lamp has changed its short address. So the one nrf54l15 is using is no more valid.

Old one: 0xb7cf, new one: 0x56a8

I can see from the sniffed traffic, that after a couple of failed attempts to send the command, nrf54l15 sends a broadcast request to resolve the short address by the IEEE MAC address.

And the lamp in question indeed answers that broadcast request, telling it's current short address (0x56a8) to which nrf54l15 also sends an ACK.

But that's it: no On/Off command with the correct short address is sent after this seemingly successful resolution. However what's worse: on the next event when on/off command is sent

it's sent to the same old address 0xb7cf, not the new one.

So apparently as the result of that broadcast request the new, correct short address was not properly updated in the binding table's entry.

Could devs check this code path, please? 

[Maria Gilje]

Hello, 

Thank you for the trace and the summary. 

I am not able to decrypt packets with the standard keys (ZigbeeAlliance09 nor Nordic Examples). It is expected that you have a unique network key, so could you please provide this so we can decrypt the trace? If you don't want to share the key in a public ticket, please let me know. Alternatively you could create a new trace which catches the commissioning process. 

Also, we have seen some compatibility issues with some third party devices, so we're not always able to solve those issues on our end. But rest assured, we will investigate this properly. The root cause for the issues varies for those third party devices, and we have seen cases where they are not following the specification or that their implementation causes issues in certain scenarios. 

Best regards, 

Maria

[theorlangur]

sure, my bad. Attaching description with the key.desc.zip

I don't think it's a compatibility issue at all. Rather a bug in the protocol handling. As I said earlier: nrf54l15 correctly sends a broadcast address query request and receives a correct answer to it with a valid 16-bit network address. It just for whatever reason fails to properly update it in the internal address translation table. And so subsequent attempts to send the command fail for exactly the same reason: stale destination short address.