Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#580 - Netgear R7800 does not receive multicast messages on LAN interfaces #5597

Closed
openwrt-bot opened this issue Mar 1, 2017 · 3 comments
Labels

Comments

@openwrt-bot
Copy link

gcobb:

Netgear R7800 running lede-17.01.

Multicast packets are not received on LAN (wired) interfaces but work fine on WiFi interfaces. I think the problem is at device/driver level.

The problem was first noticed using Avahi, which did not see announcements on LAN interfaces. However it can be easily reproduced with a simple IP Multicast sender/receiver like https://github.com/GrahamCobb/Multicast-Client-Server-Example

To reproduce:

Run the "client" on the R7800 using:

client 232.0.1.1 4545 100

Run the "server" on another system using:

server 232.0.1.1 4545 100 1000

If the server is connected to the client using a WiFi interface, the messages are received. If it using a LAN, they are not.

The messages are received if the LAN interface is set in promiscuous mode (//ifconfig ... promisc//) or all multicast mode (//ifconfig ... allmulti//). They stop again immediately if the mode is turned off.

I believe this is the same problem as reported in https://forum.lede-project.org/t/ipv6-works-only-with-wan-in-promiscuous-mode/490/9 -- in that thread it is mentioned that the AC2600 (which uses the same driver) has the same problem.

As the problem goes away in promiscuous or all multicast modes, I am guessing that the device is just not sending the multicast packets to the driver. This could be a hardware bug, a bug in the multicast filter setup code in dwmac1000_core.c or the devicetree incorrectly reporting device characteristics such as the number of multicast filter bins.

@openwrt-bot
Copy link
Author

gcobb:

Oops, I had an error the first time I submitted this and had to re-type it. I forgot to set the severity the second time -- it should have been set to "High"!

@openwrt-bot
Copy link
Author

gcobb:

I have tried a few hacks to dwmac1000_set_filter to try to track down the problem.

  • I tried ignoring the value of dwmac1000_set_filter (6) and tried 7 and 8 instead. Neither fixed the problem so I assume that 6 is the correct value.

  • I tried setting all 64-bits in the multicast filter hash. This should match all multicast addresses but it also didn't fix the problem so I presume it is actually a bug in the multicast jash filter (hardware or firmware).

It looks like the only fix for the apparently broken multicast filter hardware is to treat the device as though it didn't have a filter and just set GMAC_FRAME_FILTER_PM (pass all multi) whenever any multicast address is set.

@aparcar
Copy link
Member

aparcar commented Dec 2, 2022

This issue is for a EOL release, please comment if this bug still affects you in currently supported releases.

@aparcar aparcar closed this as not planned Won't fix, can't repro, duplicate, stale Dec 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants