Received packet on eth0 with own address as source address

Dear all

Complete openWRT newbie here,
Raspberry Pi 4 Model B Rev 1.4
OpenWrt SNAPSHOT r15599-37752336bd / LuCI Master git-21.020.56896-af422b1
This is the community edition, very newly installed, not much altered from default settings

So I am getting many log messages (4 per min) like this:

Sat Jan 30 14:41:14 2021 kern.warn kernel: [178574.680996] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)

I can see others have had a similar problem, but I really don't know where to start trying to fix it - Suggestions please?

Thankyou

My network & ifconfig below

root@192.168.0.254:~# cat /etc/config/network
config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fddc:e703:71ce::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0'
        option proto 'static'
        option ip6assign '60'
        list ipaddr '192.168.0.254/24'
        list dns '192.168.0.60'
        list dns '8.8.8.8'
        list dns '8.8.4.4'

config interface 'wan'
        option proto 'pppoe'
        option ifname 'eth1'
        option username 'bthomehub@btbroadband.com'
        option password '****'
        option ipv6 'auto'

root@192.168.0.254:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr DC:A6:32:F2:38:1F  
          inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2a00:23c4:a993:8700::1/60 Scope:Global
          inet6 addr: fe80::dea6:32ff:fef2:381f/64 Scope:Link
          inet6 addr: fddc:e703:71ce::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15189228 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25517372 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:11885120737 (11.0 GiB)  TX bytes:30436825094 (28.3 GiB)

eth0      Link encap:Ethernet  HWaddr DC:A6:32:F2:38:1F  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15413912 errors:81 dropped:6271 overruns:0 frame:0
          TX packets:25517181 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12113781291 (11.2 GiB)  TX bytes:30436538216 (28.3 GiB)

eth1      Link encap:Ethernet  HWaddr D0:37:45:C5:59:CF  
          inet6 addr: fe80::d237:45ff:fec5:59cf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25350720 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14826207 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:30197855912 (28.1 GiB)  TX bytes:12122207885 (11.2 GiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:157912 errors:0 dropped:0 overruns:0 frame:0
          TX packets:157912 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13854632 (13.2 MiB)  TX bytes:13854632 (13.2 MiB)

pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:xx.161.203.16  P-t-P:172.xx.12.14  Mask:255.255.255.255
          inet6 addr: xx80::18fc:6aad:90aa:6e67/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:25295328 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14770808 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:29992735463 (27.9 GiB)  TX bytes:11795587442 (10.9 GiB)

wlan0     Link encap:Ethernet  HWaddr DC:A6:32:F2:38:20  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@192.168.0.254:~# 

If you are not using the wifi, remove the bridge from lan interface.

1 Like

Thanks for your help

So in luci,
network -> wireless -> overview, Device is not active / Wireless is disabled. (no change)
interfaces -> lan -> edit -> physical settings --> interface
it had eth0 and Wireless Network:Master"ap101". I removed the latter so now only eth0, and saved.

ifconfig still looks the same, and the same error is being logged.

Any other ideas?

root@192.168.0.254:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr DC:A6:32:F2:38:1F  
          inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2a00:23c4:a993:8700::1/60 Scope:Global
          inet6 addr: fe80::dea6:32ff:fef2:381f/64 Scope:Link
          inet6 addr: fddc:e703:71ce::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15322051 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25716887 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:11913564912 (11.0 GiB)  TX bytes:30593424524 (28.4 GiB)

eth0      Link encap:Ethernet  HWaddr DC:A6:32:F2:38:1F  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15550702 errors:81 dropped:6458 overruns:0 frame:0
          TX packets:25716696 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12144357651 (11.3 GiB)  TX bytes:30593137646 (28.4 GiB)

eth1      Link encap:Ethernet  HWaddr D0:37:45:C5:59:CF  
          inet6 addr: fe80::d237:45ff:fec5:59cf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25500338 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14914649 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:30319719261 (28.2 GiB)  TX bytes:12144523498 (11.3 GiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:251302 errors:0 dropped:0 overruns:0 frame:0
          TX packets:251302 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:21676954 (20.6 MiB)  TX bytes:21676954 (20.6 MiB)

pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:86.161.203.16  P-t-P:172.16.12.14  Mask:255.255.255.255
          inet6 addr: fe80::18fc:6aad:90aa:6e67/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:25444072 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14858376 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:30113363679 (28.0 GiB)  TX bytes:11815950339 (11.0 GiB)

wlan0     Link encap:Ethernet  HWaddr DC:A6:32:F2:38:20  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

reading your comment again, do you mean in
interfaces -> lan -> edit -> physical settings --> interface
I should also uncheck "Bridge interfaces" ?

Richard

1 Like

do you have multiple / smart switches downstream or fancy pi-hole redirects?

1 Like

On the wan side is a simple ethernet to the BT modem
On the lan side, is a hp managed switch, but everything at default (so really a dumb switch)
I also have a set of tp-link omada APs managed by "omada controller" on one of my servers. Basically this lets me configure all the APs centrally, and they have a mesh like behaviour. One feature of this system is a guest network which, if I try it, doesn't seem to let me see anything else on the lan, which is good, however I've not configured anything special in openWrt - could this be the problem?

Richard

1 Like

tcpdump will tell you... but my guess is something in the switching fabric ( on the lan side )... likely a looping mcast discovery packet/frame...

1 Like

ok, looking at it and will return. I will need to try to find the right filter.

Thankyou.

Richard

Either there is another device in your LAN configured with the same IP address, or a loop in your network.

1 Like

I've been messing around with tcpdump for several hours and am struggling to find the right commands. I either get nothing (eg this one) or a vast amount of stuff - 12000 lines/sec.

Could someone point me in the right direction please? I don't really know what I'm looking for.

Thanks

Richard

something like this maybe...

MYMAC="AA:BB:CC:11:22:33"
iptables -t raw -I INPUT -i br-lan -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
iptables -t raw -I PREROUTING -i br-lan -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
iptables -t raw -I INPUT -i eth0 -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
iptables -t raw -I PREROUTING -i eth0 -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "

ip6tables -I INPUT -i br-lan -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
ip6tables -t raw -I PREROUTING -i br-lan -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
ip6tables -I INPUT -i eth0 -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
ip6tables -t raw -I PREROUTING -i eth0 -m mac --mac-source $MYMAC -m limit --limit 1/min --limit-burst 3 -j LOG --log-prefix "MYMAC "
1 Like

Hmm. Having done that, this is one second from the system log

Sun Jan 31 20:56:23 2021 kern.warn kernel: [287484.548557] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Sun Jan 31 20:56:23 2021 kern.warn kernel: [287484.558800] MYMAC IN=br-lan OUT= MAC=33:33:00:01:00:02:dc:a6:32:f2:38:1f:86:dd SRC=fe80:0000:0000:0000:dea6:32ff:fef2:381f DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=72 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=131 CODE=0
Sun Jan 31 20:56:23 2021 kern.warn kernel: [287484.579292] MYMAC IN=br-lan OUT= MAC=33:33:00:01:00:02:dc:a6:32:f2:38:1f:86:dd SRC=fe80:0000:0000:0000:dea6:32ff:fef2:381f DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=72 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=131 CODE=0
Sun Jan 31 20:56:23 2021 kern.warn kernel: [287484.600022] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Sun Jan 31 20:56:23 2021 kern.warn kernel: [287484.610219] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)

What does it mean?

totally lost...

Richard

1 Like

it means...

and you'll need to read up on MLD, NS, DAD and possibly seek support from the downstream hardware vendor to properly configure your hardware.

1 Like

It might be something as simple as your switch floods multicast packets back on the port they come in on by default, and that might be benign... Or not!

1 Like

is there a way to determine if a switch does this (say by swconfig)? can it be turned off?

I've had this problem. I don't consider log spamming benign even if the other functionality of the AP is not affected by it.

There does not seem to be a unique workaround for this issue... See here, and, for my workaround, here. My workaround to delete the ipv6 lla's, while still working for me, does not work for others.

Wireshark / tcpdump would be easiest. If you see your NDP packets reflected back at you then it's happening.

1 Like

All very well saying tcpdump plus wireshark, but I've no idea how to set up the filter

Fri Feb  5 09:09:55 2021 kern.warn kernel: [160637.933240] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)

Since it appears that you can't tell what the source is because its pretending to be the router, I suppose the solution is to start pulling plugs until the error stops. For that I need to have a live feed of the error, and I suppose I can do that with tcpdump via ssh ?

But what would the filter be? Guidance most gratefully received here because my efforts so far produce thousands of lines per second and I don't really know what I'm doing, or looking for.

Thanks

Richard

The key phrase here is "mesh like behavior". A mesh can usually be considered as a virtual layer 2 bridge (or virtual unmanaged switch). The errors you are getting are typical of a mal-configured mesh ie it is (most likely) a bridge loop.
You can try the following:

uci set network.lan.stp='1'
uci commit network
service restart network

If this does not work though, it could still be the mesh..... and if it does work it won't have fixed the problem, it will have just hidden it.

1 Like

tcpdump -i eth0 -evn -Q in ether src host dc:a6:32:f2:38:1f
This is just to verify that you indeed get them.
The next step would be to identify that they are sent from OpenWrt first and they are returned from the switch/ap.

You could also look at

tcpdump -i eth0 -evn icmp6

If you are getting thousands of icmp6 packets a second something is very wrong

If you don't get enough packets you could try pinging ff02::1%eth0 which is the all nodes on this link address.