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