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?
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.
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?
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.
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)
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!
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.
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.
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.
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.