Dont think so. The igmp firewall rules are correctly created and seem to pass the traffic according to the counters. If you flush the firewall table and accept all packets by default the issue is not resolved as well.
1 Like
Upgraded to TOS 6.1.0 (kernel 5.15.84) - multicasts from my ISPs network still DO NOT work via the Omniaā¦
Performed a factory reset + upgrade on my Omnia just to narrow down the surface area, still seeing this as well.
any news? tried setting up igmpproxy today and had no luck with Turris 6. downgraded to Turris 5.X and it worked.
@Pepe since 5.X is not supported anymore, what should we do?
I switched my Omnia to OpenWRT 22.03.02 with igmpproxy 0.4, IPv4 Multicast works as expected. Missing some of the Turris extensions and not enjoying the upgrade pain, but a working Multicast is more importantā¦
2 Likes
which upgrade instructions you followed? is it easy to return to TOS later on?
[OpenWrt Wiki] Turris CZ.NIC Omnia - did a schnapps export for an easy way back and I saved my /etc/config files, did a 7 LED boot as documented. 22.03 uses nftables, you might need ip[6]tables-nft. Way back is documented as well, 4 LED boot.
You could try TOS7.0 first from HBL its based on 22.03 and you keep nice Turris stuff like schnapps
I did try HBL and HBD (-future), without success on the multicast side. Forgot whether this was on HBT, HBK or HBL, but I got a bit annoyed as just switching on IGMP snooping on br-lan kills IPv6 connectivity, thatās when I decided to try 22.03.02 and was surprised that multicast, IGMP Snooping and IPv6 worked from the start. I am not developing software any more, but forcing users on a major upgrade without making sure that key features work is a real issue for me, so I doubt that I will ever switch back.
2 Likes
I accept that IGMP is big for your use-case and that your are understandably un-impressed, but I would guess the set of people that consider IGMP a key feature of turris OS is not all that largeā¦
BTW, just released OpenWrt 22.03.03 just temporarily dropped mvebu* devices like the turris Omnia, so be careful where you update to next.
*) OpenWrt snapshots have this fixed the same way as turris OS did, by switching to kernel 5.15.
Itās very disappointing that this is still broken 
For info the official reply from Turris support regarding this matter is as follows:
Actually, this topic is rather advanced and already exceeds our official
technical support. On the other hand, if you manage to figure it out in
collaboration with our or the OpenWrt user community, we can help you to
implement a solution either to Turris OS or directly to the OpenWrt upstream.
Been trying to fix my home network for two days now after the update to 6. Can confirm that this is still an issue (just tried the HBK branch).
I accept that IGMP is big for your use-case and that your are understandably un-impressed, but I would guess the set of people that consider IGMP a key feature of turris OS is not all that largeā¦
Just FYI; perhaps most people donāt have an ISP that only offers IPTV, but for those of us that do, igmp/multicast is an essential feature. We are now left with the choice of reverting to an unsupported OS version or getting a new router.
And udpxy is not an option?
there are no configuration options on the television boxes, so it doesnāt seem udpxy is a promising approach. My workaround has been to use the ISP-provided fritzbox and offload all extra functionality i used from the turris to a raspberry pi. Will keep an eye on this thread to see when I can dust off the omnia again 
So based on what I heard in this and the other threads, I would bet this is a kernel, or rather some driver/kernel module. I wonder if itās feasible to easily downgrade the kernel to whatās in 5.x while keeping the rest of the packages on 6.x to at least validate that assumption (not necessarily run on that configuration afterwards). Not sure how to do that easily with the billion kmod packages, though.
The problem continues, doesnāt it? My internet and TV provider uses this system and it doesnāt work with any other configuration 
Turris is dead at this point. So much for focusing on non-essential things like the LED ārainbowā and having a broken config after the update to 6 even for that - it didnāt stay off on rebootā¦
Yes, interstingly at least for me the internal state is kept it is just thst that state is not applied after start-up. I set the LEDs one level brighter than off, after boot they are at full brightness, however it takes a full 8 button press cycle to get back to my desired brightness indicating a full cycle and hence that the internl vriable state was okay but simply not applied after start-up.
For me this issue is cosmetic only, but I understand other use cases will be more disrupted then mine.
Now, I not sure this is a clear sign of turris being deadā¦