Broadcast packets in parse?

5904	2615.389224	0xbead	Broadcast	ZigBee ZDP	114	Match Descriptor Request, Nwk Addr: 0xfffd, Profile: 0x0104
Frame 5904: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface 0
Internet Protocol Version 4, Src: 192.168.1.3, Dst: 192.168.1.3
User Datagram Protocol, Src Port: 17754, Dst Port: 17754
ZigBee Encapsulation Protocol, Channel: 20, Length: 54
IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x0000
ZigBee Network Layer Data, Dst: Broadcast, Src: 0xbead
ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
    Frame Control Field: Data (0x08)
    Destination Endpoint: 0
    Match Descriptor Request (Cluster ID: 0x0006)
    Profile: ZigBee Device Profile (0x0000)
    Source Endpoint: 0
    Counter: 21
ZigBee Device Profile, Match Descriptor Request, Nwk Addr: 0xfffd, Profile: 0x0104
    Sequence Number: 11
    Nwk Addr of Interest: 0xfffd
    Profile: Home Automation (0x0104)
    Input Cluster Count: 1
    Input Cluster List
        Input Cluster: OTA Upgrade (0x0019) (OTA Upgrade)
    Output Cluster Count: 0

catchall: 0000 0006 00 00 0040 00 BEAD 00 00 0000 00 00 0AFDFF040101190000

Should I be seeing match descriptor requests in my driver?

ZDP frames are now sent to drivers, since 2.0.7 or there abouts, though i agree there is limited value to this one...

Good to know! Was not expecting to see that. Saw that on a couple devices and got a bit excited when I saw chatter from a Lutron connected bulb remote. If we could see the other bcast packets it was sending it could probably be a more useful device :slight_smile:

yeah, unfortunately the lutron bulb remote is a no go, they use a specific broadcast group id that the zigbee firmware isn't listening for, this is the exact reason the Ikea steering wheel remote won't work.
Many touchlink devices will switch to unicast messaging when they get a bind request from the hub, these devices can then be used in HE, those that don't support this generally can't be used.
I haven't dived into the touchlink cluster spec that much, but it appears that this observation of the device switching from multicast to unicast is arbitrarily up to the device manufacturer vs being a defined implementation standard...

Bummer. Oh well. Thanks for the info!