Thread OTA update failing - where do I look?

[safe junco]

I have added an IKEA TIMMERFLOTTE sensor to my (very limited) Thread mesh. It has popped up saying there is an OTA update to apply but I cannot seem to get it to apply.

Logs from Matter server are in https://community.home-assistant.io/t/ota-update-fails/971979 but I struggling at a bit higher level about where to even start debugging.

All I get in HA is Error during service call to update.install: Error updating: Target node did not process the update file and not a great deal more in Matter server logs

I have restarted everything, pressed buttons on the device to try and wake it etc. but no joy. Where can I start ooking into this? Do I need to look at pairing it to say Amazon Thread network and doing the update there or should this work in HA?

[safe junco]

Right so I have added an Espressif Thread Border Router and also a KLIPPBOK leak sensor which has an update available but does the same.

Other people have seen to have had success applying OTA updates. The devices pair and work quite happily which makes me wonder if there is anything special about how OTA updates get applied? I suspect the root cause is likely my network setup but the fact everything pairs and works means I can't figure out where to look.

Anyone have a detailed understanding of the OTA process who can help me work out what is going on?

[last canyon]

This doesn't solve your issue, but issues with OTA are known. The Matter server add-on will soon expose a config options that allows you to test a new Matter server, rewritten from scratch and based on Matter.js. This might improve OTA behavior in general.
For info and feedback, see this channel: #new-matter-server

[minor pumice]

You will find more detailed OTA log information if you ssh into your HA, cd into addon_configs/core_matter_server/updates/<device-id-of-failed-update>.
If everythong works well you should at least see three files:

ls -1  
3RM01_051_20240712_011537.bin
chip_kvs_ota_provider_20240816_194254
ota_provider_20240816_194254.log

where (in this case) the topmost is the firmware file, the other two are logs.

[safe junco]

I might give the alpha version a spin

[safe junco]

Thanks.
Yes I see another device got an OTA appear today (that one is powered but still the same result) and I do see

-rw-r--r-- 1 root root 514929 Jan 16 17:28 4476_12289_16777231_57dc5bcf-8c27-4db6-ba37-fc3aa976be0f.ota
-rw------- 1 root root   1722 Jan 16 17:28 chip_kvs_ota_provider_20260116_172835
-rw-r--r-- 1 root root  91975 Jan 16 17:29 ota_provider_20260116_172835.log

so the actual download of the update is taking place fine. there is a lot of low level stuff in the logs that I will go through now but attaching incase anyone who actually has some knowledge can spot anything obvious

[safe junco]

CHIP:DL: Found the primary Ethernet interface:enp1s0 jumped out as this is the trusted LAN but I had actually left the Matter server on this and set BACKBONE_IF: "enp1s0 on OTBR. So I am not entirely sure where this issue is but it is an network one as I suspected.

AI has said the logs show that

he Thread device is failing to "call back"

adding MATTER_SERVER_INTERFACE: "enp1s0.10" to Matter Server config and updating BACKBONE_IF on OTBR to be enp1s0.10 seems to have the update applying.

I am fairly sure this is down to the fact I have an explicit IPv6 address range allocated on this network so it is able to avoid using the Link-Local address