ezsp adapter crashes on frame missing senderEui64 field

[willnorris]

I am running Z2M with a Sonoff ZBDongle-E controller. When trying to connect a CMARS US-101 smart plug (which uses this ewelink zr03 config), Z2M consistently crashes with the following error:

zigbee-herdsman:adapter:ezsp:debg processMessage: {"messageType":0,"apsFrame":{"profileId":49246,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":255,"options":256,"groupId":0,"sequence":1},"lqi":255,"rssi":-31,"sender":35425,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[8,0,10,0,0,16,0]}} +61ms

/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/adapter/ezspAdapter.ts:103
                address: `0x${frame.senderEui64.toString()}`,
                                                ^
TypeError: Cannot read properties of undefined (reading 'toString')
    at EZSPAdapter.processMessage (/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/adapter/ezspAdapter.ts:103:49)
    at Driver.emit (node:events:527:28)
    at Driver.handleFrame (/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/driver/driver.ts:278:22)
    at Ezsp.emit (node:events:527:28)
    at Ezsp.onFrameReceived (/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:303:28)
    at SerialDriver.emit (node:events:527:28)
    at SerialDriver.handleDATA (/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:228:14)
    at SerialDriver.onParsed (/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:175:22)
    at Parser.emit (node:events:527:28)
    at Parser.parseNext (/Users/willnorris/src/zigbee2mqtt/zigbee-herdsman/src/adapter/ezsp/driver/parser.ts:37:26)

The ezsp adapter assumes that this frame will have a senderEui64 field, but that's not present. Interestingly, this is the only place in the ezsp adapter code that frame.senderEui64 is used instead of frame.sender. I'm not sure if that's intentional?

I tried switching this line to use frame.sender like all of the other code, and I was able to successfully connect the switch. I'm happy to send a PR, but I wanted to check first since I'm very unfamiliar with this code.

/cc @kirovilya who seems to be working the most in this area

[MattWestb]

If the device IEEE is not known (not in the router / neighbor table) in the coordinator the system cant communicating with it with IEEE. Then the system must trying Nwk address of the device. If its not known then the coordinator is doing one router request to finding it in the network, If the device cant being found by IEEE and Nwk then its no route to the device = off line.

Ops i think its the way around first Nwk and then IEEE but is not importing and direct IEEE addressing is normally not being used in the system then Nwk is faster with exception pairing and router management.

And pleas help kirovilya with debugging and fixing issues so the last parts can being fixed and getting EZSP as stable in Z2M.

[rccoleman]

I'm seeing the same issue with my SkyConnect 1.0 and making the change described above allows me to join and use the plugs as well. I understand that it may not be the right final solution, but I just wanted to chime in that it allows me to use the devices.

[kirovilya]

@willnorris @rccoleman can you record a herdsman log of this event to see the incoming frame? maybe you really need to change it to sender

[willnorris]

The first line of the error message above shows the incoming frame (it has sender, but not senderEui64). I can grab more of that'd be helpful when I'm back from traveling next week.

[kirovilya]

The first line of the error message above shows the incoming frame (it has sender, but not senderEui64). I can grab more of that'd be helpful when I'm back from traveling next week.

yes, I see, but I wanted to see the previous log entries, to have the full view of the device interview. this event seems to arrive before the device has written to eui64ToNodeId and therefore cannot get the full address. or, it has already been removed from this list.

[rccoleman]

Here's the herdsman log, starting from where I permitted joining and ending with the crash. herdsman_log.txt

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[rccoleman]

As far as I know, this is still a problem.

[kirovilya]

try with latest z2m 1.30.0

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[willnorris]

@rccoleman would you be able to test this, since you were also experience this problem? Unfortunately, all of my hardware is packed away while I'm moving right now so I can't test it myself, but it looks like 064662f37da1c0538e52e09f80bc3f724eb693a9 should have fixed this.

[rccoleman]

Sure, I'll give it a try over the weekend.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days