Multicast UDP port 6668 about multicast-relay HOT 10 OPEN

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

from multicast-relay.

from multicast-relay.

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

from multicast-relay.

from multicast-relay.

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"

from multicast-relay.

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.

from multicast-relay.

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.

from multicast-relay.

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 ! (-;

from multicast-relay.

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?

from multicast-relay.

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

from multicast-relay.