Date: Thu, 29 Aug 2019 11:15:47 +0200 From: Hauke Fath <h...@spg.tu-darmstadt.de> Message-ID: <aaf18f23-70a6-cf92-605c-8c7e24b18...@spg.tu-darmstadt.de>
| I understand. But in terms of network configuration, this is a very | plain setup, just a static ip4 address. Which is why I am left puzzled... v6 is designed to autoconfigure, manually configuring something is not supposed to be needed, so if you're in an environment where v6 is available, that should be happening, unless you take steps to specifically prevent it. Since you have v4 statically configured, I will guess that you're not starting dhcpcd - if that's not running, the kernel is managing v6 autoconfig for you. Your initial message said "/var/log/messages gets spammed with..." from which I have been assuming not just one message, but many. Can you deduce from the timestamps the appoximate frequency, and perhape correlate that with the frequency of RA messages from whatever v6 enabled router is on the same (bridged, I am guessing from voif0) network link? That is, I would assume that what you're seeing is the kernel's attempt to handle the RA messages it is seeing, and if that seems plausible, it would seem like a good idea to dump one of those, something like tcpdump -vv -i voif0 -s1600 icmp6 which should result in something like: 08:16:50.680157 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c0ea:b0ff:fe55:6190 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24 hop limit 64, Flags [managed], pref low, router lifetime 30s, reachable time 0s, retrans time 0s source link-address option (1), length 8 (1): c4:6e:1f:46:e5:cc 0x0000: c46e 1f46 e5cc (perhaps other icmpv6 messages as well, which will not be relevant for this, so wait for a RA to fly past - the frequency of the log messages should give you an idea how long that might be - but allow for these messages not being synchronised, they are sent at an average interval but with randomness included in the actual gaps between messages). My current guess is that perhaps the RA is including loopback the loopback prefix as an "on link" prefix, and the kernel is actually attempting to use that, rather than rejecting it. kre