Windows Log Output to Event Viewer or Text File

[Jason A. Donenfeld]

Hi Frank,

On Wed, Oct 13, 2021 at 7:30 AM Frank Wayne
<frank.wayne at northwestern.edu> wrote:
> >> On Tue, Oct 12, 2021 at 3:39 PM Frank Wayne <frank.wayne at northwestern.edu> 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