From: Stuart Henderson Subject: Re: [patch] wireguard floods dmesg To: Lloyd , Vitaliy Makkoveev , Claudio Jeker , "tech@openbsd.org" Date: Thu, 12 Dec 2024 10:24:21 +0000 On 2024/12/12 09:45, Stuart Henderson wrote: > On 2024/12/11 18:10, Lloyd wrote: > > > But it triggers probably for every portscan or similar attempt. It does > > > not report the IP addrs it does not give any useful info. So I think it is > > > not useful for anyone. > > > > On the contrary, it echos when the tunnel is down. It functions mostly as a > > "not in use" buzzer. > > > > Really the issue is that Wireguard provides no logging function for failed or > > attempted connections outside of the debugging interface. Which I am okay with, > > as long as the debugging does not flood the console with nuisance messages. > > > > Would syslog(3) be appropriate in this context? If so, could one of the link > > flags be used to enable/disable syslog function? Keeping it enabled all the time > > and sending only rejected connection attempts to syslog would be fine as well. > > syslog is possibly a little heavy for this too really. There is > dedup in syslogd, but only if the identical messages don't have other > messages in between, and syslogd disk writes result in fsync. > > I think this log message is roughly equivalent to the various *_notdb > "packets for which no TDB was found" in IPsec/ESP (netstat -s). > So actually perhaps if stats on this are useful, it might be better > done via the counters_alloc(9) mechanism and made available > to userland via a sysctl (and obviously handled in netstat for > printing). This is low impact, avoiding kernel locks for common > cases like incrementing counters, so seems like it might be a good > fit (more work to implement, but less hackish, and there are > probably other wg(4) DPRINTF that could change to using it). > > Anyway, food for thought.. > ... or kstats, which is simpler to implement (no sysctl or special handling in userland, kstat(1) looks up by name)