Hi Frank, On Wed, Oct 13, 2021 at 7:30 AM Frank Wayne <[email protected]> wrote: > >> On Tue, Oct 12, 2021 at 3:39 PM Frank Wayne <[email protected]> > >> wrote: > >> That's pretty awful. It is only possible to get the last 2048 events and > >> no way to get just the events since the last update. There is no way for > >> an aggregator to simply collect WireGuard logs on Windows. > > > Your "that's pretty awful" aside, is what you're asking for some kind of > > CLI "follow" mode that doesn't terminate and spits out logs to stdout > > perpetually? > > > Jason > > No. I'm not sure that would be much of an improvement.
Why not? It would make it possible to tail the log more easily and pipe it into whatever log collection daemon you want. And if that's indeed still not an improvement, what is the relevance of your previous mention, "It is only possible to get the last 2048 events and no way to get just the events since the last update"? I find the tone of your messages quite abrasive rather than informative. Can you slow down a bit and try to describe the constraints and requirements of your system, and then we can try to figure out what would be a good path toward realizing a good design there? Let's start with: what's missing in a tail mode that you can pipe to whatever, other than, "it's not ms event logging"? > In Linux (under systemd), kernel logs are accessible in journald, can be > forwarded to (r)syslog, and from there to a text file or external syslog or > wherever. I'm pretty sure systemd-journald epolls on /dev/kmsg. In other words, it aggregates logs from different sources. That's not a whole lot different from a follow mode, right? But why are you talking about Linux, or about kernel logs for that matter? > I can't imagine that a proprietary log format would fly in Linux, or even be > contemplated. On Linux, wireguard.ko simply uses printk, like other kernel drivers, and wg-quick(8) uses stdio, like many userspace programs. But why are you talking about Linux? What's the relevance? You've used the word "proprietary" but I think "bespoke" might be more clear. There are open source implementations in C, C#, and Go in the git repos, and it should be rather trivial to parse in any other language too. > In Windows, logs would ideally get sent to Event Logging into a WireGuard > log. That way, the user or administrator can use Event Viewer to view the > log, forward the log, or use a collector (like Splunk) to retrieve and > aggregate the events. > I'm not sure why WireGuard doesn't use Windows Event Logging. Is there > something that precludes the use of Event Logging by WireGuard? Event Logging appears to be rather slow and clunky, and I'm not sure I'd be too happy about blocking on that during packet events. It's also very cumbersome to use -- especially for things like crash dumps, which require a separate process or dll -- and the boilerplate involved doesn't look very appealing. In contrast, memory mapping a file, memcpy'ing buffers into it, and getting timestamps by reading 0x7ffe0014, means no calls to libraries or any interactions with other moving components that might be in an undefined state. Event Logging might yet be possible to use, though. But it seems to me that'd be some significant research and development work, to figuring out how it could work in a lightweight way, and also revisiting the way wgnt logs things. If this is something you'd like to work on, I'd be happy to review patches and read descriptions of a simplified event logging implementation. You're probably not the only user with this concern, and in theory I'd be open to considering it, provided there's a way to make it less clunky than initially meets the eye. Jason
