Multicast/switch/snooping/vlan problem. Bug?

Along with your test it's definitely wrong redirection to port0. Check bit 0 at offset 0x0210 and follow the description

And the cpu port is controlled by bit 10 at 0x0620 - only port0, probably it explains the behavior

You may try setting igmp_copy_en bit to 1.

You may try using it

edit: or 0x0618 bit 28 may also solve the issue, so it puts a correct entry into an arl table
edit2: nvm this bit is already set to 1 by default

Thanks a lot for taking the time to look at this! I've patched my tree now, and I am building as we speak!
It will be useful (and dangerous) to have the possibility to experiment with the registers directly, but hopefully a solution can be found. I'll try your suggestion when I have the new build running, and if a solution is found, then it should be permanently fixed. I guess that will also be a fix in swconfig?

Hmm, even if the patch applied cleanly, and I did a make clean in the tree before building, it still looks like the old version of swconfig is in the image, as there are no new commands/attributes (should be get/set regval, as far as I can tell).

It should be vice versa - regval get/set

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:


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

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

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

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:

In the bug report I also attached a patch with my suggested fix, so if anyone else has this issue, try the patch.

I have the same problem on the ag71xx. Is there any solution for me?

Has anyone attempted to enable IGMP Snooping on the switch???

Some news for the ag71xx ?
Thank you :slight_smile:

Is there a reason you're visiting all posts related to IGMP Snooping???

Perhaps you should make a new thread for your issue.