Kernel Warning - Received packet with own address as source address

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.

If the intended effect is

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

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

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.

So I ran this command last night and got some interesting behaviour.

Firstly my logs started filling up every minute or so with the following error

 Nov 12 19:57:17 OpenWRT odhcpd Failed to send to xxxx::xxxx:xxxx:xxxx:xxxx%lan@br-lan (Permission denied)

Then I noticed that my Plume app (on Android) also started notifying me of server connection errors (which I have never seen before) and I could not monitor all my wirelessly connected devices via the Plume app (again never seen this behaviour and I've been using Plume WiFi for over 2 years). I then noticed that my laptop internet browsing wasn't as responsive (connected via WiFi to the network over Plume Superpods). So I decided to reset the router and roll back to previous best configuration. All was then well again.........

So safe to say that for my environment this command is a non-starter, but @anon98444528 thanks again for sharing - it was worth a go! I didn't check any wired devices as I only have a couple, but can only assume that it adversely affected the Plume Superpods.

For my next experiment I will try @jsyjr firewall rules as we have similar set ups and see what happens.........

1 Like

Having added @jsyjr's firewall rule and left things running for a few days, once again I had some interesting behaviour. Firstly - unfortunately this did not fix the original kernel warning issue, I actually received more than double the warning logs over a two day period (+200 per day) but I don't notice any performance degradation at all. I can't see any particular patterns over timings when the warnings are logged either - seems pretty random to the untrained eye.

The firewall rule did, however, fix another long standing irritation of mine - I have an incredibly chatty Dnsmasq which fills up my logs more than the kernel warnings. I have set option quietdhcp '1' so I only receive SIGHUP request logs from clients....... but I do get loads of them (dnsmasq re-reads /etc files every 10-15 minutes on average). With the firewall rule in place - my log files were much quieter and the only time dnsmasq re-read /etc files was on start up which is good.

So at least I now know that it's an IPv6 enabled client that is generating the SIGHUPs which will help me narrow down the search somewhat. Obviously, if anyone else has any suggestions please do put me out of my misery!!

I've now disabled the firewall rule but will keep it for on-going testing purposes so thanks for that. So I guess I will just have to systematically disconnect each device and work out what hardware is generating the warnings and SIGHUP requests. I'll have to find an appropriate time to do this over the coming week....... and will report back again.

While looking for solutions, I ran across this suggestion to avoid this by using kmod-macvlan to create and use logical interfaces in a bridge.

Details are not clear to me and I have not tried this (I suspect it won't work if the problems comes from a bridge cloning the mac address of the first interface in its definition). It's something else to try tho.

HTH

So you've cracked it!! :slight_smile:

My standard configuration is that I do not use WiFi at all on the router and turn all radios off as WiFi is served via my hardwired Plume APs.

Following the links @anon98444528 provided I got thinking that I actually don't need a bridge at all on the LAN, so to keep things simple I turned off the bridge between eth0.1 and the wireless radios and hey presto no more kernel warnings! I'm still none the wiser why any logs were being generated as the radios have always been turned off, but I'm not complaining and very happy.........

Thanks again for everyone's help and support.

Now I just need to track down those chatty clients sending SIGHUP requests over IPv6 and my logs will be clean and tidy...........

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.