Zigbee2mqtt: same pan_id with two concurrent setups

[bartplessers]

Bug Report

What happened

starting zigbee2mqtt on 2 different raspberry generate the same panId

What did you expect to happen

different panId

How to reproduce it (minimal and precise)

2 different raspberry pi's with:

• Zigbee2mqtt version 1.6.0 on bare-metal RPI3
• CC2531_USB-stick (using an USB extension cable)
• latest version: CC2531_DEFAULT_20190608.zip

on startup,
RPI-01

10/21/2019, 4:53:52 PM - info: Logging to directory: '/opt/zigbee2mqtt/data/log/2019-10-21.16-53-50'
10/21/2019, 4:53:52 PM - debug: Removing old log directory '/opt/zigbee2mqtt/data/log/2019-10-19.23-13-00'
10/21/2019, 4:53:52 PM - debug: Loaded state from file /opt/zigbee2mqtt/data/state.json
10/21/2019, 4:53:52 PM - debug: Saving state to file /opt/zigbee2mqtt/data/state.json
10/21/2019, 4:53:52 PM - info: Starting zigbee2mqtt version 1.6.0 (commit #e26ad2a)
10/21/2019, 4:53:52 PM - info: Starting zigbee-shepherd
10/21/2019, 4:53:52 PM - debug: Using zigbee-shepherd with settings: '{"net":{"panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"channelList":[11],"precfgkey":"HIDDEN"},"dbPath":"/opt/zigbee2mqtt/data/database.db","coordBackupPath":"/opt/zigbee2mqtt/data/coordinator_backup.json","sp":{"baudRate":115200,"rtscts":true}}'
10/21/2019, 4:53:54 PM - info: zigbee-shepherd started
10/21/2019, 4:53:54 PM - info: Coordinator firmware version: '20190608'
10/21/2019, 4:53:54 PM - debug: zigbee-shepherd info: {"enabled":true,"net":{"state":"Coordinator","channel":"11","panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"ieeeAddr":"0x00124b0018e1a46a","nwkAddr":0},"firmware":{"transportrev":2,"product":0,"version":"2.6.3","revision":20190608},"startTime":1571669634,"joinTimeLeft":0}
10/21/2019, 4:53:54 PM - info: Currently 0 devices are joined:
10/21/2019, 4:53:54 PM - info: Zigbee: disabling joining new devices.

on RPI-02

10/21/2019, 4:54:17 PM - info: Logging to directory: '/opt/zigbee2mqtt/data/log/2019-10-21.16-54-16'
10/21/2019, 4:54:17 PM - debug: Removing old log directory '/opt/zigbee2mqtt/data/log/2019-10-20.23-57-56'
10/21/2019, 4:54:17 PM - debug: Loaded state from file /opt/zigbee2mqtt/data/state.json
10/21/2019, 4:54:17 PM - debug: Saving state to file /opt/zigbee2mqtt/data/state.json
10/21/2019, 4:54:17 PM - info: Starting zigbee2mqtt version 1.6.0 (commit #e26ad2a)
10/21/2019, 4:54:17 PM - info: Starting zigbee-shepherd
10/21/2019, 4:54:17 PM - debug: Using zigbee-shepherd with settings: '{"net":{"panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"channelList":[11],"precfgkey":"HIDDEN"},"dbPath":"/opt/zigbee2mqtt/data/database.db","coordBackupPath":"/opt/zigbee2mqtt/data/coordinator_backup.json","sp":{"baudRate":115200,"rtscts":true}}'
10/21/2019, 4:54:24 PM - info: zigbee-shepherd started
10/21/2019, 4:54:24 PM - info: Coordinator firmware version: '20190608'
10/21/2019, 4:54:24 PM - debug: zigbee-shepherd info: {"enabled":true,"net":{"state":"Coordinator","channel":"11","panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"ieeeAddr":"0x00124b0018e1f452","nwkAddr":0},"firmware":{"transportrev":2,"product":0,"version":"2.6.3","revision":20190608},"startTime":1571669664,"joinTimeLeft":0}
10/21/2019, 4:54:24 PM - info: Currently 0 devices are joined:
10/21/2019, 4:54:24 PM - info: Zigbee: disabling joining new devices.

on the timestamps you can see the "proof" they are from different devices :-)

Both have panId:6754

I had some problems:

• my devices, that were paired to RPI-01
• I started RPI-02 and enabled joining
  For some reason, some devices were discovered on RPI-02 without explicitly joining this network.
  I suppose that -because both networks had the same panId- it all was messed up...
  Is this possible?

Debug Info

zigbee2mqtt version: 1.6.0
CC253X firmware version: 20190608

[Koenkk]

This is actually expected behaviour as this allows to recover a network on z-stack 1.2. Z-stack 3 will refuse to start when a duplicate pan id has been detected.

[bartplessers]

Hi @Koenkk,
Can you elaborate this a little bit more? Or point me to some documentation?

"this allows to recover a network on z-stack 1.2"
Does it mean that some close neighbor can "recover" my network?
Not feeling very comfortable with this..

[Koenkk]

If he uses the same network key, yes. That's why https://www.zigbee2mqtt.io/how_tos/how_to_secure_network.html is recommended.

[bartplessers]

Hello @Koenkk

Thanx. I changed my key.
Suggestion: because of importance of this key, I would like suggest that this setting is included by default in the out-of-the-box config. So users get more aware of potential risks by not changing the key. The documentation is very clear, no criticism on that, but for newbies like me, you start with the basic configuration like mentioned on on https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html.

It's maybe a good idea to have following lines in your example?

advanced:
  # change pan_id for your own environment
  pan_id: [default panId]
  # change pan_id for security reasons
  network_key: [default network key]

kind regards,
Bart

[ciotlosm]

@bartplessers @Koenkk @danielwelch Maybe a feature enhancement to:

Update docs

Update the configuration example comments to better reflect this

Current text

# Optional: network encryption key, will improve security (Note: changing requires repairing of all devices) (default: shown below)

Suggested text

This should maybe changed to a better text:
# Optional: It is highly recommended that you change your network encryption key, to avoid security problems (Note: changing requires repairing of all devices) (default: shown below)

Add a warning

Add a warn entry in the logs if zigbee2mqtt starts with the default key

Randomize key

Investigate the possibility to randomize the key in the addon (at installation time), so people have a different key before they start pairing, reading logs later on and realizing they need to start over.

[wassfila]

Yeah well, this could be the beginning of a long series of improvements, but I would also understand that the current status is to document these features and let the user decide.

• pan_id : always the same selected by default, not documented to the user, the user can override it. Here, it could be randomized on install process or with a new feature that could re-initialize the config. After generation it could be displayed in the config.
• ext_pan_id : this is the important one I think, as it is what would avoid packet clashes on rf receivers. Also could be randomized on init and displayed on config.
• channel : why is 11 always selected by default ? This also could be set accordingly in a smart way like a smart wifi router that checks the unused channels before settling on one. But as the channel cannot be changed in zigbee on the fly like on wifi, this should be decided by the users. And also a note on wifi channels interference could help users experience so that they avoid issues.
• network_key : discussed above. Could be randomized on init and displayed on the advanced config. If I understand it right, this only encrypts the data layer and not the lower netwrok and zigbee layers, so privacy or activity monitoring is still an issue.

zigbee2mqtt is fun to use and simple for most users. I struggle with re-pairing devices from time on my own network, so I can imagine my neighbors pain trying to spy on my network, to get a temperature sensor read.
Before using zigbee in security critical applications many more points would have to be checked further and not only those mentioned above.

[Koenkk]

@ciotlosm the warning and doc changes look good to me, can you make a PR?

I will further think about how we can randomize a key.

[ciotlosm]

@Koenkk Will do

[zhapwey]

A question to make the subject clear.
So that two networks in my home do not have conflicts between them, is it enough to generate a different network key or does the pan_id also need to be established as well?

[Koenkk]

@zhapwey

• Network key only matters for security reason
• If you want to have 2 separate zigbee networks on the same channel, they need to have a different pan_id.
• Although a better way to separate them would be to use a different channel, because otherwise the radio signals will interfere with each other. In this case pan_id can be the same.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.