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?
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
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.
Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
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.
@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!
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!
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.
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?
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. You are not helping on this thing, TBH. And also not in position, where you would help as you are not the developer.
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.
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.
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.