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)