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