Kernel Warning - Received packet with own address as source address

Thank you for responding. My apologies for editing prior posts - I do that as a form of "note taking" so I can reference it later.

As described above here, my layout (at the moment) is one router and one AP. The AP connects to the router via its WAN port. The "link local" ipv6 address for eth1 (the LAN port) and br-lan are the same (see here). I'm unsure if this duplicate address is contributing to this issue but it seems likely at this point.

I have run this configuration for over a year without seeing this issue. I do have some old logs from the openwrt AP that I plan to review later today to see if the duplicate link local address was present in the past. There have been some changes to my network - I upgraded the router (a DIY ubuntu box) from 18.04 to 20.04 about 2 months ago but I have keep the same configuration there.

I do have a second, non openwrt, AP that is configured to be a drop in replacement for the openwrt r7500v2 AP currently in use (i.e. unplug the r7500v2 from the router, plug in the second AP, reboot the router and I'm good to go). Alternatively, I can "extend" my network layout by connecting this second AP to port 1 of the r7500v2 - see /etc/config/network above here.

I have used this second AP for the past 40+ days with the router (but no r7500v2) and have not observed this issue on this AP. Unfortunately, this AP is a bit different so this may not be helpful.

Then start by disconnecting the Access Point. If the problem stops, you've found your culprit.
Although as you mention later:

which makes me believe that there is something wrong with the primary AP.

That's what I think currently. Give me a day or two to look over my past logs - I might find something there. Also, after rebooting my r7500v2, I have yet to see the repetitive "own address as source address" return. I have a few ideas about how to trigger that, but I'm not sure.

Lastly, the log when this was happening indicate ipv6 ra/rs packets were on vlan:0. Do you know if vlan:0 refers to the untagged part of my trunk line?

No idea, but that sounds plausible.
It is vlan:0, not vlan0, just to be accurate.

1 Like

thanks for that. Also I, corrected a couple typo's above regarding WAN/LAN and eth0/eth1. To be clear, the br-lan and the LAN interface eth1 have duplicate link-local ipv6 address.

Reviewing some old logs, I see this has always been the case and there is always a warning about it the logs when I run the r7500v2 as an AP only.

I have also run the r7500v2 as a GW/AP (i.e. router). As a GW/AP, br-lan has an ULA ipv6 address, its "normal" ipv6 address and a duplicate link local ipv6 address on eth1 and br-lan. There are no warning in the logs about a duplicate link local address as a GW/AP - I don't understand why... but i still think the duplicate address is contributing to the issue for an AP only config.

I suspect the potential for this issue has always been present (for my AP only config) - I may have just created the right conditions to trigger it recently.

I need to "improve" my ipv6 networking knowledge if I'm going to resolve this.

fun, fun, fun

I noticed that the guest bridge and eth0 also have duplicate ipv6 link local address (lla) but there is no warning about duplicates for that in dmesg.

So... if I reorder

to

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.3 eth1.1'

I

  1. eliminate the initial warning about duplicate lla's on br-lan and eth1
  2. create a bunch of duplicate lla's now on br-lan, the guest bridge, and eth0 with no warnings about any of these duplicates in the logs.
  3. I do now see repetitive "...own address as source..." messages and it occurs every boot. e.g.
[   38.572173] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[   41.052007] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[   43.373689] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[   45.933042] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
...
[  592.502130] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[  592.502260] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[  716.336264] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[  717.775918] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
[  720.495920] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:08:59, vlan:0)
...

so yea! it is duplicate ipv6 lla's that cause this. But WTF!

When the default behavior for creating a bridge is to duplicate the MAC of the first interface defined in the config and then create a duplicate ipv6 lla from it - this feels, shall we say, less than ideal.

So now, how do I solve this? I'm going to try adding

net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.eth1.disable_ipv6 = 1

to /etc/sysctl.conf and hope that I eliminate the duplicate ipv6 lla but still have ipv6 for the bridges (and any lan, or wifi clients).

This did not stop duplicate lla's on eth0 or eth1...

EDIT this post indicates hotplug may be a way to workaround this. Note also this same post links to FS#2126 regarding openwrt lla inadequacies.

1 Like

@Ellah1 I'm not entirely sure the "cause" for my symptoms is the same as yours. I'm also not sure that my symptoms are actually the result of a mis-configuration on my router (or the AP) and perhaps these symptoms could be resolved by correcting any such mis-configuration.

Creating a hotplug script to change the bridge ipv6 lla's does not work. After a short period of no log spamming, the repetitive "'..own address as source..." messages returned.

EDIT: I plan to try using hotplug to set unique MAC address. Based on the kernel messages I saw during my other attempts, this seems related my eth1 interface. Clearly, I don't really understand why this happens.

Regardless, I'm out of time for playing with this for now and it may be awhile before I can get back to it.

Hi @nmrh,

You've really given it a good shot and sorry you've not been able to get a working solution.

I've been working with the Plume support team and ran my AP's in router mode (instead of bridge mode) for two weeks and I'm now waiting for them to release their logs to me so I can investigate further. I've now reverted my AP config and am still getting up to 100 log entries a day myself.

I'm pretty convinced the logs are harmless as previously suggested, and I haven't noticed any negative performance issues, but it's still pretty annoying not getting root cause and having to filter the warnings out of the logs..........

When I get the logs I'll update again. Good luck your side too.

Thanks for that... but it also got me thinking. I've only had an issue with this once when the br-lan bridge derived it's MAC from eth1 (the LAN). All other times that br-lan derives it's MAC from eth1, I don't have an issue (including now). In this case,

ip -6 addr show dev br-lan

showed the br-lan ipv6 lla as ...dadfailed tentative...

So instead of trying to change the ipv6 lla's I've just removed all of them from the r7500v2 AP interfaces except for the lo interface (details below). I still have ipv6 (but this needs a long term test as clients can cache an ipv6 address - something that has caused me grief in the past). Now, even if br-lan derives its MAC from eth0 I don't see any "own source as address" messages (a configuration that, for me, causes these messages from boot).

Again I consider this a kluge workaround and not really a solution. I still don't know what the problem is, but I am symptom free for the hour or two that I have tested. Also, I am not using STP on the bridges.

To remove the ipv6 lla's from the AP interfaces (including the wireless interfaces) I put the following script in /etc/hotplug.d/net (don't use the iface directory):

#!/bin/sh

#env > /tmp/envs_log.log

if [ "$ACTION" != "add" ]; then
        exit
fi

logger="/usr/bin/logger"
scope="link"

ip -6 addr flush scope "${scope}" dev eth0
ip -6 addr flush scope "${scope}" dev eth1
ip -6 addr flush scope "${scope}" dev wlan1
ip -6 addr flush scope "${scope}" dev wlan1-1
ip -6 addr flush scope "${scope}" dev wlan0
ip -6 addr flush scope "${scope}" dev wlan0-1
ip -6 addr flush scope "${scope}" dev br-lan
ip -6 addr flush scope "${scope}" dev br-guestWLAN

echo "/etc/hotplug.d/net/99-rmlla: lla's removed" | $logger

I give the script execute permissions via

chmod ugo+x /etc/hotplug.d/net/99-rmlla

It took me a while to find this thread. But once I did, it helped me resolve a very frustrating glitch that bedeviled me for at least a month. I am reviving the thread to provide a summary for anyone who, in the future, may stumble upon it.

I have a topology very similar to @Ellah1's:

 OpenWrt-based -> Luxul AMS-2624P -> Plume SuperPods x6
 Turris Omnia     managed switch     hardwired back haul

My symptoms were very parallel, including seeing 33:33:ff prefixed MAC addresses. Further, every time a nasty "own address" packet showed up, my router (or possibly my switch) went catatonic for a minimum of 3 minutes.

As best as I can tell from this thread, the issue comes down to:

  • When creating a bridge, OpenWrt's IPv6 address assignment is still a work in progress
  • Its current weakness can be exposed by IPv6 multicast traffic
  • Plume uses IPv6 multicasting (it would be interesting to know for what)

(Is that a fair characterization?)

Using LuCI, I turned off IPv6 support any and everywhere I found it. That failed to fix the problem. It was only when I added a firewall rule to drop absolutely all IPv6 packets that my network was restored to health.

(For me, banning IPv6 traffic is a viable solution because my ISP does not support IPv6.)

IPv6 uses multicast instead of broadcast. Instead of broadcasting an arp-who-has, it will send a multicast neighbor solicitation to a specific address.

@Trendy Thanks for the clarification. Had I a better grasp of IPv6 I might have solved this problem more quickly.

Hi @jsyjr - I'm glad that this topic has ultimately helped solve your issues.

I still receive around 100 errors per day, but don't really notice any performance impact that I'm aware of. I would be keen to turn off IPv6 support and test this as well. Would you mind sharing your steps to turning off IPv6 and the firewall rule you added? I've thought about doing this before as I don't use IPv6 myself but have been put off as there is never one consistent answer to turning off IPv6 in OpenWRT as far as I can find.

Thanks

Toggle ip6assign to disabled.

Thanks Trendy - I've disabled IPv6 assignment length on the LAN interface and will monitor for the next 24 hours.

That hasn't helped unfortunately (still getting the usual kernel warnings) and has caused new odhcpd warning which is presumably to be expected.

 Nov 12 15:53:00 OpenWRT netifd You have delegated IPv6-prefixes but haven't assigned them to any interface. Did you forget to set option ip6assign on your lan-interfaces?
 Nov 12 15:53:00 OpenWRT avahi-daemon Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on br-lan.*.
 Nov 12 15:53:00 OpenWRT dnsmasq read /etc/hosts - 4 addresses
 Nov 12 15:53:00 OpenWRT dnsmasq read /tmp/hosts/odhcpd - 0 addresses
 Nov 12 15:53:00 OpenWRT dnsmasq read /tmp/hosts/dhcp.cfg01411c - 27 addresses
 Nov 12 15:53:00 OpenWRT dnsmasq-dhcp read /etc/ethers - 0 addresses
 Nov 12 16:16:58 OpenWRT kernel [380868.224643] br-lan: received packet on eth0.1 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
 Nov 12 16:48:09 OpenWRT kernel [382740.241680] br-lan: received packet on eth0.1 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
 Nov 12 16:53:00 OpenWRT kernel [383030.983832] br-lan: received packet on eth0.1 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
 Nov 12 17:49:45 OpenWRT kernel [386437.538887] br-lan: received packet on eth0.1 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
 Nov 12 17:53:01 OpenWRT avahi-daemon Withdrawing address record for fd8d:xxxx:xxxx::1 on br-lan.
 Nov 12 17:53:01 OpenWRT avahi-daemon Leaving mDNS multicast group on interface br-lan.IPv6 with address fd8d:xxxx:xxxx::1.
 Nov 12 17:53:01 OpenWRT avahi-daemon Joining mDNS multicast group on interface br-lan.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
 Nov 12 17:53:02 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:00:32 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:08:08 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:11:51 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:19:00 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:25:57 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:29:27 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:39:26 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:47:32 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:53:41 OpenWRT kernel [390274.405631] br-lan: received packet on eth0.1 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
 Nov 12 18:57:21 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 18:58:30 OpenWRT kernel [390563.796831] br-lan: received packet on eth0.1 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
 Nov 12 19:06:25 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!
 Nov 12 19:13:02 OpenWRT odhcpd A default route is present but there is no public prefix on lan thus we don't announce a default route!

Sorry to hear that this is still an annoyance for you and others...

Setting IPv6 assignment length to disabled also did not work for me as indicated in my post above.

The one thing I can rely on to stop this log spam is using a command like

/sbin/ip -6 addr flush scope link dev br-lan

So far I have had no issues with ipv6 when doing this. Since you don't use ipv6, removing the ipv6 lla's or a firewall rule should be fine for you.

My hotplug script (I've since updated it a bit) is not 100% effective at removing ipv6 lla's from all ifs. For reasons unknown to me, some if's will end up with an ipv6 lla even after the script logs that they have been removed. Mostly on the wlan ifs so I think it is just artifact how openwrt configures wireless. I guess sometimes scripts in /etc/hotplug.d/net don't always get called when they get configured.

(changing the interface order in /etc/config/network as described above also can work but that was not always reliable which is how I ended up here).

HTH

AFAICT "turning off IPv6" is not a crisply defined concept. Various chunks of functionality can be individually turned on or off. But there are still large swathes of the networking stack that are expected to "just work". A perfect example being that a bridge should just work irrespective of the nature of the packet presented.

To avoid IPv6 packets ever making it to br-lan I added to /etc/firewall:

config rule
	option name 'Drop ALL IPv6 traffic'
	option src '*'
	option dest '*'
	option family 'ipv6'
	list proto 'all'
	option target 'DROP'

This rule applies in FORWARD and not INPUT.

Yes, it is self explaining.

Are you saying that it does not have the intended effect, namely preventing br-lan from seeing IPv6 packets? Or that there is a better way to achieve that effect?

I used LuCI to create the rule. My post merely described what LuCI appears to have added to my /etc/config/firewall.

Adding the rule quite definitely solved my problem. Perhaps my sense of root cause (as described previously in this thread) is flawed.