> On 12 Dec 2024, at 13:37, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> 
> 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.
> 

You talk about new net.inet.wg.log sysctl?