Kernel Warning - Received packet with own address as source address

Installing and Using OpenWrt
30

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

1 Like
31

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.

32

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
33

@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.

34

Hi @anon98444528,

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.

35

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
36

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

37

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

38

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

39

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

40

Toggle ip6assign to disabled.

41

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

42

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!
43

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

44

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'
45

This rule applies in FORWARD and not INPUT.

Yes, it is self explaining.

46

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.

47

If the intended effect is

then no.
If the intended effect is IPv6 packets traversing the router then yes.

48

@trendy IIUYC, you are saying that, rather than prevent packets from entering the bridge, I am preventing them from traversing the router. (In general that would indeed be overkill. In my particular instance it would be moot as my ISP does not support IPv6.)

OTOH, if you are saying that my rule does not achieve my goal of avoiding IPv6 traffic on br-lan then I am very interested in:

  • A rule that would actually avoid IPv6 on br-lan
  • Understanding why my broken rule completely solved my problem

I am always interested in learning. So if you showed me a more targeted rule I would be very grateful.

49 
config rule
	option name 'Drop ALL IPv6 traffic'
	option src 'lan' <- you can expand it to all zones with *
	option family 'ipv6'
	list proto 'all'
	option target 'DROP'

You can always try to ping6 the router and see how that will work.
But as I mentioned earlier, if you don't want IPv6 on one interface, turn it off by disabling the ip6assign. There will be no IPv6 and nothing to advertise to the lan hosts.