On Thu, Dec 12, 2024 at 10:24:21AM +0000, Stuart Henderson wrote:
> 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)

Also people could look at sppp or carp on how they do logging. For the key
events it may be good to have them in syslog.

-- 
:wq Claudio