Significance of "received packet on lan3 with own address as source" in kernel log

Software SW help
1

I am investigating semi-regular lockup where video sessions get dropped. In my kernel log I see long runs of this form:

[123666.278754] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.289011] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.299243] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.309620] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.319863] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.330092] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.340313] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.350535] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.360753] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[123666.370972] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)
[125647.187506] net_ratelimit: 216 callbacks suppressed
[125647.187510] br-lan: received packet on lan3 with own address as source address (addr:d8:58:d7:00:43:c8, vlan:0)

Whenever a net_ratelimit message shows up it is within a run of own address as source messages.

I have confirmed that the indicated MAC address is indeed that of my Turris Omnia.

Can someone explain what these mean? Are they normal? If not then how can I track down the cause?

2

No, and neither are those healthy.

it likely indicates a loop in the network, i.e. the bridge is receiving the same packets which it is sending.

  • packet sniffing/capturing and output audit
  • check the fdb for duplicate entries bridge fdb | grep d8:58:d7
  • if VLAN is deployed check the settings
  • if the node is still on TOS3.x try with a more contemporary branch
3

I am a bit of a neophyte so not sure exactly what to do or look for re packet sniffing.

Here is the output from your bridge fdb command:

d8:58:d7:00:43:c8 dev lan0 master br-lan permanent
d8:58:d7:00:43:c8 dev lan0 vlan 1 master br-lan permanent
d8:58:d7:00:43:ca dev lan4 vlan 1 master br-lan permanent
d8:58:d7:00:43:ca dev lan4 master br-lan permanent

I have done nothing explicit re VLAN. When I search the installed software list for vlan I get no hits.

From LuCi System | Status:

TurrisOS 5.0.4 2ca5a386eeefb11de15a9b359ae2769f775d58c9
LuCI branch git-20.200.40954-91ac721

4

command line tool is tcpdump and audit tool for the created dump could be wireshark. Latter can also do a remote ssh dump.

But for that you would have to be able to narrow down the occurrence since running a dump over an extended period could be costly on the hardware.

5

are you sure there’s no loop in your network?
Logs say that lan3 receives packets that your router sends out somewhere

6

I remember that the Omnia 3.x has two internal lan ports on the cpu and if both are configured exactly the same you would get these errors as omnia would send the packets to itself. Standard was 1 port configured with vlan for wan, other configured for lan which should prevend that error

7

It definitely seems like you have a loop in the network.

8

Hi jsyjr

I get messages like this on my router two.

Do you have the package igmpproxy installed and running ? It is needed for iptv.

My provider sent me another Turris Omnia to test and make sure there was no hardware problem.

After putting the config of my router on it, no error message and no disconnection were noticed.

BUT in the evening, I saw that my tv recording system (MythTV with IPTV) could not tune and remembered, that I had had to install the igmpproxy package on the router, what I forgot to do on the test device.

After installing and enabling the igmpproxy on the router, the problems reappeared.

I have no idea at all if this could be related with the error message in the kernel logs, but enabling/disabling igmpproxy seems to have an impact.

To be honest, my smartphone also gets disconnected sometimes even when igmpproxy is disabled when connecting to the router wlan, after having “roamed” from another access point. In this case, there is no particular message in the kernel log.

As jsyjr and others are encountering the same kind problems, I hope someone will be able to narrow it down and find a solution.

PS: a Fritzbox 5490 (as a replacement for the Turris Omnia) has no problem at all on the same network