What's new

Solved RT-AX88U flooding with broadcasts

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

netware5

Very Senior Member
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:

Code:
kernel: [79742.785227] [UFW BLOCK] IN=br0 OUT= MAC=01:00:5e:00:00:01:0c:9d:92:02:31:98:08:00 SRC=192.168.77.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=40293 DF PROTO=2

Any ideas what is happening and how to stop it? Seems to be that some change introduced between 380.70 and 384.13 causes that. The new router is with Merlin's 384.13
 
Run a pcap trace and look at the packets in Wireshark


Sent from my iPhone using Tapatalk
 
Curious how you migrated to the RT-AX88U? What steps did you take specifically?

Did you use the new powers and capabilities of the new router (by using mostly default values), or did you merely copy (or worse; import) your old settings into the new hardware?

After flashing RMerlin onto the RT-AX88U, did you perform a full reset to factory defaults and then follow up with a minimal and manual configuration to secure the router and connect to your ISP?

Are your devices configured specifically to work with the capabilities/limitations of the old router?

The full answers to the questions above may be helpful in solving this for you quicker. :)
 
Curious how you migrated to the RT-AX88U? What steps did you take specifically?

Did you use the new powers and capabilities of the new router (by using mostly default values), or did you merely copy (or worse; import) your old settings into the new hardware?

After flashing RMerlin onto the RT-AX88U, did you perform a full reset to factory defaults and then follow up with a minimal and manual configuration to secure the router and connect to your ISP?

Are your devices configured specifically to work with the capabilities/limitations of the old router?

The full answers to the questions above may be helpful in solving this for you quicker. :)

1. "Migration" was in fact just manual entering the DHCP data in the new router :D so no direct importing of values :D Used default values of new router except control channels of Wi-Fi.
2. Yes, I did factory reset after flashing Merlin's FW.
3. All TrendMicro and Asus stuff disabled and not used.
4. No devices with specific configurations to match the old router
5. Yes, I did everything as required. I am an old user and senior forum member :D :p
6. The new router is still in very simple configuration as OpenVPN servers and Samba share are not activated yet. It is just router now.
 
Last edited:
Here is the tcpdump output on Linux machine. Seems to be that router broadcasts IGMP queries.

Code:
19:57:15.757891 0c:9d:92:02:31:98 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 192.168.77.1 > 224.0.0.1: igmp query v2
 
Here is the tcpdump output on Linux machine. Seems to be that router broadcasts IGMP queries.

Code:
19:57:15.757891 0c:9d:92:02:31:98 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 192.168.77.1 > 224.0.0.1: igmp query v2
There are two areas where you can play with IGMP. One is under the IPTV tab in Lan settings and the other is under professional settings of each wifi frequency.
 
There are two areas where you can play with IGMP. One is under the IPTV tab in Lan settings and the other is under professional settings of each wifi frequency.

In both places the values are "disable" as it was on my old router.
 
In both places the values are "disable" as it was on my old router.
IIRC they changed IGMP options in the recent router models. Do you still have the option "Enable efficient multicast forwarding (IGMP Snooping)"? If so that would normally need to be enabled to stop the traffic you're seeing.
 
IIRC they changed IGMP options in the recent router models. Do you still have the option "Enable efficient multicast forwarding (IGMP Snooping)"? If so that would normally need to be enabled to stop the traffic you're seeing.

No, I have no this option under LAN>IPTV. But I have "Enable IGMP Snooping" under Wireless>Professional, which is "disabled". Changing it to "enabled" does not change anything.

This is very dissapointing .... Probably I can do something using postconf scripts, but need infomation about mcpd deamon and its mcpd.conf file ....
 
UPDATE: Killing the process "mcpd" by issuing kill -9 <PID> solved the problem. I will appreciate any advices how to stop mcpd permanently.
 
Local multicast - nothing to worry about.

I don't worry regarding why this happens. The problem is that this traffic floods the firewall log of very tiny Linux VM hosted by my fileserver. This VM is dedicated for one task only, resources allocated (RAM, HDD, etc.) are minimised, and constant HDD activity is not desired. So flooding the log is not accepatble at all. And for some reasons I don't want to allow this traffic in firewall rules in order to stop flooding of the log.
 
I'm not that familiar with UFW but can you not just suppress the message so that it isn't logged?
 
I'm not that familiar with UFW but can you not just suppress the message so that it isn't logged?


Unfortunately there is no way to exclude only certain packets from ufw log (for example not logging blocked packets incoming from certain IP address). The only options available are "logging of" and "logging on" and also I may play with log level. I don't want to stop ufw logging at all.

It is weird that Asus decided to run IGMP broadcast by default and didn't provide the possibility for users to enable or disable it. And also there is no official information from Asus regarding mcpd daemon and its config file mcpd.conf.
 
Unfortunately there is no way to exclude only certain packets from ufw log (for example not logging blocked packets incoming from certain IP address). The only options available are "logging of" and "logging on" and also I may play with log level. I don't want to stop ufw logging at all.
One of the suggestions in the previous links was to suppress the messages in the logger (rsyslog) rather than UFW. I do this on my Ubuntu box for a couple of irritating messages, e.g.:
Code:
# cat /etc/rsyslog.d/15-my-filter.conf
# Supress sysstat cron messages
:msg, contains, "command -v debian-sa1" stop
# Supress anacron messages
:programname, isequal, "anacron" stop


It is weird that Asus decided to run IGMP broadcast by default and didn't provide the possibility for users to enable or disable it. And also there is no official information from Asus regarding mcpd daemon and its config file mcpd.conf.
You can customise the mcpd.conf file so maybe try experimenting with that. Difficult as you say because of the lack of documentation. This (from a google search) looks interesting, perhaps add this line?
Code:
igmp-snooping-enable 1
Or possibly change igmp-snooping-interfaces to a bogus value.

EDIT: What do you currently have in mcpd.conf?
 
Last edited:
................................................
You can customise the mcpd.conf file so maybe try experimenting with that. Difficult as you say because of the lack of documentation. This (from a google search) looks interesting, perhaps add this line?
...........................

EDIT: What do you currently have in mcpd.conf?

This is the default configuration after factory reset:

Code:
##### IGMP configuration #####
igmp-default-version 3
igmp-query-interval 20
igmp-query-response-interval 100
igmp-last-member-query-interval 10
igmp-robustness-value 2
igmp-max-groups 25
igmp-max-sources 25
igmp-max-members 25
igmp-fast-leave 1
igmp-admission-required 0
igmp-admission-bridging-filter 0
igmp-proxy-interfaces eth0
igmp-snooping-interfaces br0
igmp-mcast-interfaces eth0

##### MCAST configuration #####
igmp-mcast-snoop-exceptions 239.255.255.250/255.255.255.255 224.0.255.135/255.255.255.255
mld-mcast-snoop-exceptions ff05::0001:0003/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

I never touched it yet.
 
Update of the situation:

When recently updated my RT-AX88U from 384.13 to 384.15 it had reached 66 days uptime with mcpd daemon killed. So I decided that the test period is sufficient and I may do something to permanently disable the mcpd.

The mcpd daemon is started when the wan is connected. So the right place to kill it should be the wan-event script.

I've created in /jffs/scripts a script named "wan-event" copying the template described here: https://www.snbforums.com/threads/wan-start-script-also-run-on-wan-stop.61295/#post-542636

Then edited the wan-event script replacing $1 argument with "0" and $2 argument with "connected". Then created a script named "wan0-connected" with the following code inside:
Code:
#!/bin/sh

killall -q -9 mcpd

Then rebooted the router. No result - the mcpd is still running. Then manually executed the wan-event script by typing in SSH terminal "/jffs/scripts/wan-event" - everything is fine and mcpd daemon has been killed.

Then unplugged and plugged again the WAN cable. The log says that the wan-event script has been ran successfully, but the mcpd daemon appeared again. Then manually executed the wan-event script as above and the mcpd daemon has been killed.

@Martineau, @RMerlin, what I am doing wrong?
 
I don't worry regarding why this happens. The problem is that this traffic floods the firewall log of very tiny Linux VM hosted by my fileserver. This VM is dedicated for one task only, resources allocated (RAM, HDD, etc.) are minimised, and constant HDD activity is not desired. So flooding the log is not accepatble at all. And for some reasons I don't want to allow this traffic in firewall rules in order to stop flooding of the log.

I also face very similar issues, but I have an additonal impact.
I have a home linux box also serving as a server for other computers. I intend to only suspend this linux box with wake on lan for unicast messages only.
These IGMP messages unfortunately wake up the server in some seconds. That is crazily energy consuming...
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top