The router will take note of it and now has the info in his igmp membership table.Į.g. Host Y on network A wants to receive a multicast stream from network B. Lets call them interface/network A and interface/network B. The only thing that needs to be "proxified" are the multicast streams. The router needs to know the igmp memberships on both sides. usr/sbin/iptables -t mangle -A PREROUTING -p udp -d 224.0.0.0/4 -i iptv -j TTL -ttl-inc 1 If someone could explain this to me please?Īctually i would try to remove option classlessroute, defaultroute, peerdns and gateway and then check what the the isp dhcp hands out?Īnd let the igmp proxy init script create the firewall rules. Is this even needed? Why doesn't the isp dhcp server push the routes? (Copy and pasted from OP x) ) config interface 'iptv'
IP LOCATOR 239.255.255.250 HOW TO
Option vid '6' // may differ (should be vlan 6?)Ĭreate the the following new vlan config switch_vlanĬaution: only alter the switch config if you know how to recover you device in the case you lose access. (i guess ops device supports swconfig) config switch_vlan Search for your wan interface in /etc/config/network Yes i know your rule does something different but i i saw your rule with the ttl option and it came to my mind. 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. Only the udp multicast packets need their ttl increased.
The IGMP packets and the multicast packets. Iptables -t mangle -A PREROUTING -d 239.255.255.250 -i br-lan -j TTL -ttl-inc 1Īll packets going to this address will get their ttl increases by 1. When a client sends a packet to a specific multicast address and someone uses something like this rule: This is done after the packet is received on the router, though. It may be that igmpproxy adds TTL I haven’t looked at the code. Especially since only multicast traffic would reach me anyway. I noticed that I omitted UDP but I haven’t experienced any issues. This rule states that any packet with a multicast DST - possessing a ttl of 6 or less should be ACCEPTED.
What you describe would be a bug, have you reported this? 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? As 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. This is probably a bug, which I'll try to pinpoint exactly on monday when no other people are actively using iptv.įor now I'm just trying to gain a deeper understanding about all of this just for the sake of broadening my knowledge. 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. My issue was that I was having stutters throughout my IPTV experience for the higher bitrate channels.
0 kommentar(er)
