From: Stuart Henderson Subject: Re: [patch] wireguard floods dmesg To: Lloyd Cc: Vitaliy Makkoveev , Claudio Jeker , "tech@openbsd.org" Date: Thu, 12 Dec 2024 09:45:47 +0000 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..