A glance at
https://github.com/WireGuard/wgctrl-go/blob/master/internal/wguser/parse.go#L48
seems to indicate that we treat the first "blank" line produced by
bufio.Scanner (which strips \n) as a sentinel to stop parsing, which
would mean something like "errno=0\n\n" would parse the errno and be
done once it interprets the final line "\n".
The tests seem to indicate this works as expected, but I don't regularly
develop on Windows and welcome PRs if something has changed.
- Matt
On 2/25/21 12:54 PM, Jason A. Donenfeld wrote:
+ Matt Layher
Hi Davanath,
We are trying to use wgctrl way of configuring the wireguard devices
and facing issues while creating/configuring the wireguard device on
windows.
1) First problem was while creating the wintun device using wintun.dll
and using wgctrl for configuring it. It hangs in
wgclient.ConfigureDevice api()
wgctrl works with wireguard. wireguard uses wintun, but wireguard is not wintun.
2) So tried to first create the device through wireguard.exe. And then
used wgctrl way to configure it, but wgClient.Devices() is not able to
get the devices on our test windows boxes (even though it works on my
development machine)
This sounds like a potential bug in wgctrl.
Matt -- I wonder if there's a bug in the parser, recently unearthed by
a change in wireguard-go. Specifically, uapi stipulates that requests
and responses end with \n\n. Is it possible that you're relying on the
socket to EOF, instead of looking for the \n\n? Recent wireguard-go
keeps the socket open, in case you want to send one request after
another.
Jason
