I'mreally confused right now. Could you please tell me exactly what settings are needed from the settings I posted above ?
Of what I understood IGMPProxy wasn't even needed ?
here I'll start with a simple script you can enable the things. I think @lleachii is suggesting that igmpproxy also handles MLD methods in ipv6 so we just need to set up forwarding, routing, and etc.
#first load your sysctls to make sure they're set
sysctl -p
# set up a static multicast route
ip -6 route add multicast ff::/8 dev br-lan
# add a braindead firewall rule
ip6tables -A forwarding_rule -p udp --dst ff::/8 -j ACCEPT
EDIT sorry I wrote ALLOW where it should be ACCEPT
1 Like
I only see that you posted enabling mc_forward.
You also need:
- a route
- a firewall rule
Simple - you didn't post those yet, unless I've mistaken.
Correct. Your issue with the IPv4 multicast was likely only the bad sysctrl file you refused to reset for over 100 posts.
You think slightly off...why is multicast so difficult to grasp? It was for me at 1st too...
Just try the route and firewall first. Then proceed. Stop making it so complex...that was my downfall at first!
without igmpproxy running in the ipv4 case the igmp responses sent by the VLC listener do not get mirrored to WAN (this is the "proxy" in "igmpproxy") and without that the switch will not open the floodgates on the port and so the UDP will not flow to the WAN of the router. So it wasn't sufficient to just enable mc_forwarding without also having igmpproxy installed and running.
Furthermore, because of the way the kernel works, without a multicast routing daemon holding open the routes via some netlink socket the multicast routes do not persist (I'm told by googling, haven't tested). So without igmpproxy running you can't just add the routes...
I suspect it's the same in ipv6, you need some software sitting on the router listening on LAN for MLD packets, and then mirroring them to WAN so the smart switch will open up the floodgates, and this software also needs to hold the routes open.
I didn't realize you were still under this impression. @mickey84, I'll let @dlakelan assist from here.
Yes I am. If the OpenWrt firewall allows IGMP packets to go from LAN to WAN out of the box without igmpproxy running I consider this a serious security bug.
Well in the IPv4 case, I just set up the sys config.
And it didn't work. When setting up those other settings it works fine. So I don't know exactly whats really needed.
So for IPv6:
I set up this net.ipv6.conf.all.mc_forwarding = 1
I start a stream via VLC with rtp://@ff08:
123
And its not working.
Sir, that's why there's a zone section in the software.
Making the firewall rules as I suggested above does that.
There's nothing magical.
Also, again, no PIM, so IGMP packets aren't going anywhere in WAN.
Let's try this set of steps:
- make sure igmpproxy and mld6 are not running
- Run my script from above to enable the sysctl, route, and firewall
- Turn on the VLC broadcast on
ff08::abc:123 - Turn on the VLC receiver on LAN for that same address
Come back and tell us what happens at this point.
Then try
- turn off the VLC receiver
- start up mld6
- turn on the VLC receiver
and let us know what happens at this point
1 Like
@lleachii, if you have the time and the hardware for testing I invite you to set up a test bed. With igmpproxy not running on the router, wireshark the WAN, and then have a VLC on the LAN start up listening for a given ipv4 stream.
Now stop VLC, start up igmpproxy and continue to wireshark the lan while re-starting the VLC listener. Do IGMP packets appear on the WAN under the second conditions and not on the first? I will bet they do, everything I've read about IGMPproxy is that it proxies IGMP packets from its "downstream" interfaces to its "upstream" interfaces. That's almost all it does.
I'd do this myself but I don't have the hardware to test it on.
EDIT:
Actually thinking further, igmp is a separate protocol it's not a ipv4 or ipv6 packet, and so it doesn't go through the firewall, and furthermore, it has no notion of routes. so without the igmpproxy running it's definitely not going to come from LAN and arrive on WAN. The question is whether with igmpproxy running it will do this, and I am betting yes.
root@OpenWrt:~# cat /etc/sysctl.conf
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
net.ipv4.conf.all.mc_forwarding = 1
net.ipv6.conf.all.mc_forwarding = 1
root@OpenWrt:~# ip6tables -A forwarding_rule -p udp --dst ff::/8 -j ACCEPT
root@OpenWrt:~# ip -6 route add multicast ff::/8 dev br-lan
ip: RTNETLINK answers: File exists
Was that correct set up ?
are you running mrd6 ? that's the only reason I could imagine the route would answer that it already has this route installed.
stop mrd6 first, and then run those same commands
router is freshly reset. I only put in thos 3 commands you mentioned.
mrd6 is not installed.
yes but is mrd6 (or igmpproxy) running? It might be set to start on startup? You need to go to startup page in Luci and stop both of those things to be sure
Also I note on the wiki page for mrd6 "The project is unsupported since 2013. The author states as a reason that native multicast forwarding support is available in Linux since 2005 and pim6sd could be used to manage it.[1]"
so it might be best to uninstall mrd6 entirely
Also, MLD packets are ipv6 packets (icmpv6 to be exact) and so they do go through the firewall and do have routes associated. This is different from igmp.
can you verify:
- you have uninstalled mrd6
- restart router
- run my given commands
- run
ip -6 routeand paste the results here (edit: route, not mroute) - the VLC receiver does not receive any stream
1 Like
no mrd6 installed
made a reboot
setup sysconfig
typed this:`root@OpenWrt:~# ip6tables -A forwarding_rule -p udp --dst ff::/8 -j ACCEPT
root@OpenWrt:~# ip -6 route add multicast ff::/8 dev br-lan
root@OpenWrt:~#
root@OpenWrt:~# ip -6 route add multicast ff::/8 dev br-lan
ip: RTNETLINK answers: File exists
root@OpenWrt:~# ip -6 mroute
BusyBox v1.28.3 () multi-call binary.
Usage: ip [OPTIONS] address|route|link|neigh|rule [COMMAND]
`
Yes I made a mistake, please do
ip -6 route show
other than that all looks fine so far. Does the VLC listener get a stream (I suspect not)
root@OpenWrt:~# ip -6 route show
default from fd91:dab6:a2b2:1::/64 via fe80::964a:cff:fe88:84f5 dev eth0 metric 512
::/8 dev br-lan metric 1024
fd91:dab6:a2b2:1::/64 dev eth0 metric 256
fd91:dab6:a2b2:1::/64 via fe80::964a:cff:fe88:84f5 dev eth0 metric 512
fdd0:14c6:6082::/64 dev br-lan metric 1024
unreachable fdd0:14c6:6082::/48 dev lo metric 2147483647 error -148
fe80::/64 dev eth1 metric 256
fe80::/64 dev br-lan metric 256
fe80::/64 dev eth0 metric 256
unreachable default dev lo metric -1 error -128
ff00::/8 dev br-lan metric 256
ff00::/8 dev eth1 metric 256
ff00::/8 dev eth0 metric 256
unreachable default dev lo metric -1 error -128
root@OpenWrt:~#
ok, with all that in place, can you set up the VLC sender and receiver and verify whether receiver gets any stream?
also I think the address is wrong. I found several possibilities to run and receive a VLC stream.
could you please give me your recommendation ?
I tried [ff15::1]
and I try to open this with rtp://[ff15::1]
My recommendation was above a ways back:
[ff08::abc:123]