Igmpproxy creates many "own address as source address" entries in kernel log

Hi,

Just installed and enabled IGMP snooping in my router (OpenWrt 18.06.4, r7808-ef686b7292).

Since then, I've been having a lot of messages in kernel log complaining about "received packet with own address as source address":

br-lan: received packet on eth0.1 with own address as source address (addr:58:ef:68:xx:xx:xx, vlan:0)

My root FS is a SSD, so I need to avoid as much as possible too many irrelevant log entries or I can wear out the filesystem.

Any idea/suggestion?

Thanks,
Joaoabs

You seem to have a loop in your network, please share more info about your setup.

Well, although my home network is somehow complex, I don't believe I have any loops on it neither repeated MACs.

I didn't have these messages before installing igmpproxy and as a test, I uninstalled it to confirm that the messages didn't appear anymore. Therefore, I believe it should be something related with igmpproxy: Either a bug or a miss-configuration from my side (the later would be most probable).

As soon as I re-installed igmpproxy, I got the messages back again in kernel log.

My igmpproxy configuration is the standard, as per the below:

root@mojito:~# cat /etc/config/igmpproxy
config igmpproxy
        option quickleave 1
#       option verbose [0-3](none, minimal[default], more, maximum)

config phyint
        option network wan
        option zone wan
        option direction upstream
        list altnet 192.168.1.0/24

config phyint
        option network lan
        option zone lan
        option direction downstream

One detail that might be relevant is that I have two WIFI SSIDs based on the same radio. One is bridged with the WAN interface and the other is bridged with the LAN:

root@mojito:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.58ef6858cf9d       no              eth0.1
                                                        wlan0
br-wan          7fff.58ef6858cfaa       no              eth0.2
                                                        wlan0-1
root@mojito:~#

I have this setup because this way I can have a less-secure WIFI (ISP provider network) and a more-secure WIFI (behind my OpenWRT firewall). Nevertheless, with this setup I didn't have these messages before.

My WAN network is the 192.168.1.0 (br-wan) and the LAN network is the 192.168.2.0 (br-lan)

Any idea/suggestion?

Thanks,
Joaoabs

  • In default OpenWrt, the log is saved to RAM, not the HDD.
  • Nothing you showed helps identify a possible loop

Hi,

As mentioned, I doubt I have loops and/or repeated MAC addresses because the message only appears when igmpproxy is installed and it stops appearing when I uninstall it.

Regarding logs, if they are in RAM I guess I'll not have the ssd wearing problem and could survive with the annoying messages in kernel log. Running the risk of going slightly out-of-topic, how can I check if the logs are really being written into RAM and not SSD?

Thanks

Are you aware of what igmpproxy does?

It's possible the multicast is dumping onto the wrong interface via an improper bridging/config, etc. If you insist there's no issue, I'd just advise leaving it uninstalled.

1 Like

My TV Box was experiencing several freezes and the tech support told me it could be due to IGMP multicast flooding in the network. They recommended to turn on IGMP-Snooping in my switches/routers in order to minimize unneeded multicasts.

While there was a native option in my TL-SG108E switches I couldn't find it in my OpenWRT router, so I installed igmpproxy.

However, after double-checking, the IGMP Snooping option is available after all (Network --> Interfaces --> Physical Settings), even without the igmpproxy binary.

Since this is IGMP snooping is the only thing I needed, I uninstalled igmpproxy and the messages didn't appear anymore.

Thank you all

I'd try quickleave 0

There is a IGMP snooping setting, and it's unrelated to an IGMP proxy.

OK, you discovered it.

See: https://openwrt.org/docs/guide-user/base-system/basic-networking#options_valid_for_all_protocol_types

:+1: