I did. I even mentioned that pppoe-wan was incorrect.
That's what I had initially, until you mentioned the following:
Where you implied the igmpproxy should contain a zone.
Yes, wan is a different VLAN. I will use a separate iptv zone then. I was just wondering whether it would be possible to use a single wan zone for both wan and iptv. Obviously I was using this setup earlier as you mentioned, however, that was using the broken FORWARD rule. Going back to this rule fixes this issue with the current configuration as well, however it reintroduces the stuttering issue.
No...I was just under the impression that you hadn't named the zone and interface identically, my apologies. In addition, I believe that was regarding the following:
Yes, as this is what I understood I was explaining to you:
I assume it does need to be edited....Interesting...I've never looked at that page, since I realized OpenWRT had igmpproxy from opkg.
config igmpproxy
option quickleave 0
config phyint
option network iptv
option direction upstream
list altnet 0.0.0.0/0
config phyint
option network lan
option direction downstream
In either configuration this should be correct, since this references the interface, which is the same for both setups.
Changing the src in both the IGMP and UDP INPUT rules from iptv to wan
moving the iptv interface from iptv zone to wan zone (both zones have the same general setttings)
results in iptv stopping to work. Changing these few things back to the dedicated iptv zone OR changing the UDP from INPUT to FORWARD and iptv starts working again.
So it seems igmpproxy isn't properly binding to the iptv interface if the zone isn't called exactly the same, since it requires a FORWARD rule to lan, which probably means igmpproxy is listening on LAN.
To test my hypothesis I went to the working setup with the iptv zone. And now all I did was rename the iptv zone to test. And iptv stopped working again. I verified both firewall rules were properly updated with the new names, which they were. I also restarted igmpproxy to see if that changed anything, which it didn't. Changing the name of the zone back to iptv and it instantly came back alive. Very weird stuff happening.
I didn't edit it, since the configuration should remain the same, as the igmpproxy configuration references interfaces rather than zones, which didn't change. But I did restart igmpproxy.
My fiancee just came back home, so that is exactly what I am going to do right now (she doesn't like me messing with our iptv connection ;)) and do some additional reading over the weekend. I'll go back to debugging / tinkering on monday. I'll let you know if I manage to find anything. Thank you very much for your amazing help and patience
Not sure how to locate igmpproxy with this command:
Weird that is shows twice. Also it is listening on all IPs in this case and not restricted to a specific interface as far as I can tell. I will have a look on Monday in the non-working setup.
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.
A fiancé that can watch her TV is a happy Wife...so...what about the "stutter?"
(If it ain't broke...don't fix it.)
Also, I cannot change my IPTV zone as you describe, I stated:
I should note, I use their device to bridge to IP, but my OpenWRT is the border device for Internet, hence why I need igmpproxy.
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.
