QS Processor generates lots of broadcast packets

Hi,

I have a small Lutron setup, but the client has lots of devices on the LAN, including Control4 processors and Control4 doorstations. I was mentioned on the Control4 forum that another dealer found that the Lutron QS processor sends a lot of frequent broadcast packets and since they isolated the processor (own VLAN) they stopped having issues.

Below is the post from C4:

has anyone experienced Lutron HomeWorks QS processors having negative impact on other gear on the LAN, e.g. Unifi AP to controller adoptions, slow web browsing, and Control4 intercom (2 × C4-DSC + 2 × glassedge touch screens)?

So far it seems like all the problems mentioned above went away when the Lutron processor was confined in a different subnet / multicasts were blocked from affecting the rest of the network.

The problem with Control4 intercom was that the door stations would get stuck regularly, nobody could ring the customer’s home from the outside etc.

Here’s a Wireshark capture of the multicasts.
https://dl.dropboxusercontent.com/u/...9_12_15.pcapng

Tried googling for 239.0.38.1 to see if there is any information about it. No luck. It doesn’t seem familiar to me either.
From the Wireshark captures I can see it’s sending 20 of these multicast datagrams per second. I guess it’s not that many. But I’m still wondering what they are.

Quote:

---

Originally Posted by etienneterblanche

Hi,

I have a small Lutron setup, but the client has lots of devices on the LAN, including Control4 processors and Control4 doorstations. I was mentioned on the Control4 forum that another dealer found that the Lutron QS processor sends a lot of frequent broadcast packets and since they isolated the processor (own VLAN) they stopped having issues.

Below is the post from C4:

has anyone experienced Lutron HomeWorks QS processors having negative impact on other gear on the LAN, e.g. Unifi AP to controller adoptions, slow web browsing, and Control4 intercom (2 × C4-DSC + 2 × glassedge touch screens)?

So far it seems like all the problems mentioned above went away when the Lutron processor was confined in a different subnet / multicasts were blocked from affecting the rest of the network.

The problem with Control4 intercom was that the door stations would get stuck regularly, nobody could ring the customer’s home from the outside etc.

Here’s a Wireshark capture of the multicasts.
https://dl.dropboxusercontent.com/u/...9_12_15.pcapng

Tried googling for 239.0.38.1 to see if there is any information about it. No luck. It doesn’t seem familiar to me either.
From the Wireshark captures I can see it’s sending 20 of these multicast datagrams per second. I guess it’s not that many. But I’m still wondering what they are.

---

Dear etiennerterblanche,

Thank you for the inquiry.

The HomeWorks QS processor use multicast packets to communicate to each other. The system address of the HomeWorks QS processors is 239.0.38.1 by default. This can be found on the Activate screen under Advanced Settings. Depending on how active the system is will depend on how much multicast traffic is being sent.

Sorry, to which devices do they need to communicate using multicast packets? Can I disable this and/or block it? The only IP communication is to the Control4 processor, iPads with Lutron app and QS Software.

Quote:

---

Originally Posted by etienneterblanche

Sorry, to which devices do they need to communicate using multicast packets? Can I disable this and/or block it? The only IP communication is to the Control4 processor, iPads with Lutron app and QS Software.

---

Dear etienneterblanche,

Thank you for then follow-up.

The HWQS processors will communicate to other processors with multicast. This communication cannot be disabled or blocked.

Exactly the same thing is happening with RR2 repeaters, they generate this kind of traffic as well - even if there is just a single repeater in the system.