kernel: br0: received packet on eth0 with own address as source address

[Arbadacarba]

Feb 14 21:52:45 Jupiter kernel: br0: received packet on eth0 with own address as source address (addr:a8:a1:59:89:af:49, vlan:0)

 

I get thousands of these messages a day…

 

I’ve looked through several pages of questions on the forum, and nothing has rung true as a solution.

 

Notes:

• Running 6.10.0-rc2
• Not Bonding any NICs
• I am running pfsense in a VM, so there are mutlitple cables going from the server to the switch, but they have different IP addresses…
• No special configuration on my switch that I can find

 

Attempted so far:

• I tried shutting down the Docker and VM services… but still got them.
• I disabled bridging, and they seemed to stop, but as soon as I re-enabled bridging they were back…

 

I’m fairly close to throwing in the towel and reinstalling everything from scratch.

 

Thanks for any help

 

jupiter-syslog-20220215-0300.zip

[bonienl]

 

[Arbadacarba]

Yes, I had read that... I assumed that since the NIC was passed through to the VM (and the VM service is off) that it should not be interfering... 

 

I disconnected the two network cables that work with the pfsense box from the server (from ~420pm to 7pm) and still got that error... Along with a bunch of complaining about not having an internet connection (I assume)

 

 

 

jupiter-syslog-20220216-0022.zip

[Arbadacarba]

OK, Tried something new:

 

I reformatted the USB drive Using the Unraid USB Creator

 

Booted Fresh to a new copy of the OS with GUI and checked the logs (Attached)

jupiter-syslog-20220218-2039.zip

I also reset my Switch to factory new so there is no Port controlled VLAN

 

And Pulled the 2 port Intel Nic right out of the machine.

 

All still resulted in the error message spamming my Logs...

 

I did take a picture of the Unraid USB Creator configured for my USB drive:

 

 

 

[Arbadacarba]

OK, Much like the Poster of that thread I was sent, my problem seems to have lain with the switch... I had reset the switch, so it wasn't a change I had made... But rather a default configuration of the TP-link switch... (TL-SG1016PE)

 

I turned OFF IGMP Snooping and it seems to have stopped the error.

 

Does this make sense? MAybe it has something to do with the multiple Dockers using the same connection? (No, It happened with NO dockers installed)

 

I will take a CLOSE look at my switching tonight and make sure that I do not have a loop, but honestly, I don't think I do (It's behind my server so I can't see it easily.

[3x3q]

I've been having the exact same issue as you and others on this forum, though I'm using a TrendNet TEG-30284 managed switch. Like you, no mirroring enabled on my switch.

 

Read your follow-up post and was excited by your progress with IGMP snooping. My switch has IGMP Snooping turned OFF by default to my initial dismay. In a last ditch effort to stop this error, I turned it ON. That stopped the error. Dude, what the hell? This is the opposite of your solution, and it seems to have worked.