search

superfly / flyctl

Command line tools for fly.io services
https://fly.io
Apache License 2.0
1.4k stars 234 forks source link

reproduce wintun.dll missing panic #2650

Open billyb2 opened 1 year ago

billyb2 commented 1 year ago

wintun.dll is needed for userland wireguard on Windows. If the dll is missing, flyctl would panic. We observed this since the userland wg feature was released. It can be installed either in system32, or colocated with the flyctl binary. We go the colocated path to simplify installation and just bundle wintun.dll in a zip file along with the flyctl binary for distribution. This works okay, but it complicates the build/distro/install process because we can't reuse the same logic across windows/macos/linux.

I have a branch that embds wintun.dll in the binary that gets extracted when flyctl is ran. But I can't actually reproduce the panic when the dll is missing, yet fly ssh console still works. How the heck is this possible? What code path requires wintun.dll? We need to figure out how to reproduce the panic when it's missing so we know if this branch is working correctly. Once we get this sorted out we can simplify the build, distribution, installation, and update process to a single binary across all platforms.

For reference, I've tested this on a windows machine I have at home, and a Windows VM running on AWS. Tailscale also uses wintun.dll, and I have Tailscale on my home windows machine. This might explain why it's not panicing. Though I can't find wintun.dll in system32. I also can't reproduce on the VM, but maybe this is because the VM has a funky network setup that includes wintun.dll. Though again, I can't find it.

Do we actually need it?

billyb2 commented 1 year ago

So it looks like there's two types of tun devices. nativeTun, which uses wintun on windows, and netTun, which looks like it's a go native implementation of some features, without having to rely on OS support.

We never create a regular tun device, we only use the CreateNetTUN function. As for why this used to crash, I think it was due to this commit that made it so wintun is lazily loaded. This commit seems to confirm my thoughts.

As for what we're going to do about this (to simplify our build process), we plan to first embed the wintun.dll binary into flyctl, then remove it from the installer, and finally remove it from the binary (to ensure there aren't any unexpected breakages).