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