How to configure igmpproxy for minidlna between 2 subnets?

Hi, I know this kind of question has been asked before and I've studied the pertinent threads to no avail. I have a br-lan subnet 10.238.134.0/24 that has a minidlna server, and I want to stream from that to my guest subnet (called "iso") 10.238.135.0/24 on wlan0-1. My igmpproxy.conf looks like:

config igmpproxy
        option quickleave 1
        option verbose 3

config phyint
        option network lan
        option zone lan
        option direction upstream
        list altnet 10.238.134.0/24

config phyint iso
        option network iso
        option zone iso
        option direction downstream

When I start igmpproxy, the log shows that no routes are added, and if I attempt to find a upnp server from VLC on the iso network, tcpdump on the router shows:

tcpdump -vv host 10.238.135.120 -i wlan0-1
tcpdump: listening on wlan0-1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:23:11.444596 IP (tos 0x0, ttl 255, id 43095, offset 0, flags [DF], proto UDP (17), length 68)
    10.238.135.120.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _googlecast._tcp.local. (40)
16:23:11.444697 IP (tos 0x0, ttl 255, id 43095, offset 0, flags [DF], proto UDP (17), length 68)
    10.238.135.120.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _googlecast._tcp.local. (40)
16:23:11.449556 IP (tos 0x0, ttl 255, id 43096, offset 0, flags [DF], proto UDP (17), length 151)
    10.238.135.120.5353 > 224.0.0.251.5353: [udp sum ok] 0 [5q] PTR (QM)? _ftp._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _nfs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _rtsp._tcp.local. (123)
16:23:11.449640 IP (tos 0x0, ttl 255, id 43096, offset 0, flags [DF], proto UDP (17), length 151)
    10.238.135.120.5353 > 224.0.0.251.5353: [udp sum ok] 0 [5q] PTR (QM)? _ftp._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _nfs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _rtsp._tcp.local. (123)
16:23:11.449766 IP (tos 0x0, ttl 64, id 30791, offset 0, flags [DF], proto UDP (17), length 78)
    10.238.135.120.37051 > 255.255.255.255.137: [udp sum ok] UDP, length 50
16:23:11.449870 IP (tos 0x0, ttl 64, id 30791, offset 0, flags [DF], proto UDP (17), length 78)
    10.238.135.120.37051 > 255.255.255.255.137: [udp sum ok] UDP, length 50
16:23:11.473462 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    10.238.135.120 > 239.255.255.250: igmp v2 report 239.255.255.250
16:23:11.473587 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    10.238.135.120 > 239.255.255.250: igmp v2 report 239.255.255.250
16:23:11.907635 IP (tos 0x0, ttl 4, id 31320, offset 0, flags [DF], proto UDP (17), length 155)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 127
16:23:11.907777 IP (tos 0x0, ttl 4, id 31320, offset 0, flags [DF], proto UDP (17), length 155)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 127
16:23:12.008369 IP (tos 0x0, ttl 4, id 31326, offset 0, flags [DF], proto UDP (17), length 155)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 127
16:23:12.008486 IP (tos 0x0, ttl 4, id 31326, offset 0, flags [DF], proto UDP (17), length 155)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 127
16:23:12.516841 IP (tos 0x0, ttl 4, id 31347, offset 0, flags [DF], proto UDP (17), length 146)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 118
16:23:12.516956 IP (tos 0x0, ttl 4, id 31347, offset 0, flags [DF], proto UDP (17), length 146)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 118
16:23:12.616728 IP (tos 0x0, ttl 4, id 31348, offset 0, flags [DF], proto UDP (17), length 146)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 118
16:23:12.616839 IP (tos 0x0, ttl 4, id 31348, offset 0, flags [DF], proto UDP (17), length 146)
    10.238.135.120.59788 > 239.255.255.250.1900: [udp sum ok] UDP, length 118
16:23:13.954562 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    10.238.135.120 > 239.255.255.250: igmp v2 report 239.255.255.250

The box serving minidlna does not appear to get any type of request, from all the tcpdump-ing I can do (which makes sense if igmpproxy didn't add any routes). What am I missing?

Perhaps you can explain...what does minidlna have to do with igmpproxy?

  • Stream from what?
  • Are you saying that you want the DLNA server to stream something?
    • If so, what?
  • Have you configured any streaming services for that to happen?

I'm lost, what does mDNS have to do with streaming via IGMP?

This is DLNA...

  • Why would a route be added?
  • I didn't see, what device on ISO requested/subscribed a stream - can you show us?
  • Can you show this log?

Are you trying to do DLNA or IGMP?

I don't see anything wrong, I just don't see where you expect VLC to stream across networks using multicast.

Most persons rig the packets and setup multicast forwarding; you haven't shown any IGMP-based streaming infrastructure, only DLNA LAN discovery.


I think maybe you're seeing various multicast packets and believe its IGMP?

I'm obviously not sure what I need to do. I thought I read that igmpproxy could allow a client on one network to be served by minidlna hosted on a different network. From your reply it seems that this is the wrong approach.

Yes - I want the DLNA server to stream music and videos to the guest network, the same as it does on the br-lan network. I have not configured anything on the server machine. Is that something I should do?

This is probably why I thought igmpproxy would help - my client sends SSDP packets to 239.255.255.250:1900, and nothing comes back:

tcpdump -vv port 1900 and host 10.238.135.229
tcpdump: listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:51:43.717630 IP (tos 0x0, ttl 4, id 6063, offset 0, flags [DF], proto UDP (17), length 155)
    10.238.135.229.59824 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 127

That is probably the case - I'm in over my head, but I'm trying to learn.

I had the idea that igmpproxy was multicast forwarding. How should I rig the packets?
Thanks for your help!

smcroute works better for this purpose.
Setup it up to forward 239.255.255.250 (DLNA) packets between the networks.
Make sure no firewall rules are blocking those packets and that TTL is > 1.
Maybe you also need to setup additional firewall rules to allow connections to minidlna.
For the initial setup and testing maybe you also want to
disable igmp snooping on any related bridge interface.

2 Likes

Accidentally deleted my reply:

Excellent, thank you. I've been trying to go in that direction. My smcroute.conf:

mgroup from wlan0-1 group 239.255.255.250
mgroup from br-lan group 239.255.255.250
mroute from wlan0-1 group 239.255.255.250 to br-lan
mroute from br-lan group 239.255.255.250 to wlan0-1

This afternoon when I tried to discover DLNA servers, my multicast routes looked reasonable. (I can't recall exactly what they were, but there were two of them, as expected). Then for a while my wife's laptop (a Windows machine) showed up as the internal interface - it's on br-lan and I guess it wants to subscribe to the SSDP group.

ip mroute
(10.238.134.212, 239.255.255.250) Iif: unresolved  State: resolved

And now, I don't get any routes at all. I've stopped and started smcroute, etc. When it's feasible I'll reboot the router and try some more.

Also in https://forum.openwrt.org/t/multicast-across-subnets-smcroute/47222 someone noted that the package included in 18.06.5 is version 2.0.0.2 and "dated" - which may or may not be an issue. The OP from that thread got things working with smcroute 2.4.4 from a 19.07 snapshot. I considered flashing rc2 in the hope that I'd get better results.

Okay, my routes are showing up now:

ip mroute
(10.238.134.200, 239.255.255.250) Iif: br-lan     Oifs: wlan0-1  State: resolved
(10.238.135.3, 239.255.255.250)  Iif: wlan0-1    Oifs: br-lan  State: resolved
(10.238.134.212, 239.255.255.250) Iif: br-lan     Oifs: wlan0-1  State: resolved
(10.238.135.120, 239.255.255.250) Iif: wlan0-1    Oifs: br-lan  State: resolved

But still no response on the server (10.238.134.200). Will try forwarding rules.

I'm trying to forward SSDP from the iso zone to the br-lan host 10.238.134.200. My firewall entry:

config redirect
        option target 'DNAT'
        option src 'iso'
        option dest 'lan'
        option proto 'tcp udp'
        option dest_ip '10.238.134.200'
        option name 'ssdp-1900'
        option src_dport '1900'
        option dest_port '1900'

I also tried the line

       option src_dip '239.255.255.250'

But none of this seems to have any effect. The mroutes are reported as above. What am I missing? Do I need a SNAT option instead?

config rule
	option name 'ISO-FORWARD-ACCEPT-SSDP'
	option family 'ipv4'
	option proto 'udp'
	option src 'iso'
	option dest 'lan'
	option dest_ip '239.255.255.250'
	option dest_port '1900'
	option target 'ACCEPT'

config rule
	option name 'LAN-FORWARD-ACCEPT-SSDP'
	option family 'ipv4'
	option proto 'udp'
	option src 'lan'
	option dest 'iso'
	option dest_ip '239.255.255.250'
	option dest_port '1900'
	option target 'ACCEPT'

If you have the following in your firewall config,

config forwarding
	option src 'lan'
	option dest 'iso'

then you can remove the 'LAN-FORWARD-ACCEPT-SSDP' rule. (or vice versa)
You will also need to create rules that allow access to minidlna (after the ssdp/dlna discovery)
For example, Plex uses TCP port 32469.
But for minidlna I'm not sure. Maybe 8200 ?

config rule
	option name 'ISO-FORWARD-ACCEPT-MINIDLNA'
	option family 'ipv4'
	option proto 'tcp'
	option src 'iso'
	option dest 'lan'
	option dest_ip '10.238.134.200'
	option dest_port '8200'
	option target 'ACCEPT'
	
config rule
	option name 'LAN-FORWARD-ACCEPT-MINIDLNA'
	option family 'ipv4'
	option proto 'tcp'
	option src 'lan'
	option dest 'iso'
	option src_ip '10.238.134.200'
	option src_port '8200'
	option target 'ACCEPT'

If you have the following in your firewall config,

config forwarding
	option src 'lan'
	option dest 'iso'

then you can remove the 'LAN-FORWARD-ACCEPT-MINIDLNA' rule. (or vice versa)

@ shm0, thank you - I appreciate your help. Unfortunately this doesn't work - I actually tried these rules before (the discovery ones - I figured I should get that to work before I worry about the stream), and thought they must be wrong because I don't discover anything and the server machine itself doesn't see traffic resulting from an SSDP request from ISO.

For sanity, I also just tried the config forwarding options and got the same outcome.

So - something else must be blocking (obviously). The default firewall settings include some rules for allowing certain INPUT and FORWARD from the WAN, and I have those disabled - but I turned them back on again just to rule that out.

I do notice packets sent to igmp.mcast.net with TTL 1:

17:35:58.105032 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    10.238.135.120 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_in { }]

in spite of my firewall rule

iptables -t mangle -A PREROUTING -i wlan0-1 -d igmp.mcast.net -j TTL --ttl-inc 1

Can this be the issue?

That's the rigging I referenced. I'm not sure how others mangled the packets to produce a TTL of 2 - so it will traverse a router one hop.

1 Like

Okay then - that's my task... figure out how to make the mangling actually work.

1 Like

Although - if I do the same trace with a host on br-lan, the TTL is also 1, and the discovery happens immediately:

tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes                                                                                                                                                           
18:00:55.139396 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))                                                                                                                                      
    10.238.134.201.lan > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]                                                                                                                                            
18:00:55.182432 IP (tos 0x0, ttl 4, id 18050, offset 0, flags [DF], proto UDP (17), length 155)                                                                                                                                                
    10.238.134.201.lan.54727 > 239.255.255.250.1900: [udp sum ok] UDP, length 127                                                                                                                                                                       
18:00:55.183556 IP (tos 0x0, ttl 64, id 21242, offset 0, flags [DF], proto UDP (17), length 389)                                                                                                                                               
    10.238.134.200.lan.1900 > 10.238.134.201.lan.54727: [udp sum ok] UDP, length 361                                                                                                                                     

Puzzling!

iptables -t mangle -A PREROUTING -i wlan0-1 -d 239.255.255.250 -j TTL --ttl-inc 1

iptables -t mangle -A PREROUTING -i br-lan -d 239.255.255.250 -j TTL --ttl-inc 1

Yes - I already have those:

iptables -t mangle -A PREROUTING -i br-lan -d 239.255.255.250 -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i wlan0-1 -d 239.255.255.250 -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i wlan0-1 -d igmp.mcast.net -j TTL --ttl-inc 1

I also rebooted and observed:

  • TTL remains stuck at 1 for 10.238.135.x -> igmp.mcast.net
  • Even if I comment out the above rules and restart the firewall, the TTL for dest 239.255.255.250 remains at 4.

The MANGLE table in IPTABLES appears to be set correctly:

iptables --table mangle --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
TTL        all  --  anywhere             239.255.255.250      TTL increment by 1
TTL        all  --  anywhere             239.255.255.250      TTL increment by 1
TTL        all  --  anywhere             igmp.mcast.net       TTL increment by 1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
TCPMSS     tcp  --  anywhere             anywhere             tcp flags:SYN,RST/SYN /* !fw3: Zone wan MTU fixing */ TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

So it seems like I'm not hitting these rules. If I were, the TTL for 239.255.255.250 should be incremented too, from 4 to 5.

TTL of 4 should be more than enough.
Also, there is no need to increase the TTL of igmp.mcast.net (224.0.0.22) by 1.

I found this, it is an old post but maybe it is still relevant:
https://sourceforge.net/p/minidlna/support-requests/13/

And the problem was that original minissdp.c file didn't like receiving packets from other subnet, different to the one minidlna is bound to.

For testing, you can also try to allow forwarding between the zones:

config forwarding
	option src 'lan'
	option dest 'iso'

config forwarding
	option src 'iso'
	option dest 'lan'

Then you can also remove/disable the rules above, because "all" traffic will be forwarded between the zones. If it works, then there is an issue with the firewall rules.
If not, there is a problem with the smcroute setup, minidlna (see link above) or something else.

1 Like

@shm0, it's all good now! I had to change

config rule
	option name 'LAN-FORWARD-ACCEPT-SSDP'
	option family 'ipv4'
	option proto 'udp'
	option src 'lan'
	option dest 'iso'
	option dest_ip '239.255.255.250'
	option dest_port '1900' <-- Should be option src_port '1900'
	option target 'ACCEPT'

and poof, everything started to flow. I was encouraged by your sleuthing of minissdp.c and looked into that, but the relevant lines of code are inside the #else clause of an #ifdef __linux__ and in my case minidlna is hosted on Arch linux. So I looked again at the firewall rules and made that small change.

Incidentally, the discovery rules (i.e. the two udp port 1900 ones) are not sufficient to complete the discovery from the client's perspective. I also needed the port 8200 rules in place - it was all or nothing.

You helped me tremendously. Thank you so much!

I'm glad you got it working.

Interesting that it works now with dest_port switched out for src_port.
All info I can find is that SSDP/DLNA is send to 239.255.255.250:1900 and that the source port can vary.
:thinking:

I didn't report things quite accurately. From what I observe, the server only sends to 239.255.255.253 when minidlna starts up (or maybe after a router reboot). Nobody in the ISO zone needs to listen for that. The SSDP request/response is over HTTP, and the server's response (HTTP 200 OK) is to the IP address of the client, i.e. not 239.255.255.250:

Internet Protocol Version 4, Src: 10.238.134.200, Dst: 10.238.135.120
User Datagram Protocol, Src Port: 1900, Dst Port: 37887
Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    CACHE-CONTROL: max-age=180010\r\n
    DATE: Tue, 24 Dec 2019 23:09:36 GMT\r\n
    ST: urn:schemas-upnp-org:device:MediaServer:1\r\n
    USN: uuid:4d696e69-444c-164e-9d41-0024e8da9707::urn:schemas-upnp-org:device:MediaServer:1\r\n
    EXT:\r\n
    SERVER: 4.17.1-1-ARCH DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.2.1\r\n
    LOCATION: http://10.238.134.200:8200/rootDesc.xml\r\n

So the sequence looks like:

19:25:08.994840 IP (tos 0x0, ttl 4, id 40949, offset 0, flags [DF], proto UDP (17), length 155)
    10.238.135.120.46347 > 239.255.255.250.1900: [udp sum ok] UDP, length 127
19:25:08.997514 IP (tos 0x0, ttl 63, id 11527, offset 0, flags [DF], proto UDP (17), length 389)
    10.238.134.200.1900 > 10.238.135.120.46347: [udp sum ok] UDP, length 361
19:25:09.001874 IP (tos 0x0, ttl 64, id 40015, offset 0, flags [DF], proto TCP (6), length 60)
    10.238.135.120.37144 > 10.238.134.200.8200: Flags [S], cksum 0xcc1c (correct), seq 1126491101, win 65535, options [mss 1460,sackOK,TS val 1146770 ecr 0,nop,wscale 8], length 0
19:25:09.002271 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    l10.238.134.200.8200 > 10.238.135.120.37144: Flags [S.], cksum 0x990d (correct), seq 1282679328, ack 1126491102, win 65160, options [mss 1460,sackOK,TS val 4115517587 ecr 1146770,nop,wscale 7], length 0

And so the rule modification I mentioned is extraneous and I shouldn't have said that's what got things working. As it turns out we don't need the LAN-FORWARD-ACCEPT-SSDP rule at all. This is what I have:

config rule
        option name 'ISO-FORWARD-REQUEST-SSDP'
        option family 'ipv4'
        option proto 'udp'
        option src 'iso'                         
        option dest 'lan'   
        option dest_ip '239.255.255.250'
        option dest_port '1900'
        option target 'ACCEPT'
                                       
config rule                    
        option name 'LAN-FORWARD-RESPOND-SSDP'
        option family 'ipv4'
        option proto 'udp'
        option src 'lan'                         
        option dest 'iso'   
        option src_ip '10.238.134.200'
        option src_port '1900'
        option target 'ACCEPT'
                                      
#config rule                  
#       option name 'LAN-FORWARD-ACCEPT-SSDP'
#       option family 'ipv4'
#       option proto 'udp'
#       option src 'lan'
#       option dest 'iso'
#       option dest_ip '239.255.255.250'
#       option dest_port '1900'
#       option target 'ACCEPT'

config rule
        option name 'ISO-FORWARD-ACCEPT-MINIDLNA'
        option family 'ipv4'
        option proto 'tcp'
        option src 'iso'
        option dest 'lan'
        option dest_ip '10.238.134.200'
        option dest_port '8200'
        option target 'ACCEPT'

config rule
        option name 'LAN-FORWARD-ACCEPT-MINIDLNA'
        option family 'ipv4'
        option proto 'tcp'
        option src 'lan'
        option dest 'iso'
        option src_ip '10.238.134.200'
        option src_port '8200'
        option target 'ACCEPT'

Sorry for the confusion.

I think, minidlna is sending on a specific interval, announcing itself (NOTIFY).
Clients can start a manual discover by sending
a request to address 239.255.255.250:1900 (M-SEARCH).
Responses to such requests are sent to the originating IP address (via unicast).
Sorry I missed this aspect.

You maybe also don't need those two lines:

mgroup from wlan0-1 group 239.255.255.250
mgroup from br-lan group 239.255.255.250

Those lines will make the router join those multicast groups.
I think this is only useful with igmp snooping.

//edit
Those lines are needed.

//edit2
You can actually use IPSets to dynamically allow the unicast answer.
Something like:

config ipset
	option name 'ssdp'
	option storage 'hash'
	option match 'dest_ip dest_port'
	option timeout '4'	
 
config rule
	option name 'ISO-FORWARD-IPSET-ADD-SSDP'
	option family 'ipv4'
	option proto 'udp'
	option src 'iso'                         
	option dest 'lan'   
	option dest_ip '239.255.255.250'
	option dest_port '1900'
	option extra '-j SET --add-set ssdp src,src --exist'
	option target 'ACCEPT'
 
config rule
	option name 'LAN-FORWARD-ACCEPT-SSDP-RESPONSE'
	option family 'ipv4'
	option proto 'udp'
	option src 'lan'
	option dest 'iso'
	option ipset 'ssdp dest'
	option target 'ACCEPT'

config rule
	option name 'ISO-FORWARD-ACCEPT-SSDP-SEARCH/NOTIFY'
	option family 'ipv4'
	option proto 'udp'
	option src 'iso'                         
	option dest 'lan'   
	option dest_ip '239.255.255.250'
	option dest_port '1900'
	option target 'ACCEPT'

config rule
	option name 'LAN-FORWARD-ACCEPT-SSDP-SEARCH/NOTIFY'
	option family 'ipv4'
	option proto 'udp'
	option src 'lan'                         
	option dest 'iso'   
	option dest_ip '239.255.255.250'
	option dest_port '1900'
	option target 'ACCEPT'                                                               

config rule
	option name 'ISO-FORWARD-ACCEPT-MINIDLNA'
	option family 'ipv4'
	option proto 'tcp'
	option src 'iso'
	option dest 'lan'
	option dest_ip '10.238.134.200'
	option dest_port '8200'
	option target 'ACCEPT'

config rule
	option name 'LAN-FORWARD-ACCEPT-MINIDLNA'
	option family 'ipv4'
	option proto 'tcp'
	option src 'lan'
	option dest 'iso'
	option src_ip '10.238.134.200'
	option src_port '8200'
	option target 'ACCEPT'

Creates an IPSet (holds IP and Port, entries expire after 4 seconds)
The first rule adds the source IP:Port from clients of the iso zone to the set.
(from the ssdp search/request)
The second rule allows clients from the lan zone to answer the ssdp request via unicast, this should work because the unicast response is send to the source ip+port, which are stored in the IPSet. This will allow all servers from the lan zone to answer.
You can add src_ip '10.238.134.200' to only allow answers from your server.
The third and fourth rule allow basic notify/m-search forwarding.
The last rules allow access to minidlna itself.
You can also use the limit option to prevent multicast spam.

I can't test this atm but it should work :sweat_smile:

I don't seem to need the mgroup/mroute from br-lan -> wlan0-1 - minidlna creates (or joins) the group, and the wlan0-1 > br-lan group/route propagates the SSDP request from the ISO zone to the LAN zone. At least it's working that way :thinking:

The response is directed via unicast and the forwarding rule takes care of that.

I like the idea of using an IPSet - I had not known about that before. But I'm wondering if it's overkill to build a hash table, given that I only have 2 minidlna clients on the ISO network: a Roku connected to an old TV, and a smart TV. But maybe as you suggested I can limit some of the spam, and filter the answers to cut down the amount of traffic. I also have some other devices on the ISO network and all together, they are pretty chatty even when (supposedly) doing nothing.

Will try the IPSets anyway, just to see how it works, but not for a few days, until nobody is using the internet.