[REQUEST] Open ZigBee Coordinator Backup Format support for Zigbee network backups and restoring from and to ZiGate

[Hedda]

Request for developers depending on zigpy-zigate to consider implementing Zigbee network backup and restore tools to zigpy-zigate (or zigpy-cli) supporting the "Open ZigBee Coordinator Backup Format" as it is already supported by both zigpy-znp and bellows radio libraries + planned to be supported by all radio libraries for zigpy as a unified standard specification for backups:

• https://github.com/zigpy/open-coordinator-backup
• https://github.com/zigpy/zigpy/wiki/Coordinator-Backup-and-Migration
• https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#backup-and-restore
• https://github.com/zigpy/bellows#nvram-backup-and-restore

Update! The groundwork for these backup features are also indirectly being worked on by @puddly for zigpy-cli (zigpy CLI tool):

• Implement new radio API zigpy-cli#2

That, in turn, is dependent on all the work on the new radio API for zigpy:

• New radio API zigpy#848

which when merged in turn will require that new radio API for zigpy is then implemented into the zigpy-zigate radio library:

• Implement the new zigpy radio API #117

@pipiche38 @badzz @SylvainPer @jp-keros posting this request here to upstream zigpy-zigate but I believe that this feature should especially be of personal interest to you guys as if zigpy-zigate (or zigpy-cli) supported backing up and restoring to and from this "Open ZigBee Coordinator Backup Format" then it would allow your developers and users to simply migrate their Zigbee network from a ZiGate based Zigbee adapter to a Texas Instruments (or Silicon Labs Zigbee adapters and ConBee/RaspBee deCONZ adapters) as well as vice versa with reverse migrations.

I would think such a tool could make both testing and development easier as testers and developers will be able to compare the same Zigbee network by simply just temporarily migrating back and forth between different Zigbee stacks and hardware brands seamlessly using backup and restore methods to and from this unified open backup format standard for Zigbee networks without having to re-pair any Zigbee devices.

FYI, this is already a popular upgrade and downgrade method among end-users in the ZHA community as seen in examples here:

• https://www.youtube.com/watch?v=ql58ZfXso1M&ab_channel=EverythingSmartHome
• https://community.home-assistant.io/t/backup-your-zha-husbzb-1-stick-and-even-seamlessly-migrate-to-a-new-stick-without-re-pairing/229044/
• https://community.home-assistant.io/t/zha-integration-to-do-nightly-backup-of-both-zigbee-coordinator-adapter-dongle-stick-and-zigbee-database/357558

PS: Also keep in mind that this Open ZigBee Coordinator Backup Format is also already in use by the Zigbee2MQTT (Z2M) project.

[puddly]

@badzz says that he may be working on implementing the new radio API zigpy/zigpy#865 (reply in thread)

The whole purpose of this radio API change is to remove the need for radio libraries to have their own independent tools, since this all will be done by zigpy-cli or within zigpy directly.

[pipiche38]

I have a security concern as regards to this backup tool. For instance if you are able to backup a Zigbee dongle and get it restore somewhere else, this a huge security breach

[MattWestb]

I think making one service in HA for doing the backup that user can using doing automation is OK.
deCONZ is doing backup of there coordinator (at least then updating the system) but i think its not needed but open for the user doing it by hand or in one automation is not so bad and its up to the user using it with care.

And its the same with your keys to your house or car dont writing the address on them so the finder is not knowing where its can (ab)using them !!

[pipiche38]

I do not discuss the purpose of the backup, what I'm concern with is the fact that the backup can be use somewhere else and that is a security breach.
For instance what NXP does, is making sure that the back can ONLY be restore on the same MAC address

[MattWestb]

Silabs is doing nearly the same and its possible restoring on one other chip but must burning new MAC on it and its can only being made ones if not doing one chip erase with one J-Link probe.

But Silabs can restore with wrong MAC of the coordinator but then is the bindings not working to the coordinator and its not working for bonded devices (that is having the old MAC in the table).

As long the backup is in clear its still possible getting the network and link keys from it and that is the dangerous thing if your neighbour is also reading this forums :-)

[puddly]

For instance if you are able to backup a Zigbee dongle and get it restore somewhere else, this a huge security breach

How so? A user deciding to post their network key online isn't a security breach. Nothing prevents one from posting their WiFi password, online banking credentials, copy of their passport, and full address online, other than common sense.

Besides, an attacker interested in your specific network doesn't need access to a backup: the coordinator sends your network key in the clear every time you join a device without using an install code. Zigbee also has zero forward secrecy so an attacker can store your encrypted network traffic for months and then decrypt all past and future traffic when they learn your key. The protocol itself is as secure as a glass door.

For instance what NXP does, is making sure that the back can ONLY be restore on the same MAC address

Are you saying that you cannot change the IEEE address of a ZiGate coordinator at all?? Can you read the network key after writing it? What about setting the network key frame counter?

As long the backup is in clear its still possible getting the network and link keys from it and that is the dangerous thing if your neighbour is also reading this forums :-)

Agreed. The evil Zigbee neighbor will always win.

[pipiche38]

when you do the restore, will the Mac address of the zigbee coordinator overwrite ?

The reason is that if it is not done,

• then most of the IAS devices won't work any more and need to be reset in order to get the new IEEE coordinator
• I believe this will also be the case for most of the devices for which a bind has been explicitly made between them and the coordinator

[puddly]

Yes. Make sure to write the original down, deCONZ doesn't work properly if the address prefix changes.

[pipiche38]

that looks promising also for test purposes. I'll investigate it as it will allow to move test from one key to an other one with the same network

[puddly]

Here is all of the info that can be contained in the network state: https://github.com/puddly/zigpy/blob/d9129dbea31ce90a8b242c18c2adb8533f7f67c9/tests/test_app_state.py#L217-L283

It's unfortunate that the ZiGate does not have any way to even specify the PAN ID during network formation (I think this is a NXP limitation?). I was hoping to try directly editing this data in the PDM (like in zigpy-znp), at least to test with, but the only command that seems like it might work needs to be compiled into the firmware:

• https://github.com/fairecasoimeme/ZiGatev2/blob/33e144e3fb8e485d16451eace4b9181b3524ea15/Source/ControlBridge/app_Znc_cmds.c#L2536-L2558
• https://github.com/fairecasoimeme/ZiGatev2/blob/33e144e3fb8e485d16451eace4b9181b3524ea15/Build/mcux/Makefile#L119

My main goal is to migrate my production network over to the ZiGate to test. I'm able to find most of the missing information in the ZiGate flash dump to edit directly but I can't seem to find the frame counter (it's probably implemented as a boot/reset counter), or a single place to edit the PAN ID.

[SylvainPer]

@fairecasoimeme any idea?

[fairecasoimeme]

Hi,
currently, there are no API command to reach the PDM directly. In NXP's SDK, there are functions to read, delete or add records to PDM tables but I don't ouned yet the PDM structure and I don't know how to backup / restore with this way.

NXP give tools to backup/restore but only NXP to NXP. You can clone only if you write the old MAC address to the new device.

https://zigate.fr/documentation/cloner-la-zigate-pizigate/

[puddly]

@fairecasoimeme Thank you for the clarification. It looks like this is not possible at the moment.

[Hedda]

Originally posted by @pipiche38 in #117 (comment)

@puddly , I found that https://github.com/fairecasoimeme/ZiGate/blob/5a64452e3cc4f32afe217a332d0c9b1d97e17d84/ModuleRadio/Firmware/src/ZiGate/Source/ZigbeeNodeControlBridge/app_start.c#L1191 which can be interested for you as regards to a Backup/Restore solution.
If we take in consideration this procedure is used when the PDM size is changed during a firmware upgrade, we might think that can be used for Backup and then Restore.

@fairecasoimeme could that be used for ZiGate network backup/restore via zigpy-cli utility as discussed in zigpy/zigpy-cli#2 ?