Multicast UDP port 6668

[paulearley]

This fine project allows my Home Assistant to connect with Sonos. I have one other multicast need, Home Assistant on one VPN needs to send multicast messages in UDP or TCP through port 6668 to another VLAN. Is there a way to set this with the "relay" option? Sorry I do not know enough about multicast or python to figure this out. Thanks!

[alsmith]

Hi Paul! Try adding --relay A.B.C.D:6668, substituting the multicast IP# - that ought to work.

[paulearley]

Thanks very much! will give it a try. Now I have to figure out which UDP IP to use for this broadcast. I cannot broadcast the IP of the client or server that is actually involved in the communication, because multicast-relay responds with this error:IP address 192.168.30.100 is neither a multicast nor a broadcast address  (which totally makes sense) I need to do more study about Multicast and will report back.

Paul On Monday, February 8, 2021, 04:20:22 AM EST, Al Smith notifications@github.com wrote:

Hi Paul! Try adding --relay A.B.C.D:6668, substituting the multicast IP# - that ought to work.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[alsmith]

Hi Paul, this might help, where ethN refers to the interface where the broadcast is coming from, and A.B.C.D is the IP# of the source device:

tcpdump -ni ethN src A.B.C.D and dst net 224.0.0.0/4

[paulearley]

Great! Looking into this now. Thanks again.Paul On Tuesday, February 9, 2021, 03:11:53 AM EST, Al Smith notifications@github.com wrote:

Hi Paul, this might help, where ethN refers to the interface where the broadcast is coming from, and A.B.C.D is the IP# of the source device:

tcpdump -ni ethN src A.B.C.D and dst net 224.0.0.0/4

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[fender4645]

I'm seeing the exact same thing as @paulearley. Running the relay on a UDM using the scyto/multicast-relay docker image. I'm even trying to use the same device port as him (6668) so maybe it's an actual problem with the Tuya-based devices? I ran the tcpdump command mentioned above and it received nothing:

# tcpdump -ni br30 src 192.168.30.177 and dst net 224.0.0.0/4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br30, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

EDIT: I actually didn't have the container running when I ran the above. Fired it up but got the same results. Also, getting the error mentioned above "IP address 192.168.30.177 is neither a multicast nor a broadcast address"

[tempestrock]

Hi @alsmith ,

Just wanted to say "thank you" for this great tool! I used it successfully today for the (so far broken) connection between my Sonos players and my OpenHAB instance. The OpenHAB instance runs in a small private Kubernetes (K3s) cluster and therefore is located in a different subnet compared to the Sonos speakers. 'multicast-relay' made my day - I just had to call it on the right Kubernetes node that has access to both subnets. Really great, thanks again!

BTW: I also mentioned your tool in the OpenHAB community because the difficulty to get OpenHAB access to Sonos devices that are located in a different subnet is a very well known issue there and I think that your solution can help a lot of people in that community.

[alsmith]

I actually didn't have the container running when I ran the above. Fired it up but got the same results. Also, getting the error mentioned above "IP address 192.168.30.177 is neither a multicast nor a broadcast address"

Yeah you'd need to somehow be able to work out what the protocol is. I would have thought that the tcpdump might have come up with something that would help you work out what to supply to --relay but it looks like either it's not transmitting multicast but something else, or that the packets are otherwise not making it to tcpdump.

One thing to now try would be this, if you can work out the device's mac address:

tcpdump -ni ethN ether src nn:nn:nn:nn:nn:nn and see if that produces anything helpful. If you have a lot of data and want to send me a trace to look at I'd be more than happy to help.

[alsmith]

Hi @alsmith ,

Just wanted to say "thank you" for this great tool! I used it successfully today for the (so far broken) connection between my Sonos players and my OpenHAB instance. The OpenHAB instance runs in a small private Kubernetes (K3s) cluster and therefore is located in a different subnet compared to the Sonos speakers. 'multicast-relay' made my day - I just had to call it on the right Kubernetes node that has access to both subnets. Really great, thanks again!

BTW: I also mentioned your tool in the OpenHAB community because the difficulty to get OpenHAB access to Sonos devices that are located in a different subnet is a very well known issue there and I think that your solution can help a lot of people in that community.

That's awesome - thankyou very much for the kind feedback! That made my day too ! (-;

[MRobi1]

I'm seeing the exact same thing as @paulearley. Running the relay on a UDM using the scyto/multicast-relay docker image. I'm even trying to use the same device port as him (6668) so maybe it's an actual problem with the Tuya-based devices? I ran the tcpdump command mentioned above and it received nothing:

Based on the tuya-local change log Added support for passive devices, I.e. connection attempts are now made when discovery messages are received. This is a breaking change as these messages are now mandatory for the integration to function. Ensure UDP broadcasts for port 6666 and 6667 are forwarded to Home Assistant.

This could be why you're seeing nothing on port 6668.

Now I'm here looking for the same solution since the update to this integration. When we're adding --relay A.B.C.D:6668 does this need to be done for every Tuya device we're looking use?

[alsmith]

Anyone able to help out @MRobi1 ? I'm a bit stumped as to what to suggest, to be honest.