Igmpproxy Turris 6.0

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 :frowning:

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 :slight_smile:

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 :pensive:

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…

hi there… question, since over here i might get fiber with ( different VLAN) TV…does this mean that TV over fiber does not work with a Turris?

If it is multicast based it will not work with TurrisOS 6. Alternatively you could use TurrisOS 5.4.4 or Openwrt 21.02.6. I made the observation that multicast in Openwrt 21.02.7 is broken as well

1 Like

Short answer: Yes, unfortunately, unless the problem is analyzed in-depth for a (user applicable) fix (on Turris Omnia).
I can’t recommend buying Turris products after all the trouble I had with various essential functions even when using the command line through SSH to put things together - something that does not bother me at all by itself.

For me, multicast streaming last worked with Turris OS 3 on my Turris Omnia.
I skipped version 4 and 5 because of significant (quality) issues and finally updated to 6.
Recently, I retested streaming on Turris OS 6.3.2 - to no avail.
I also found that at least IGMP was not passing through the LAN/Switch despite proper firewall/filter tables etc… igmpproxy and udpxy could therefore not even try to fulfill their purpose. However, unproxied (direct) streaming through WAN worked locally on Turris, I was able to stream into a watchable video file using ffmpeg and saw expected traffic.
Given limited out-of-the-box debugging tools and available time, I did not bother any further and put the Turris aside to handle only my legacy WiFi. I might give it away at some point.
The other reason for that is that I put together a 25 GBit router that works with pfSense and currently with plain netfilter (nftables) - just because the experiment was actually fun and yielded expected results after a few hours - not something I can say about Turris OS/OpenWrt.

1 Like

That’s not entirely true - udpxy doesn’t care about IGMP working on the LAN side. That’s the point of it. It translates multicast to unicast, so if you are able to get the stream from the WAN locally on the Omnia, so will udpxy.

I resorted to this setup after fighting this for some time and it works, but it’s a bit painful - requires udpxy support in the player or some search&replace on the playlist. But works for now.

However, it seems that my Omnia is destined the for same future as yours. I used to be excited about the 10gig version (if it ever comes out), but after this & the 6.0 push fiasco… sorry, not interested.

You’re absolutely right about udpxy on Turris, didn’t think about that.
In my setup, it sits next to streaming clients at a separate Switch and WiFi AP (on a NAS behind NGINX, which serves corresponding station playlists and larger file shares). WiFi throughput/stability was the main reason for me to set up udpxy.

Anyway, it’s unfortunate that we seem to have very similar issues in general.

Well, that can be a major reason for slow sales to an average joe like myself, since cable tv is slowly replaced by fiber ( VLAN ) tv.
Most of the technical stuff published in this topic is far beyond my knowledge about IGMP and such, therefore my question.

And if i understand correct, this is a kernel, and /or openWT flaw that can only be solved by users?

as stated, fiber IPTV is the future, so a major (sales) Bummer.

Unfortunately, facts speak for themselves. Just look at the changelog of the last 3 versions and check what Turris is focused on. We’re got a network routing appliance that cannot do core networking stuff like multicast but that can run Librespeed, Syncthing or even Transmission, and the problem hasn’t even been acknowledged by anybody maintaining the firmware. Now read between the lines :frowning:

As usual, there are many possibilities without knowing the actual cause of the problem. It could indeed be a problem in the kernel (network modules) or any other binaries requiring a patch for Turris OS or the underlying OpenWrt followed by a regular Turris OS update on the device. Or it could be some not so obvious config issue that can also be fixed by most users through the web UI or SSH until the fix is added to the OS package.
Since unicast streaming with udpxy is at least troublesome if even possible to set up on a TV or a proprietary streaming box, I’m afraid that a Turris is currently not a good option.

1 Like

This is indeed a kernel/driver flaw, either something in networking stack of the kernel or (more likely) the switch/NIC driver. It is pretty hard for a kernel bug to be solved by users to be honest ;-). But Turris support shows no interest in this… even though it’s their problem, or potentially openwrt problem, but openwrt will likely want nothing do with it (clearly), since Turris is not their device.

So it’s either on the community (with the understanding that not many people have the required knowledge or have time and experience to troubleshoot it), or to get cznic support to actually care :frowning:

2 Likes