Hi Jason/Matt, I could try running any debug binaries or debug patches, that you want to run to troubleshoot the issue. Plz, advice.
Regards, Dev On Thu, Feb 25, 2021 at 12:15 PM Matt Layher <[email protected]> wrote: > > 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
