No go. And as far as I can tell from the source, the regval command should also be listed through the help command, which it isn't. And the executable in the build system is clearly being updated (new timestamp), so it is being compiled and generated.
I'm not able to figure out why it doesn't work. I think there might be a change needed also to the userspace application to make it work, but all the layers and abstractions are confusing to someone who hasn't spent much time in the kernel.
TBH I haven't tested that commit, because by the time I cherry-picked it I've switched to qca8k.
Meanwhile I've browsed through qca8k code with blogic's additional patches - it doesn't use igmp snooping as is, instead it enables multicast offloading within the switch, so the effect probably is the same.
The qca8k code is most likely the future, but I need to stay on stable due to the issues I have with master.
I looked a bit further into this, and it is clear that along with the driver patch there must also be changes made to the userspace application to actually access the added functionality in the driver. In other words, modifications are needed in:
/package/network/config/swconfig/
However, it doesn't look like the commit you pulled has anything like that.
Not sure about this, as an example this commit doesn't require such modifications
https://github.com/dissent1/r7800/commit/82deb4b3455c1dd92e019b50ce25fbbe47439082
edit: seems that direct reg access is lacking some bits
edit2: nvm I messed things up with the example, posting on the go.
I think that could be because that patch just adds a new attribute to the global attributes. The existing userspace code just receives this list. The register access patch adds new commands and types, which the userspace application doesn't know about. It would be strange the driver changes wasn't accompanied with the necessary changes to the userspace application, but where to find that?
Yep I vastly messed that these commits are completely different. 
Anyway imo for now the best option for you is to swap cpu ports. You can also open a ticket in FS explaining the situation and findings
Ok. It is also possible to modify the default values of the bits in the driver, but it would have been better to have support for it in the userspace application. If it isn't possible to find code for this, I guess I could try hacking something myself. Should be doable, but might not be worth it.
Ok, I modified the driver to set the IGMP_COPY_EN bit in register 0x620 to 1 instead of the default 0. What this does, is that it will copy IGMP frames to the CPU instead of redirecting the frames.
And does it have an effect? It sure does. Now I can enable IGMP snooping and still see the query frames at eth1. However, as opposed to before, I now also get both the queries and the reports at eth0. Previously I got only the queries, while the reports would stay where they should. This is a bit strange, as the data sheet has the following note for the IGMP_COPY_EN bit:
This IGMP does not include the IGMP join/leave
packet
I am not yet sure if this will have any unwanted side effects. The IGMP packets are not seen at the actual wan interface (eth0.2), which is good. I'll have to test with some actual multicasts to see what happens. If the stream data is somehow duplicated now, then it will be bad, but I can't imagine why it should be. The changes should only affect the management frames, I think.
My modification to the driver does fix the problem with the queries, and with this fix in place, it is possible to enable IGMP snooping on the switch to avoid flooding the multicast to other devices.
However, I am now facing a different issue, which is that I get stutter on the TV (which is what the multicast is there for) when I run for example Speedtest on my computer. This saturates the WAN at 300 Mbit/s (both ways, in sequence), but the IPTV traffic is not using WAN. The traffic for that comes in on a separate VLAN.
I've also noticed that when the set top box is booting the router becomes really sluggish and I saw that ksoftirqd was consuming 40-50% CPU. I have no clue why, though.
I also tried reverting back to a build without my driver modification, with no difference to that issue (other than the fact that the TV stream times out after a few minutes due to the queries taking a wrong turn), so I don't think this driver modification has any adverse effects.
FYI: I submitted a bug report for this:
https://bugs.lede-project.org/index.php?do=details&task_id=954
In the bug report I also attached a patch with my suggested fix, so if anyone else has this issue, try the patch.
Has anyone attempted to enable IGMP Snooping on the switch???
https://openwrt.org/docs/guide-user/base-system/basic-networking#config_switch
Some news for the ag71xx ?
Thank you 
Is there a reason you're visiting all posts related to IGMP Snooping???
Perhaps you should make a new thread for your issue.
And five(!!) years later, this issue is still there, unfortunately. I have just used my own build all this time (yes, I should have kept it up to date, but it has just been working), and now I decided to check whether this problem had been resolved, so I flashed a backup router with 22.03.0-rc5. IGMP queries still gets sent to the wrong CPU port when IGMP snooping is enabled on the switch.
I had hoped to just be able to use a vanilla OpenWRT going forward, but this means I would still have to create my own build so I can patch this annoying issue.
It is of course possible that a DSA build would not have this problem, but as far as I can tell, DSA isn't going into OpenWRT mainline for the R7800 for other reasons.
1 Like
It seems your patch got lost during issue tracker migration (it cannot be found at https://github.com/openwrt/openwrt/issues/5905).
Would you be so kind to share it again? Thank you.
Yes, I can. I'll just have to check if the patch needs to be modified to apply cleanly.
I guess I would submit it as an issue here: https://github.com/openwrt/openwrt/issues ?
And then just include the patch to the issue?
Your old issue was migrated and now exists at https://github.com/openwrt/openwrt/issues/5905, so you can use it already.
That being said, it seems that if you create a pull request, it would get more chance to get reviewed/merged.
Maybe some regular OpenWrt contributors (I am not) may shed more light on the process.
You are probably right that creating a pull request gives the best chance of getting it fixed/reviewed/merged. The migrated old issue could perhaps be reused as well, but maybe it is better to create a new one, as the old one is owned by the migration bot.
1 Like