How to disable router IGMP snooping multicast on AXE16000

[Qwinn]

For the record, I'm running the stock firmware, but I would be willing to switch to merlin if it can help address this issue.

On my home network served by my AXE16000 router, all my firewalls are showing that I'm blocking a packet from my router on 224.0.0.1 every 20 seconds. Based on that IP address, I strongly suspect this is IGMP snooping. I basically never do multicast streaming or use IPTV, so as far as I'm concerned this is a useless resource hog that is polluting all my logs (yes, I know, I could set up rules to clean up the logs. I don't want to have to to no good purpose.)

I have disabled every option under LAN -> IPTV. I have disabled IGMP snooping under all 4 WiFi bands under Wireless -> Professional. It has had absolutely zero impact on these every-20-second packets on 224.0.0.1 from the router to every device on my LAN.

I've searched for HOURS and the only thread I've found that even comes close to addressing this topic is this thread from 2 years ago.

Disable IGMP Snooping on AX88u

How do I disable IGMP Snooping on Asus AX88U? I have it disabled in: Wireless professional settings, and 'Multicast Routing' is disabled in IPTV settings as well However, in Wireshark, I can clearly see the LAN Gateway IP (which sits on AX88U) generating IGMPv3 Membership queries. Is there...

www.snbforums.com

The upshot of that, and the thread linked to near the end, is that it seems that this packet is being broadcast every 20 seconds from the router by a process called mcpd. If you ssh into the router and do `killall mcpd`, the queries will stop. But that hardly seems like a permanent solution, it would just resume the next time the router rebooted. There are some tips in the subthread on how to edit the mcpd configuration file, but none of the settings there seem to amount to "disable", best I could do would be to increase the interval.

Is it seriously impossible to disable this multicast spam? Or is this constant multicast serving some purpose other than IGMP snooping that I'm unaware of? If there is some perceptible benefit, I'd be happy to allow the packets, but so far I have blocked them on my linux boxes and not experienced any negative consequences I'm aware of.

 

[Qwinn]

Update: After posting that I found this thread, which *appears* to have a solution. Apparently - and I am assuming this is a merlin-only feature - I could add a wan-event script that would kill the mcpd process 15 seconds after the router reboots.

Solved - RT-AX88U flooding with broadcasts

Finally I've migrated from my old RT-N66U to my new RT-AX88U. Now the new router floods the network with broadcasts to 224.0.0.1. One of my Linux machines Firewall log shows a lot of these messages every minute: kernel: [79742.785227] [UFW BLOCK] IN=br0 OUT=...

www.snbforums.com

That was years ago, and at least 2 people indicated that they did this and never posted suffering from any negative effects from it. I still feel like this requires excessive lengths to have to go through to simply disable something like this though. So I'm willing to wait a couple days for someone to hopefully offer advice or a better way to do this that may have arisen in the 5 years since, before I risk bricking my router.

 

[ColinTaylor]

As I said in that other thread "IGMP snooping" is not the same as multicast traffic. If anything you want IGMP snooping enabled to prevent multicast traffic being sent to devices unnecessarily. What you might be seeing is a multicast IGMP membership query. This is a good thing, ignore it. If you really want to kill mcpd you could probably do so in a wan-event script in Merlin's firmware.

 

[Qwinn]

I understand that they are not the same thing (as did the guy you initially said that to). I virtually *never multicast*, so these 20 second packets are a useless waste of resources. The only multicasting I'm getting, aside from some WSD and Avahi-daemon device discovery packets on ports 3072 and 5353 that at least serve some purpose and are far less frequent, is this 20 second spam from the router. Is it so wrong that I want to disable continuous traffic on my network that I get no benefit from whatsoever?

And as other people in the linked threads noted, that spam can have some seriously negative consequences, like waking devices from sleep when wake on LAN is otherwise needed and enabled. It has also, in the past, been used as a DoS attack vector. It's puzzling to me why there is no easy way to disable this traffic that is only of benefit to a small minority of users who frequently multicast.

If this spam was of *any* benefit, if it improved my network in *any* way, I'd be happy to allow it, but as it stands, it is 100% pure negative.

 

[ColinTaylor]

I understand that they are not the same thing..

In which case you should remove the word "snooping" from your title question because what you are asking has nothing to do with snooping.

Apologies. I confused myself by looking back at those old discussions from 2019 and 2021. Back then I was still using an RT-AC68U in which multicast snooping was implemented differently. That generation of router doesn't have mcpd but uses snooper instead (older firmware didn't even have that). snooper doesn't send IGMP queries every 20 seconds, rather it sends one every two minutes.

 

[Qwinn]

In which case you should remove the word "snooping" from your title question because what you are asking has nothing to do with snooping.

What? The 20 second broadcasts coming from the router IS IGMP snooping that I can't disable. I am trying to disable that snooping. Not all multicast traffic is snooping, but all IGMP snooping is multicast traffic, and that is what I'm trying to disable. You seem fixated on this meaningless (at least, in this context) distinction.

Either make the case that these 20 second packets coming from the router on port 224.0.0.1 are NOT IGMP snooping, despite that port being generally reserved to that purpose, or quit complaining that I'm using the terms incorrectly.

 

[ColinTaylor]

OK, let's ignore the semantics and answer your question: how to stop the multicast traffic you're seeing. The answer to that, on stock firmware, is you can't. You would need to install Merlin's firmware.

 

[Qwinn]

Bleah. I was afraid of that (and I still find it baffling that a "feature" that was available but disabled by default on virtually all routers just a couple years ago has now become irremovable despite it only being useful to a subset of the population and having several cons attached).

If Merlin's firmware had a simple switch in the GUI to do it, I'd be far more inclined to do it - I am pretty confident I could just install the firmware and flip a preprogrammed switch without significant risk of bricking the router. But having to directly muck about with startup services and scripts makes it a far riskier proposition. As annoying as the spam is, I don't think it's worth any risk of bricking a $600 router to get rid of it.

 

[ColinTaylor]

In that case I think the best solution would be to filter out the messages in your firewall log, even though you said you didn't want to do this. In terms of network traffic, 60 bytes every 20 seconds is negligible.

 

[Qwinn]

Yeah. Sigh. Either allowing it or denying it eliminates it from normal low level logging, but raising the log level at all in cases of debugging floods the logs again, when I need quiet logs the most. I'll see if I can find an absolute filter that operates on all log levels.

 

[glens]

Sorry, (still) not going to look at the other threads linked or any of that. I was looking at something else just now and remembered seeing this thread earlier today. If it hadn't been mentioned in those other threads you might ssh into your router and have a look at /bin/bcmmcastctl to see if it can do anything to help you.

# bcmmcastctl show
Interface br0: IGMP snooping mode 1, rate limit 0
Interface br0: MLD  snooping mode 1, rate limit 0

# bcmmcastctl 
Usage: bcmmcastctl <option>
        show  -  Show configuration:     [-i <ifindex or ifname>] [-p <igmp(1), mld(2)>]
        mode  -  Set snooping mode:       -i <ifindex or name>     -p <igmp(1), mld(2)> -m <disabled(0), standard(1), blocking(2)>
        rate  -  Set protocol rate limit: -i <ifindex or name>     -p <igmp(1), mld(2)> -r <0 to 500>
        blog  -  Enable/disable blog:     -e <disable(0), enable(1)>
        prio  -  Set priority queue :     -p <queue priority>

 

[Qwinn]

Sorry, (still) not going to look at the other threads linked or any of that. I was looking at something else just now and remembered seeing this thread earlier today. If it hadn't been mentioned in those other threads you might ssh into your router and have a look at /bin/bcmmcastctl to see if it can do anything to help you.

# bcmmcastctl show
Interface br0: IGMP snooping mode 1, rate limit 0
Interface br0: MLD  snooping mode 1, rate limit 0

# bcmmcastctl
Usage: bcmmcastctl <option>
        show  -  Show configuration:     [-i <ifindex or ifname>] [-p <igmp(1), mld(2)>]
        mode  -  Set snooping mode:       -i <ifindex or name>     -p <igmp(1), mld(2)> -m <disabled(0), standard(1), blocking(2)>
        rate  -  Set protocol rate limit: -i <ifindex or name>     -p <igmp(1), mld(2)> -r <0 to 500>
        blog  -  Enable/disable blog:     -e <disable(0), enable(1)>
        prio  -  Set priority queue :     -p <queue priority>

Oooh, that looks like good stuff, thanks! Just checking, is that something I could make use of ssh'ing into the router on stock firmware? Or is that Merlin only? And do you happen to know if functions like that are naturally persistent, or do they come with config files that can be set in order to make them so?

I was about to post again anyway because I made some interesting discoveries since my last post, that maybe could help someone else with an interest in getting rid of unnecessary network traffic:

First, in UFW in Linux, you can make IGMP spam silently accepted at all logging levels by adding this to your /etc/ufw/before.rules file, anywhere before the COMMIT. (Naturally, you could also block it this way)

-A ufw-before-input -p igmp -d 224.0.0.1 -j ACCEPT
-A ufw-before-output -p igmp -d 224.0.0.1 -j ACCEPT

But I'm actually glad this all happened, because I noticed something while I was in that before.rules file - there's a much *bigger* source of multicast spam that gets hidden from you in a default UFW install. This is in the default before.rules:

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

SSDP/UPNP is poison, and I have it disabled on all of my windows machines (I let all autodiscovery be handled by Avahi and WSD, be aware if you do the same you'll have to install either wsdd or wsdd2 on your linux boxes in order for Windows boxes to be able to discover samba shares and stuff like that), but when I commented out that line and restarted UFW, I discovered that virtually every one of my machines on my network was spamming SSDP/UPNP discovery on that IP and port. Like, a *lot*. And I spent hours trying to determine what the source was, since I had all related services already disabled. I found two major culprits, with some help from wireshark:

1) My Plex Server. There's no easy way to get it to stop spamming SSDP/UPNP (apparently a means to do so has been a top customer request for years) except to set up an outbound "stop sending on port 1900" outbound firewall rule, which I did. Net effect was that my NVidia Shield takes a little longer - a minute or two - to initially detect my Plex server after a cold boot of both machines, but after that they are connected and I stream just fine directly to the Shield on a local unicast connection, at least in my initial testing. If I run into further problems beyond that, I'll update this post.

2) Browsers. Damn near every browser. If you have machines with browsers that you don't cast from and you don't want them barraging every device you own with spam every few seconds, go into your browser flags settings (brave://flags, edge://flags, chrome://flags, you get the idea, obviously this is for browsers built on chromium, if you're using others you can probably find similar settings) and disable these two services:

Connect to Cast devices on all IP addresses​

Have the Media Router connect to Cast devices on all IP addresses, not just RFC1918/RFC4193 private addresses. – Mac, Windows, Linux, ChromeOS, Fuchsia,
Lacros
#media-router-cast-allow-all-ips

Allow cast device discovery with DIAL protocol​

Enable/Disable the browser discovery of the DIAL support cast device.It sends a discovery SSDP message every 120 seconds – Mac, Windows, Linux, ChromeOS, Fuchsia, Lacros
#media-route-dial-provider


After doing that, and even with that before.rule hiding the multicast spam commented out (and the SSDP and UPNP services stopped on Windows machines as I said, of course), I get almost none of this SSDP/UPNP poison traffic anymore. So much nicer. Hope this helps someone!

 

[glens]

Net effect was that my NVidia Shield takes a little longer - a minute or two - to initially detect my Plex server after a cold boot of both machines, but after that they are connected and I stream just fine directly to the Shield on a local unicast connection, at least in my initial testing.

Just wondering how long it might take, with everything on the network "spamming" as much as it can, to "cost" you the same "minute or two" of lost (superceded) "normal traffic" flow...

Naturally(?) by firewalling such un-disabled-in-the-first-place traffic you're still going to have the packets flowing (maybe more so?) on the network anyway, until they get to the firewall, right?

I understand your goal but not so much the motivation for it.

 

[Qwinn]

Just wondering how long it might take, with everything on the network "spamming" as much as it can, to "cost" you the same "minute or two" of lost (superceded) "normal traffic" flow...

Naturally(?) by firewalling such un-disabled-in-the-first-place traffic you're still going to have the packets flowing (maybe more so?) on the network anyway, until they get to the firewall, right?

I understand your goal but not so much the motivation for it.

It only took a couple of extra minutes after a cold boot on both machines. I can't even say for sure that there wasn't always a delay in connecting in such a circumstance. Under normal conditions, neither the Shield nor the Plex server is rebooted.

And no, the firewall I put up was outgoing on the Plex server. The packets are not arriving on the network at all. And that was only one PC spamming anyway, and only for Plex. The browser thing is the real tip.

And finally, this is unnecessary traffic I won't have to spend time to filter out or determine I can ignore should I ever need to be debugging or watching network traffic for any other reason that can come down the line.

People spend days removing bloat software from their systems for no real gain. Why is removing network trafic bloat viewed as different somehow?

 

[glens]

Not viewing it negatively, just wondered how much of, say an hour, is the bandwidth occupied by these packets. Is it seconds even? Certainly not into minutes...

 

[jonnyc55]

apparently a means to do so has been a top customer request for years

Is there anyway companies can data mine this multicast traffic? It seems very convenient to a data marketer. Knowing all devices on the network... when these devices turn on/off... what these devices are... It seems like golden information.

For me I want it gone, because there's no telling how this play outs with hardware/software interactions performance or privacy wise, so if it's gone, well, there's no concern about that anymore.

Oh and principle, if that was the case, like hell I want my LG TV which I spent £1000 on to continue making more money out of me.

I saw this on reddit regarding 'going on the offensive against smart TV's' in the r/privacy:

Vizio just announced they make more from selling your data than they do on tvs. They can’t make money off you if you don’t connect it to the network

I know the data mining can include direct data mining from TV watching, but I've seen in wireshark my LG TV doing SSDP multicast and no clear setting on the internet to toggle that off, similar to the plex server issue.

If multicast can be used for marketing and is a gold mine for them, then all these companies are going to bury the setting, or not have it available and I get a big feeling that's the case.

 

[jonnyc55]

It only took a couple of extra minutes after a cold boot on both machines. I can't even say for sure that there wasn't always a delay in connecting in such a circumstance. Under normal conditions, neither the Shield nor the Plex server is rebooted.

And no, the firewall I put up was outgoing on the Plex server. The packets are not arriving on the network at all. And that was only one PC spamming anyway, and only for Plex. The browser thing is the real tip.

And finally, this is unnecessary traffic I won't have to spend time to filter out or determine I can ignore should I ever need to be debugging or watching network traffic for any other reason that can come down the line.

People spend days removing bloat software from their systems for no real gain. Why is removing network trafic bloat viewed as different somehow?

Did you ever find a SSH command you can use with the stock firmware to stop the snooping for good? Is there a script you can use with merlin software? I'm going to set-up merlin software tomorrow, as I found no way to stop LLDP multicast permanently either. I don't mind 2 scripts running on router restart, it's no different to procedures running on start-up on any machine. But yeah, does stopping IGMP and LLDP have any negative effect past these file sharing screen casting applications? I just don't use them... And for something that I know most people I know don't bother with such things... I'm amazed there's no simple toggle, like any other toggle on the stock router page... there is stuff on the stock settings page, that regards things that aren't probably used by 99% of the population, yet when it regards a spam of multicast traffic as we speak, no toggle to turn that off... Odd... That's why I suspect data mining has hardware/software vendors keep their cash cow on lockdown... whether they can harvest that information?