iptables -t raw -A PREROUTING -i eth0.2 -d 224.0.0.0/4 -m ttl --ttl-lt 7 -j ACCEPT
I havent posted his in my thread about vlans and multicast routing.
I asked a question about that weird firewall log.
The problem was i didn't have specified the protocol (udp) in my ttl increase rule.
If you dont specify protocol udp here, also the ttl of the igmp packets gets increased.
I guess that is not wanted x)
I asked this because you have multiple processes involved. Simply rebooting after making such changes would be better. I'll be honest, I'm not willing to change working configs to find Easter-Egg-like bugs. I would reboot after making such change to avoid quirks.
relevant route added to the config (again in /etc/config/network):
config route
option interface 'IPTV_WAN'
option target '213.75.112.0/21'
option gateway '10.202.96.1' <- this changes per geo location you are situated, just check what gateway you get on your iptv vlan, and adjust accordingly. apparently the IPTV dhcp server can dynamically push this route to you as well, but i never bothered to figure out how to set that up.
/etc/config/igmpproxy setup
config igmpproxy
option quickleave 1
# option verbose [0-2]
config phyint IPTV_WAN
option network IPTV_WAN
option direction upstream
list altnet 192.168.1.0/24 <- your internal network
list altnet 213.75.0.0/16 <- this network needs to be routed over vlan 4
config phyint lan
option network lan
option direction downstream
config zone
option name 'IPTV_WAN'
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option network 'IPTV_WAN'
option masq '1'
config forwarding
option dest 'IPTV_WAN'
option src 'lan'
config rule
option name 'Allow-IGMP-Proxy'
option proto 'udp'
option family 'ipv4'
option target 'ACCEPT'
option dest_ip '224.0.0.0/4'
option dest 'lan'
option src 'IPTV_WAN'
errors in the log:
just the occasional error, but no flooding. TV is used daily
logread | grep igmp
Mon Mar 19 06:47:52 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.92.109
Mon Mar 19 06:47:52 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.92.109
Mon Mar 19 11:57:18 2018 user.warn igmpproxy[17518]: MRT_DEL_MFC; Errno(2): No such file or directory
Mon Mar 19 18:24:48 2018 user.warn igmpproxy[17518]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Mar 20 17:28:08 2018 user.warn igmpproxy[17518]: MRT_DEL_MFC; Errno(2): No such file or directory
Thu Mar 22 13:06:17 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.48.125
Thu Mar 22 13:07:41 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.48.125
Thu Mar 22 21:26:53 2018 user.warn igmpproxy[17518]: MRT_DEL_MFC; Errno(2): No such file or directory
Fri Mar 23 08:54:13 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.138.97
Fri Mar 23 08:54:13 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.138.97
Fri Mar 23 08:54:13 2018 user.warn igmpproxy[17518]: No interfaces found for source 169.254.138.97
Now I am confused. I've read multiple guides, including the OpenWRT wiki and they all use a FORWARD rule, the same thing as you are using and the previous version I was using. However, @lleachii explicitly states this should be an INPUT rule since the igmpproxy daemon is running on the router itself, which makes sense. Did you follow one of those guides that I read as well and hence you are using a FORWARD rule? Or do you have a particular reason for using this?
Any particular reason for defining this static route? With the way your firewall is configured this shouldn't be required, correct?
Getting those as well. Really annoying for my OCD, but they seem harmless.
Adding the following line to your upstream igmpproxy configuration should fix these errors: list altnet 169.254.0.0/16
Make sure you run /etc/init.d/igmpproxy restart to apply the changes
mroute: I had to install the full IP package to get it working. have it working now. updated my previous post.
169.x.x.x: i can't be bothered with this they are seldom and it's cosmetic
firewall: simply using this because it works. has worked fine for the last 3 years, so why change?
Consider changing the input rule to REJECT by the way. With your current configuration, you are ACCEPTing any packets coming from the IPTV_WAN interface to your router. While probably fine, you are relying on your ISP having everything in order. I prefer to only let packets reach my router that I want it to receive via INPUT rules.
I noticed a MAJOR difference in one of these configs that could make a FORWARD rule work:
This route COULD make a FORWARD rule work...but you can't multicast on any other LAN....It also appears this is an outbound route, not inbound...so I'm lost...
My issue was that I was having stutters throughout my IPTV experience for the higher bitrate channels. Those seem to be fixed by using an INPUT rule instead of the earlier FORWARD rule, but require my to use a separate iptv firewall zone, since for some reason the iptv interface needs to have the exact same name as the rule it is included in. This is probably a bug, which I'll try to pinpoint exactly on monday when no other people are actively using iptv.
For now I'm just trying to gain a deeper understanding about all of this just for the sake of broadening my knowledge. As @lleachii just mentioned the static route that you have defined probably made your FORWARD rule without any issues, and why I (without that static route) had to switch to the INPUT rule.
Now there's a good chance I'll sound extremely dumb, but why is IGMPPROXY actually needed? Wouldn't it be possible to simply route to multicast traffic from to ISP to the LAN? And things like subscribe messages from LAN to the ISP?
Multicast is only local, as the IPs used as destinations are not routed...therefore, if the devices are not directly connected, they need IGMP requests to be proxied...
Let me tell you a secret...your ISP's router likely had an IGMP proxy running in the background as well.
Correct, 224.0.0.0/4 is not a normal IP range. These IPs are reserved on the Internet and in software for use as various destination IPs in multicasting. The particular IP usually refers to a subscription sent in an IP/IGMP packet upstream, and the service is delivered on the corresponding DST IP for receiving downstream, whose IP is also within 224.0.0.0/4, and protocol is IP/UDP.
Another random thought: What would happen if I simply bridge the vlan4 interface with the rest of my LAN? Would that give me working iptv without igmpproxy?
I don't think this is actually a bug. More like intended behavior.
When a client sends a packet to a specific multicast address and someone uses something like this rule:
All packets going to this address will get their ttl increases by 1.
The IGMP packets and the multicast packets.
But this is wrong?
Only the udp multicast packets need their ttl increased.
In this case 239.255.255.250 (SSDP) this rule should not be needed because ssdp should use default ttl of 4 or 5, but im not quite sure and some clients are buggy so i use it anyway.
Yes i know your rule does something different but i i saw your rule with the ttl option and it came to my mind.
Actually i dont think this is correct?
IGMP packets only need to reach the interface(s) of the router.
The router then will take care of the routing.
According to the multicast routing setup and igmp memberships on the interfaces.
So OP only needs two rules.
One to allow igmp input to the router on all interfaces he wants igmp/multicast to work.
Second allow forward of the multicast packets (224.0.0.0/4)
But as i said in the last thread the init script of igmpproxy will create the rules accordingly.
Good spot! Mind sharing your firewall config as well? Are you getting any weird igmpproxy messages in your logs?