Igmpproxy not working on OpenWrt Fork 6.0/21.02 (Turris)

I used the same config for my providers IPTV App for years with OpenWRT and now for 2 years on my Turris Omnia with Turris OS, which is a fork of OpenWRT. It worked allways smoothless. Now they updated Turris OS to fork 21.02, and igmpproxy stopped working without changing the config. 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 ”.

I have no ideas where to start debugging: kernel options? Firewall? etc.

Anyone able to help?

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

Ask Turris, it's their version of openwrt, and a black box for us.

1 Like

That's not true. :wink: We have just patches on top of OpenWrt, and our specific Turris feed with packages which can not be upstreamed like Updater-ng (Automatic updates), reForis (UI), etc.

This should be reported here, IMHO. Not specific to Turris OS, anyhow.

Works in official 21.02. You should ask Turris - especially since their update caused the issue you describe.

Would seem to be, based on @lleachii's comment

1 Like

It is not. See:

The thread you linked list Turris and other devices with similar hardware. Semantics to say "it's not".

I will test again on my device.

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

1 Like

@psherman, I see that you are here now, it is good to see someone new involved in OpenWrt (hopefully), but I have yet to see that you contributed to the source code, which you mentioned. It's a pity, so I will skip that part because it will answer all your steps, which you provided! :wink:

Even though I am not the reporter, here you go:

So, the thread can be closed. Since the beginning, I told you - this is NOT specific to Turris OS anyhow! :wink:

I apologize if you thought I was insulting your language or something; but that's not what I meant.

I simply meant the Turris is listed and similar devices - and that it works as noted. This would mean that hardware is likely, since it's similar.

What is the issue specific to???

I have a working igmpproxy here.

(The reporter noted mvebu, again same hardware as Turris - semantics. OpenWrt uses hardware targets, so mvebu == "Turris".)

:spiral_notepad: Perhaps it has something to do with the issue of those devices leaking packets across VLANs/ports as if the device were a hub.

I've been here for quite a while, thank you.

I fail to see how my contributions to the OpenWrt source code has anything to do with the custom fork that you are running on your device.

This is, by definition, not an official version of OpenWrt. They (Turris) have made change and customizations, which will affect how the OS functions. Therefore, if you find bugs in the Turris OS, it is best addressed by asking them for support, or by installing an official version of OpenWrt and verifying that the bugs exist in pure OpenWrt as well. If the issues only present on Turris OS, it is the responsibility of the Turris maintainers to fix them. If they can be proven to occur in the official version of OpenWrt, then that becomes a bug to submit against OpenWrt.

Until this point, you had not provided any specific information to conclusively demonstrate that the bug exists in the Official OpenWrt version, as it appears you did not install OpenWrt (official) on your device for testing. In the future, if you are aware of a bug report prior to your post, please include that in your discussion -- this saves a lot of hassle.

2 Likes

Please feel free to mark the appropriate post as the solution (including your own, if you'd like). Or if you'd like the thread closed without a declared solution, please indicate as such.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

1 Like

Nope, this is wholly wrong from the beginning. You can not label Turris as mvebu even theoretically, as you would forgot about Turris 1.x routers, which are using mpc85xx.

Are you using snapshot with kernel 5.15? The thing is that it is related to kernel 5.15.

This explains everything since you did not understand anything. I am so sorry, but you are wasting my time here, and your reasoning is completely wrong. You should take a look, what Turris OS is. You would see that Turris OS are just patches based on top of OpenWrt + own Turris feed, which leads to your definition is wrong again. This affects OpenWrt and as well Turris OS. I see that the bug was submitted. Wasn't it? :wink:

You are going entirely off-topic on this thing...

And here you go. Again you're mistaken. I am not the OP, who created this thread, thus I can not do anything. :wink: You are not helping on this thing, TBH. And also not in position, where you would help as you are not the developer.

So it affects mvebu on Linux Kernel 5.15. Thanks for [finally] clarifying/answering.

Let's respect the mods.

I'd like to take this opportunity to remind you of the OpenWrt Community Guidelines. Please keep things civil -- your above comments do not follow these guidelines.

It is true that I'm not the developer, but that doesn't mean I cannot help. In fact, if you look at my history here, you will find that I am an active contributor and I have helped many, many users resolve their issues. If only the developers of $product were the ones who could assist/solve problems, the world would be a very different place.

Fair enough, but you suggested the thread could be closed and, when I replied to that specific comment, I didn't look back up-thread at that moment to see who had opened this one in the first place.

2 Likes

I am having the same issue with OpenWRT "master" on a Turris Omnia.

  • I use omcproxy ( and the luci plugin ) instead of igmpproxy.
  • I last made an OpenWRT image for this router in october. No issues with IPTV.
  • I made an image from master last weekend. Same configurations as before. Result: No IPTV.
  • Initially I thought the problem was from the switch from fw3 to fw4 but this was incorrect.
  • by painstakingly bisecting a bunch of builds from master I was able to narrow down to the commit that causes the issue:
    https://github.com/openwrt/openwrt/commit/738b04c88128d9963b81bff68426980f587f22d9
    It is the commit that bumps the kernel from 5.15.85 to 5.15.86.

Note: because I do make many optimization changes to my custom build, I tried using the images available from OpenWRT for the Omnia and installing the packages from the package manager. Same issue. If I install a build before 5.15.86 it works, if it is a build with 5.15.86 or higher kernel it doesn't work.

Also, it's not from the packages versions. I am currently running a build that checks out master on the commit prior to the kernel bump and the latest packages without issues.

I left a note on the commit.

1 Like

So I just figured out that I am running a very old bootloader.

root@gateway:~# strings /dev/mtd0 |grep "U-Boot 20"
U-Boot 2015.10-rc2 for db-88f682
U-Boot 2015.10-rc2 (Aug 18 2016 - 20:43:35 +0200)

Having in consideration the omnia changes from kernel 85 to 86 ( there are two patches that depend on info from the bootloader I am considering updating and try out if it fixes the issue.

The OpenWRT page says that to upgrade one needs to boot the TurriosOS and use the nor-update package to update it, but I am sure there must be a way to do it from within OpenWRT.

Can anyone help me with this? @Pepe ?

I downloaded the:
turris-nor-update_1.1.0-7_arm_cortex-a9_vfpv3-d16
and the
turris-omnia-devel-firmware_0.0_arm_cortex-a9_vfpv3-d16

but I really don't know how to proceed and I'm kind of afraid of bricking the device.

new u-boot didn't fix it.

I am having the same problem, is there any way I can help?
My internet and TV provider needs this package in order to work.

you have to use a kernel 5.15.85 or bellow.

No one cares.
I have opened a bug report, complained on the commit that updated kernel from 5.15.85 but no one cares.

as you can see, the persons responsible for the commit @hauke and some graysky2 that killed this network capability couldn't care less. Business as usual. Reply? what for.

Anyway, it is what it is. It's free, people do it on their own time, and well, one doesn't really have arguments to complain all things considered.

by the way, latest kernel 5.15.116 still has the issue and kernel 6.1 is not available for testing on the mvebu platform yet.

I am, unfortunately unable to help further. I think the next step would be to figure out the particular patch from kernel .85 to .86 introduces the bug. I have some suspicions that I pointed on the .86 commit but I do not know how to remove those particular patches and compile openwrt without them.

1 Like