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.
2 Likes
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