Igmpproxy Turris 6.0

Software SW help
#1

My migration to OS 6.0 was smoothless. The only thing i noticed thats make me go back to 5 is that igmpproxy seems not functional and thus keeps me from using my TV. It is started but from the logs it doesnt see any request by clients. The config is the same as presented here [OpenWrt Wiki] IPTV / UDP multicast. Don’t know where to start debug this problem.

config igmpproxy
        option quickleave 1
#       option verbose 3
config phyint wan
        option network wan
        option zone wan
        option direction upstream
        list altnet 0.0.0.0/0

config phyint lan
        option network lan
        option zone lan
        option direction downstream
3 Likes
#2

I have the same problem after upgrading to Turris OS 6.0.1. Igmpproxy is not working as it did in version 5.4.4. I haven’t changed a single thing in the configuration.
I get all the multicast addresses with “Iif: unresolved State: unresolved” from the command “ip mroute”. Before the upgrade, the same command returned “Iif: eth2.2 Oifs: br-lan State: resolved”. So now iptv is not working any more.

#3

Hi, I did not update yet to 6.x but as I had issue with igmpproxy in the past, I switched to udpxy which converts the multicast traffic to unicast. It needs very little configuration but your stream URLs will need to be updated. It may be worth testing if you don’t find the issue with igmpproxy.

#4

I had the same issue with igmpproxy in Turris OS 6. Downgraded to 5.4.4 today and here igmpproxy works fine with the config @Florian_Fra uses (after activating IGMP snooping).

One odd thing I noticed in Turris OS 6 was that UDP multicast/IPTV worked over WLAN but not over LAN. I have no idea why, though.

#5

i tried debugging a little further. What i found out:

  • Firewall setting (iptables -L -nv) are the same in 5.4.4 an 6.0.1 in Respect of igmp and are correctly added by the igmpproxy script
  • i changed igmpproxy in /usr/sbin to the version of 5.4.4: no change
  • sysctl is the same across both version

What is really different is, that the br-lan interface somehow doesnt see any igmp traffic

Here is version 6.0 (onion is name of turrisrouter):

root@onion:~# tcpdump -i br-lan igmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
22:50:36.475235 IP onion > all-systems.mcast.net: igmp query v2
22:50:37.905161 IP onion > igmp.mcast.net: igmp v2 report igmp.mcast.net
22:50:38.545158 IP onion > 224.0.0.251: igmp v2 report 224.0.0.251
22:50:40.065155 IP onion > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
22:50:46.071855 IP onion > all-systems.mcast.net: igmp query v2

With version 5.4.4, there is traffic from various sources:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
22:56:44.787820 IP onion > all-systems.mcast.net: igmp query v2
22:56:47.352214 IP fmf-Desktop.fmf.netz > 224.0.0.252: igmp v2 report 224.0.0.252
22:56:49.198611 IP onion > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
22:56:49.541031 IP TV.fmf.netz > 239.255.255.250: igmp v2 report 239.255.255.250
22:56:51.357511 IP fmf-Desktop.fmf.netz > 224.0.0.251: igmp v2 report 224.0.0.251
22:56:52.478613 IP onion > igmp.mcast.net: igmp v2 report igmp.mcast.net
22:56:52.796731 IP Superconnect.fmf.netz > 239.255.255.250: igmp v2 report 239.255.255.250
22:56:53.860972 IP fmf-Desktop.fmf.netz > 239.255.255.250: igmp v2 report 239.255.255.250

But i have no clue, why local igmp traffic doesnt show in tcpdump or what is blocking it. By the firewall rules it shouldn’t be

#7

Have you also tried to set option igmp_snooping '1' for br_lan in /etc/config/network ?

Or additionally specify igmp version in /etc/sysctl.conf

net.ipv4.conf.all.force_igmp_version=2
#8

igmp_snooping was already active. the sysctl command didn’t change anything.

#9

Since this seems to be broken based on your reports and I am not using it.

Newer OpenWrt versions are using igmpproxy version 0.3, let’s update it to this version in OpenWrt 21.02 (it’s using 0.2.1 and will be updated in Turris OS 6.0.2) and once you let me know if it helps, I will upstream it.

#10

Hi, just updated to TOS 6.0.1 which partially broke my IPTV streaming to Arris 4302 (ISP Slovanet). The problem is, that after this upgrade it takes a long time (5-10sec) between channel switching. Also on startup it takes this long to image come up. Before upgrade channel switching and startup was instant. Also tried factory reset Arris with no change.

/etc/config/network

...
config device 'br_lan'
	option name 'br-lan'
	option bridge_empty '1'
	option igmp_snooping '1'
	list ports 'lan0'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	option type 'bridge'

/etc/config/firewall

...
config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'
...

/etc/config/igmpproxy

config igmpproxy
	option quickleave 1
#	option verbose [0-3](none, minimal[default], more, maximum)

config phyint
	option network wan
	option zone wan
	option direction upstream
	list altnet 0.0.0.0/0

config phyint
	option network lan
	option zone lan
	option direction downstream

This I found in logs:

Nov  5 20:55:39 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96
Nov  5 20:55:40 turris igmpproxy[4530]: No interfaces found for source 169.254.138.96

In sysctl.conf I have:
net.ipv4.conf.all.force_igmp_version=2

Thank you for your help

#11

I had the same problem.
As a workaround I installed and enabled udpxy and disabled igmpproxy.
I then manually activated/added the IGMP rules in the firewall:

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'
	option enabled '1'

config rule
	option name 'Allow-Multicast'
	option src 'wan'
	option proto 'udp'
	option family 'ipv4'
	option dest_ip '224.0.0.0/4'
	option target 'ACCEPT'
	option enabled '1'

I was lucky, since I use with “IPTV Simple Client” on KODI. It has is an option to add the IP address of your udpxy server, and that’s all it needs.

Multicast IGMP reports missing
#12

Still does not work after updating to 6.0.2

tcpdump -i br-lan igmp

Still does not see any packages by other sources than router itself.

#13

iptables -L -nv counts igmp packets, so they arrive at the network interface, but somehow they get filtered after passing iptables so tcpdump -i br-lan igmp doesnt end up seeing them

#14

Related: Multicast IGMP reports missing. My IPTV setup is also broken as igmpproxy cannot see any IGMP packet coming from my IPTV device. It worked fine with <6.0.

#15

Shall we open an official support request about this? Since the problem seems to be that IGMP traffic is not visible in the interface this is no longer an igmpproxy issue.

#16

I would be glad if you did

#17

I’ve just mailed tech.support@turris.cz pointing them to here. :slight_smile:

#18

Nobody has replied :frowning:

#19

Any news about the annoying IPTV/multicast feature that does not work?

Thanx

#20

+1 I have the same problem with 6.x and IPTV reverted to 5.x until resolved. Let me know if I can help with any details.

#21

So I have used a Mikrotik RB750Gr3 router with two results:

1. OpenWRT 22.03.2 , igmpproxy 0.4: it was not working. I got the same odd results as with TurrisOS 6.0.4 and its igmpproxy 0.3. Just note, that 22.03.2 doesn’t use iptables anymore. Instead it uses nft tables.

2. OpenWRT 21.02.5 , igmpproxy 0.2.1: worked like a charm.

May it be a problem with the integration of igmpproxy and the used firewall on the Turris?