devices not found on running multicast-relay

[girtsn]

Hello, thanks for this awesome container for UDMP - I read a lot of people successfully got it working. I have SSDP/mDNS using devices on br0 and br2, turned off IGMP snooping and mDNS features in UDMP and also killed the avahi processes as I read those can cause some issues. Running with 'podman run --rm -it --network=host -e OPTS="--verbose --noSonosDiscovery" -e INTERFACES="br0 br2" docker.io/scyto/multicast-relay' It outputs relay messages, but in the end the SSDP/mDNS devices are not detected accross br0 and br2, they ones on the same subnet are detected just fine. I tried to put firewall rules allowing everything on LAN to no good.

./multicast-relay/multicast-relay.py INFO: [SSDP] Relayed 153 bytes from 192.168.1.117:39065 on br0 [ttl 1] to 239.255.255.250:1900 via br2/192.168.2.1 ./multicast-relay/multicast-relay.py INFO: [SSDP] Relayed 333 bytes from 192.168.2.168:1900 on br2 [ttl 255] to 239.255.255.250:1900 via br0/192.168.1.1

any ideas what could be the issue?

[scyto]

Hi,

Are .117 and .168 the devices in question? If so then everything is working fine in terms of what this container does.

However this is only part of the device discovery sequence and lots of devices do the rest of the handshake after the successful SSDP or mDNS in different ways. For example of sonos it is the sonos device that initiates a unicast TCP to the client and not the client that initiates to the device. yes it is weird!

In general i recommend that during testing one turns off all firewall rules between networks - or rather that it is set to ALL<>ALL - if that doesn't work you don't have a mDNS or SSDP discovery problem but some other routing issue.

What are the devices? This container only does some IGMP packets and it proxies them (not routes them) because the UDMP doesn't support multicast routing at a kernel level :-( if for example you are doing IPTV i would expect this to be a poor solution - but you can use the command line switches to define multicast addtional routing groups if you know what they are.

[girtsn]

Thanks for the hints, very useful. My main req was to have Synology NAS media server which sits on my main LAN to be discoverable by media players on IOT vlan (like my isp tv decoder). I thought most setups described to be working using multicast-relay would be doing DLNA. But in fact it is not the reality, Seems that they don't use DLNA and that DLNA is expected to only work on the same subnet by design or by some custom routing for which I find no examples in Unifi subsystem.

[scyto]

DLNA uses SSDP for discovery https://community.arubanetworks.com/browse/articles/blogviewer?blogkey=275564c2-b2da-4378-902f-0e59b3f6ca16 i have a synology if i get the time i will do a test - but please make sure you do the test with all firewall restrictions off between the two subnets.

If your synology has multiple LAN ports - consider connecting one LAN port to the other subnet and using the firewall on the synology to protect that port and only allow the traffic you want.

[scyto]

DLNA is working for me for a variety of services on my LAN (including emby running on my synology) when using a client on the IoT network (i do it this way around as IoT is only a test network in my system, I run everything on LAN, but this is functionally equivalent to what I assume you are doing - client on LAN and steamer on IoT?)

Interestingly audio station doesn't show up, note in test below i was passing mDNS and SSDP

You might want to do a network capture on the synology port with wireshark and see what multicast group audiostation / app you are using on the synology sends to and then add that to the relay config using --relay in the OPTS variable.

--edit-- hmm seems audio station isn't an DLNA server as it isn't discovered when my client and server are on same network (i don't use audio station just installed for this test)

tl;dr DLNA is working perfectly with the container with a variety of DLNA server sources and DLNA clients.

[girtsn]

hmm so it can work :(

what I have is a TV corner which has a TV and a ISP given tv decoder box, both of them are media devices with DLNA this is connected via an unmanaged switch port where port profile is set to default profile of network "iot" then there is Synology NAS on main lan as well as my pc

with setup like this (and relay running) 1) my pc detects Synology NAS 2) TV detects the tv decoder box

if I put the port profile of the tv corner to LAN instead of iot: 1) my pc detects Synology NAS, tv and tv decoder box 2) TV detects the NAS and tv decoder box

network settings = tried to disable all LAN firewall rules (no others defined), no effect upnp enabled unifi mDNS disabled igmp snooping disabled on every network device isolation disabled on every network

[scyto]

I have no experience of ISP TV boxes that work over IP.

I have seen threads of people trying to get them to work, generally it seems it requires a full multicast router; multicast-relay is not a full multicast router and until UDMP adds kernel support for multicast-routing there is no way to implement a container to do full multicast routing of video streams.

In terms of pure discovery (and assuming it can do unicast streams) it doesn't sound like your TV box is using SSDP or pure DNLA OR it is not using standard multicast addresses and ports and you will need to add them with --relay. OR there is something you are not telling me about your port profiles / groups / firewall (but it doesn't seem like it).

I am closing this ticket as your are gonna have to network sniff and see whats going on at the network layer and then figure out if suggestion 2 above will even work....

I suggest you focus on getting a different DLNA device placed on you IoT network to be seen by your PC and build upwards from there.

(PS you may find this super useful to see what is happening in addtion to wireshark http://noeld.com/programs.asp?cat=dstools#upnptest - SSDP is upnp)