The problem is a broken basic functionality that was present in Turris OS as in every other mass market router I’ve used in multiple European countries - until some major updates were released.
What’s really bad is that Turris is not responding to support requests about this problem. We have several comments here about this behavior.
Doubting the importance of IPTV on multicast and pointing to unicast is just material for a straw man argument.
Certain TV providers or connected devices don’t even offer that option. And even if it were available, why would anyone want to work around that defect? Before I bought my Turris Omnia, I specifically checked for multicast.
I don’t think that customers need to justify why they need multicast. That would be going beyond ridiculous.
Totally 
paddingpaddingpa
Well, this is not a feature they advertised so I am not really surprised that given their man-power issues they prioritize other development (like moving off OpenWrt21 before OpenWrt23 is released and 21 is fully EOLd). Yes, if I would use this feature I would be (mildly) unhappy myself, but even then I would accept their priorities.
It was not intended as such, this was to illustrate that multicast has historically been under-used so bugs will lurk and are likely to be introduced by new features; this is only going to change if people using multicast supply actionable bug reports to the respective developers (so linux kernel of multicast support applications).
So you asked about multicast and were explicitly told that turris would support that? Or was this just listed as part of the kernel?
We are clearly talking past each other, probably my fault. So I am going to shut up now since there is nothing productive I can add.
I went with the information and setup guide provided by my ISP that was a reseller at some point.
Honestly, that may be something a lawyer would use against a customer complaint in court.
I don’t think this line of reasoning is helping Turris, rather, it should be concerning for people who care about Turris.
…
I don’t mind debates as long as we can make our points clear, but I agree, let’s stop until one of us can contribute something to solve the actual problem.
Multicast is simply an essential feature of IP protocol set and thus of any router worth anything. It used to work with earlier version, then it regressed. With TP-Link for $25, I could excuse that, maybe. Not with this price tag.
And I don’t get the apologies of “this is just a tiny goverment organization” (no, it’s an association of corporations and has nothing to do with government at all). It has long operated on the premise of “we have too much money from the domains, so we will invest money to projects that have nothing to do with our core business - like bird and turris.” And suddenly they are understaffed… hm, ok, I can accept that, but it’s not increasing trust in upcoming projects like the 10gig router, which looked really promising. Well, since it’s overdue from the launch date, and it will be supported in the same way as this… that’s a large nope.
Just to add to that, in case whoever decides on priorities reads this: For some this might be a minor annoyance. For us this is the difference between a router and a brick with an antenna.
My ISP only offers IPTV with multicast. And so does the largest ISP in my country. And the second largest. I personally do watch television, but even if I didn’t, other people in my household do. No television is simply not an option.
I appreciate that some people might not need working multicast, and that the turris team does not currently see this as a priority. We’re just saying that this makes the turris no longer something we can use. My omnia has served me well for several years, but i had to move back to fritz.
Exactly this! My Omnia is a loved device, but since moving to a new country, it’s a brick. I can’t use it at all.
are there any solutions, even it if means downgrading turris os, or even openwrt? I tried turns os 5.x, openwrt (can’t remember which version) and nothing really worked.
not everybody agrees in this thread, about whether OpenWRT 22.03 has imgpproxy config working or not… in my view this is a key point, as going through the differences in firewall setup (between Turris Os and OpenWRT) would certainly help getting to the bottom of this problem… in the above post it was stated that OpenWRT is functional, which would be a very good baseline to work from…
From my observations, the problem lies deeper then just firewall rules. And that is probably why it hasn’t been fixed yet. It’s probably a kernel issue, it could even be related to the built in hardware.
Around the same time igmpproxy stopped working on TOS, @X-dark and myself where seeing really strange behavior with IPv6, which only stopped after disabling IGMP-snooping on the router.
Now IGMP is purely IPv4, since IPv6 has its own mechanisms to handle multicast. I find it odd and highly unlikely that an IPv4 service affects the IPv6 protocol stack on other hosts in a dual-stack network environment. But it looks as this is just the case here.
So aside from the “niche case of dying linear TV” (pun intended), this looks like a deeply rooted and disturbing problem.
The Turris Team is aware of these problems:
- IPv6 neighbor discovery breaks when igmp_snooping is enabled
- (HBL) TOS6.0 breaks IPv6 TCP connectivity
On a another note, the main reason my provider stopped reselling Turris Omnia routers, was because they started to offer 10Gbit/s and 25Gbit/s subscriptions over FTTH (notably for the same price as their 1Gbit/s subscription), and the current Omnias can’t handle that. I’m assuming they will be glad to offer them again, as soon as newer models can sustain those bandwidths.
And me too, I would appreciate it, if the discussion here would move to the “General Feedback” area, unless you have a technical contribution to help users with this issue.
Issue has been identified and “solved”
Seems to work again with latest TurrisOS version 6.4.2 release.
I’m sorry for all the fuss. It doesn’t seem to work yet. Funny thing though … When I’m connected over wifi to the router, the IPTV seems to work somehow?!
Still does NOT work for me:
igmpproxy - running
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
FIREWALL:
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'UDP-WAN-to-LAN'
option src 'wan'
option proto 'udp'
option dest 'lan'
option dest_ip '232.232.0.0/17'
option target 'ACCEPT'
option family 'ipv4'
config rule
option src 'wan'
option name 'Allow-Mcast'
option target 'ACCEPT'
option family 'ipv4'
list dest_ip '224.0.0.0/4'
list proto 'udp'
option dest '*'
Any update here or a workaround?
Can we get someone from the Turris Team look to look into this, coz the Problem seems to be identified already? It would be nice if this could get fixed soon …
that is not really helpful…
Bumping this thread as I really wanted to get IPTV working with my TO today but then stumbled across this thread when I couldn’t get it working.
Hope someone from the team can prioritize this fix 
And what Igmpproxy with TOS 7?
I seem to recall that the issue is linked to kernel 5.15, since TOS7 retains that kernel, the IGMP issue will also stay…