Zigbee question - Insecure Rejoin Option

ptdalen · May 16, 2018, 2:00pm

Like quite a few people here, I have a HUSBZB-1. Also Like a lot of people, but ZigBee devices (3 iris open/close, 4 iris motion, one smartthings open/close and one smartthings motion) seem to be less than perfect. I mostly have issues with the iris devices falling off the network or getting stuck. For the most part this seems to happen after a restart of HA, but not always.

These devices were solid on Smartthings, and I came across this the other day, and would like to know if I could do something like this in HA, maybe a configuration setting somewhere.

If you don’t want to read the article here is one section that seems to give an good idea what it is

The current ZigBee Home Automation 1.2 standard uses encryption to allow only authorized devices to join a home network. In order to allow some devices (like motion sensors) to drop off of, and then easily re-join the network (to preserve battery power), there is a feature known as “insecure rejoin” built into the standard. It has been shown, however, that in very specific cases this feature could potentially be used to gain unauthorized access to a ZigBee network. The upcoming ZigBee 3.0 specification removes this potential vulnerability, but until that new standard is released, SmartThings is giving users the ability to disable the insecure rejoin feature.

I’m willing to take the risk of a hacker coming over to my house and jumping on my ZigBee network.

Anyone have any experience with this.

joe248 · December 1, 2020, 10:13pm

I know this is an old thread, but did you ever find a solution to this? I’m experiencing the same issue with a HUSBZB-1 and devices leaving the network and not rejoining.

walt · December 2, 2020, 5:25am

For OP, you can do:

zha:
  zigpy_config:
    ezsp_policies:
        TRUST_CENTER_POLICY: 3

ptdalen · December 2, 2020, 4:07pm

Wow, nice. ZHA has been very stable for me in the past year, but this is nice to see. is there a wiki or place where i can see what other config options there are out there?

walt · December 2, 2020, 4:42pm

Nothing documented yet, but we’d like to start a wiki on the zigpy project until the HA docs are reworked.

Here are some of the settings:

github.com

zigpy/bellows/blob/c12cbfecb296c70adb12f0db765dff397da589cc/bellows/ezsp/v4/types/named.py#L71


class EmberRf4ceNodeCapabilities(basic.uint8_t):
    # The RF4CE node capabilities.
    pass


class EmberRf4ceApplicationCapabilities(basic.uint8_t):
    # The RF4CE application capabilities.
    pass


class EzspConfigId(basic.enum8):
    # Identifies a configuration value.

    # The number of packet buffers available to the stack.  When set to the
    # special value 0xFF, the NCP will allocate all remaining configuration RAM
    # towards packet buffers, such that the resulting count will be the largest
    # whole number of packet buffers that can fit into the available memory.
    CONFIG_PACKET_BUFFER_COUNT = 0x01
    # The maximum number of router neighbors the stack can keep track of. A
    # neighbor is a node within radio range.
    CONFIG_NEIGHBOR_TABLE_SIZE = 0x02

And here is how to put them into configuration.yaml (though use zigpy_config for bellows based radios):

joe248 · December 3, 2020, 2:39pm

Thanks @walt. Can you explain what a TRUST_CENTER_POLICY of 3 means and what it does, as well as what the other options are?

Is it this?

Edit: wouldn’t we want a value of 0 to allow insecure rejoins?

walt · December 3, 2020, 3:42pm

TRUST_CENTER_POLICY is a bitmask (see bottom table):

3 gets you “allowed joins” and “allowed unsecured rejoins”

joe248 · December 3, 2020, 4:08pm

Got it, thanks. But I still don’t see how the numbers in the EzspDecisionId class correspond to the numbers in the bitmask chart, or are they not supposed to?