Received packet on eth0 with own address as source address

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.

Ok, thankyou so much, I seem to be making some progress.
For one minute in the system log I got these

Fri Feb  5 17:47:24 2021 kern.warn kernel: [191687.568386] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:25 2021 kern.warn kernel: [191688.572414] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:26 2021 kern.warn kernel: [191689.596465] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:31 2021 kern.warn kernel: [191694.760455] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:32 2021 kern.warn kernel: [191695.772514] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:33 2021 kern.warn kernel: [191696.796439] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:43 2021 kern.warn kernel: [191706.332604] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:43 2021 kern.warn kernel: [191706.343235] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:43 2021 kern.warn kernel: [191706.353472] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:47 2021 kern.warn kernel: [191710.452938] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:48 2021 kern.warn kernel: [191711.484568] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)
Fri Feb  5 17:47:49 2021 kern.warn kernel: [191712.508647] br-lan: received packet on eth0 with own address as source address (addr:dc:a6:32:f2:38:1f, vlan:0)

and in tcpdump output, for the same minute, these

tcpdump -i eth0 -evn -Q in ether src host dc:a6:32:f2:38:1f
---- beginning of minute - some earlier ones removed
17:47:24.527705 dc:a6:32:f2:38:1f > 33:33:ff:71:a3:d3, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff71:a3d3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:c069:5f8:7a71:a3d3
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:25.531728 dc:a6:32:f2:38:1f > 33:33:ff:71:a3:d3, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff71:a3d3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:c069:5f8:7a71:a3d3
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:26.555765 dc:a6:32:f2:38:1f > 33:33:ff:71:a3:d3, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff71:a3d3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:c069:5f8:7a71:a3d3
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:31.719707 dc:a6:32:f2:38:1f > 33:33:ff:71:a3:d3, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff71:a3d3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:c069:5f8:7a71:a3d3
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:32.731758 dc:a6:32:f2:38:1f > 33:33:ff:71:a3:d3, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff71:a3d3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:c069:5f8:7a71:a3d3
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:33.755676 dc:a6:32:f2:38:1f > 33:33:ff:71:a3:d3, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff71:a3d3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:c069:5f8:7a71:a3d3
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:43.291746 dc:a6:32:f2:38:1f > 33:33:ff:f2:38:1f, ethertype IPv6 (0x86dd), length 86: (hlim 1, next-header Options (0) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:fff2:381f: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:fff2:381f
17:47:43.302383 dc:a6:32:f2:38:1f > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 86: (hlim 1, next-header Options (0) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:2: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:2
17:47:43.312629 dc:a6:32:f2:38:1f > 33:33:00:01:00:03, ethertype IPv6 (0x86dd), length 86: (hlim 1, next-header Options (0) payload length: 32) fe80::dea6:32ff:fef2:381f > ff05::1:3: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener reportmax resp delay: 0 addr: ff05::1:3
17:47:47.412040 dc:a6:32:f2:38:1f > 33:33:ff:3f:89:84, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff3f:8984: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:387c:d840:583f:8984
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:48.443667 dc:a6:32:f2:38:1f > 33:33:ff:3f:89:84, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff3f:8984: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:387c:d840:583f:8984
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
17:47:49.467739 dc:a6:32:f2:38:1f > 33:33:ff:3f:89:84, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dea6:32ff:fef2:381f > ff02::1:ff3f:8984: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a00:23c4:a993:8700:387c:d840:583f:8984
          source link-address option (1), length 8 (1): dc:a6:32:f2:38:1f
---- end of minute - the rest removed
25 packets captured
3250 packets received by filter
6 packets dropped by kernel
8 packets dropped by interface

It would appear that the number of lines are the same and the timing second is the same in each,

but....

what does it mean?

Thankyou

Richard

It means that ICMPv6 NDP packets sent by your machine are reflecting back to the machine. It doesn't seem that you have an amplifying loop at least, otherwise you'd lock up your network.

I'd bet that your mesh re-meshes and when that happens you briefly have a loop. Basically benign.

1 Like

Thankyou very much - benign sounds good.

Shame about the mass of received packet on eth0 with own address as source address log messages

I think tomorrow morning early I will pull all the plugs on the APs and see if these messages disappear. If so, I suppose there is a way of filtering them from the logs, but, first things first.

Thankyou again

Richard

1 Like

yeah, that would tell you that the mesh is reflecting them. if they persist then it's the wired hardware somewhere.

1 Like