resolv.conf location, slow to start

[sakai135]

About the standalone mode :

You are searching resolv.conf in /mnt/wsl/ but there is no files in this directory. resolv.conf is located in /etc/resolv.conf in my case.
The vpnkit is very low to start. Do you have an explanation ? 1 minute before the message "starting vm and gvproxy...".

sudo VMEXEC_PATH=$(pwd)/wsl-vm GVPROXY_PATH=$(pwd)/wsl-gvproxy.exe ./wsl-vpnkit
+ VPNKIT_GATEWAY_IP=192.168.127.1
+ VPNKIT_HOST_IP=192.168.127.254
+ VPNKIT_LOCAL_IP=192.168.127.2
+ TAP_MAC_ADDR=5a:94:ef:e4:0c:ee
+ VMEXEC_PATH=/lib/wsl-vpnkit/wsl-vm
+ GVPROXY_PATH=/lib/wsl-vpnkit/wsl-gvproxy.exe
+ TAP_NAME=wsltap
+ CHECK_HOST=example.com
+ CHECK_DNS=1.1.1.1
+ DEBUG=0
+ set +x
+ WSL2_TAP_NAME=eth0
+ WSL2_GATEWAY_IP=172.27.48.1
+ [ 0 -eq 0 ]
+ set +x
starting vm and gvproxy...
INFO[0000] waiting for packets...
started vm and gvproxy
check: ❌ ping fail to IPv4 WSL 2 gateway / Windows host (172.27.48.1)
check: ❌ ping fail to IPv4 Windows host (192.168.127.254)
check: ❌ ping fail to IPv4 gateway (192.168.127.1)
check: ❌ nslookup fail for example.com A using 192.168.127.1
check: ❌ nslookup fail for example.com A using 172.27.48.1
check: ❌ nslookup fail for example.com A using 1.1.1.1
time="2023-03-31T15:30:42+02:00" level=info msg="waiting for clients..."
time="2023-03-31T15:30:42+02:00" level=info msg="new connection from remote to 7184"
check: ✔️ ping success to IPv4 external host domain (example.com)
check: ✔️ ping success to IPv4 external host IP (1.1.1.1)
check: ✔️ nslookup success for example.com AAAA using 192.168.127.1
check: ✔️ nslookup success for example.com AAAA using 172.27.48.1
check: ❌ nslookup fail for example.com AAAA using 1.1.1.1
ping: example.com: Address family for hostname not supported
check: ➖ ping fail to IPv6 external host (example.com)
check: ✔️ wget success for http://example.com
check: ✔️ wget success for https://example.com

Originally posted by @adpeyre in #187 (comment)

[sakai135]

Interesting, I was under the impression that WSL always generated its main resolv.conf in /mnt/wsl/resolv.conf. Can you provide the output of wsl.exe --version?

You can override where wsl-vpnkit looks for with the env variable WSL2_RESOLVCONF.

As for the 1 min delay, it does seem like a similar issue to #176. I haven't been able to recreate the issue myself, which makes it difficult to diagnose.

[ubuergi]

Same here:

wsl --status
Standard Distribution: ubuntu-2
Standardversion: 2

Das Windows-Subsystem für Linux wurde zuletzt aktualisiert am 01.04.2023
Automatische Updates sind aktiviert.

Kernel-Version: 5.10.102.1

(pardon the German)

You can override where wsl-vpnkit looks for with the env variable WSL2_RESOLVCONF

How do you set this env var?

[adpeyre]

 wsl.exe --status
Distribution par défaut : docker-desktop-data
Version par défaut : 2

La dernière mise à jour effectuée du Sous-système Windows pour Linux date du 26/04/2022
Les mises à jour WSL automatiques sont activées.

Version du noyau : 5.10.102.1

You can override where wsl-vpnkit looks for with the env variable WSL2_RESOLVCONF.

Currently, It's not possible. Can you add the abilty to set this env variable like VMEXEC_PATH ?
For testing, I've created a symbolic link ln -s /etc/resolv.conf /mnt/wsl/resolv.conf

[sakai135]

@ubuergi @adpeyre

I'll make a release with #203 soon with a fix for this issue.

It looks like you both are using an older version of WSL. Are there any reasons that are preventing you from updating to a newer version of WSL?

[ubuergi]

Are there any reasons that are preventing you from updating to a newer version of WSL?

For me, company hardware combined with weird update policies... :\

[sakai135]

@adpeyre Can you try running the script with debug and pass it through ts to see exactly which command is taking time?

sudo VMEXEC_PATH=$(pwd)/wsl-vm GVPROXY_PATH=$(pwd)/wsl-gvproxy.exe DEBUG=1 ./wsl-vpnkit 2>&1 | ts '[%Y-%m-%d %H:%M:%S]'

Output should be something like this:

[2023-04-04 18:09:39] + VPNKIT_GATEWAY_IP=192.168.127.1
[2023-04-04 18:09:39] + VPNKIT_HOST_IP=192.168.127.254
[2023-04-04 18:09:39] + VPNKIT_LOCAL_IP=192.168.127.2
[2023-04-04 18:09:39] + TAP_MAC_ADDR=5a:94:ef:e4:0c:ee
[2023-04-04 18:09:39] + VMEXEC_PATH=/home/ubuntu/Projects/wsl-vpnkit/wsl-vm
[2023-04-04 18:09:39] + GVPROXY_PATH=/home/ubuntu/Projects/wsl-vpnkit/wsl-gvproxy.exe
[2023-04-04 18:09:39] + TAP_NAME=wsltap
[2023-04-04 18:09:39] + CHECK_HOST=example.com
[2023-04-04 18:09:39] + CHECK_DNS=1.1.1.1
[2023-04-04 18:09:39] + DEBUG=1
[2023-04-04 18:09:39] + set +x
[2023-04-04 18:09:39] + WSL2_TAP_NAME=eth0
[2023-04-04 18:09:39] + WSL2_GATEWAY_IP=172.27.224.1
[2023-04-04 18:09:39] + [ 1 -eq 0 ]
[2023-04-04 18:09:39] + command -v iptables-legacy
[2023-04-04 18:09:39] + alias iptables=iptables-legacy
[2023-04-04 18:09:39] + id -u
[2023-04-04 18:09:39] + [ 0 -ne 0 ]
[2023-04-04 18:09:39] + [ ! -f /home/ubuntu/Projects/wsl-vpnkit/wsl-vm ]
[2023-04-04 18:09:39] + [ ! -f /home/ubuntu/Projects/wsl-vpnkit/wsl-gvproxy.exe ]
[2023-04-04 18:09:39] + + grep automatically generated by WSL
[2023-04-04 18:09:39] cat /mnt/wsl/resolv.conf
[2023-04-04 18:09:39] + [ 0 -eq 1 ]
[2023-04-04 18:09:39] + /home/ubuntu/Projects/wsl-vpnkit/wsl-gvproxy.exe -help
[2023-04-04 18:09:39] + [ 0 -eq 1 ]
[2023-04-04 18:09:39] + trap close exit
[2023-04-04 18:09:39] + trap exit int term
[2023-04-04 18:09:39] + cleanup
[2023-04-04 18:09:39] + iptables_set D
[2023-04-04 18:09:39] + wsl2tap_up
[2023-04-04 18:09:39] + ip link set dev wsltap down
[2023-04-04 18:09:39] + ip tuntap del wsltap mode tap
[2023-04-04 18:09:39] + ip route add default via 172.27.224.1 dev eth0
[2023-04-04 18:09:39] + wsl2tap_down
[2023-04-04 18:09:39] + ip route del default
[2023-04-04 18:09:39] + ip tuntap add wsltap mode tap
[2023-04-04 18:09:39] + ip link set dev wsltap address 5a:94:ef:e4:0c:ee
[2023-04-04 18:09:39] + ip link set dev wsltap up
[2023-04-04 18:09:39] + ip addr add 192.168.127.2/255.255.255.0 dev wsltap
[2023-04-04 18:09:39] + ip route add default via 192.168.127.1 dev wsltap
[2023-04-04 18:09:39] + run
[2023-04-04 18:09:39] + echo starting vm and gvproxy...
[2023-04-04 18:09:39] starting vm and gvproxy...
[2023-04-04 18:09:39] + sleep 1
[2023-04-04 18:09:39] + /home/ubuntu/Projects/wsl-vpnkit/wsl-vm -url=stdio:/home/ubuntu/Projects/wsl-vpnkit/wsl-gvproxy.exe?listen-stdio=accept&debug=1 -iface=wsltap -stop-if-exist= -preexisting=1 -debug=1

[adpeyre]

@sakai135 The script is waiting 1 minute on /lib/wsl-vpnkit/wsl-gvproxy.exe -help Why ?

[2023-04-05 10:06:36] + grep automatically generated by WSL
[2023-04-05 10:06:36] + [ 0 -eq 1 ]
[2023-04-05 10:06:36] + /lib/wsl-vpnkit/wsl-gvproxy.exe -help
[2023-04-05 10:07:36] + [ 0 -eq 1 ]
[2023-04-05 10:07:36] + trap close exit

Then, the connectivity takes a long time.

VMEXEC_PATH=$(pwd)/wsl-vm GVPROXY_PATH=$(pwd)/wsl-gvproxy.exe ./wsl-vpnkit 2>&1 | ts '[%Y-%m-%d %H:%M:%S]'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
[2023-04-05 10:19:33] + VPNKIT_GATEWAY_IP=192.168.127.1
[2023-04-05 10:19:33] + VPNKIT_HOST_IP=192.168.127.254
[2023-04-05 10:19:33] + VPNKIT_LOCAL_IP=192.168.127.2
[2023-04-05 10:19:33] + TAP_MAC_ADDR=5a:94:ef:e4:0c:ee
[2023-04-05 10:19:33] + VMEXEC_PATH=/lib/wsl-vpnkit/wsl-vm
[2023-04-05 10:19:33] + GVPROXY_PATH=/lib/wsl-vpnkit/wsl-gvproxy.exe
[2023-04-05 10:19:33] + TAP_NAME=wsltap
[2023-04-05 10:19:33] + CHECK_HOST=example.com
[2023-04-05 10:19:33] + CHECK_DNS=1.1.1.1
[2023-04-05 10:19:33] + DEBUG=0
[2023-04-05 10:19:33] + set +x
[2023-04-05 10:19:33] + WSL2_TAP_NAME=eth0
[2023-04-05 10:19:33] + WSL2_GATEWAY_IP=172.25.144.1
[2023-04-05 10:19:33] + [ 0 -eq 0 ]
[2023-04-05 10:19:33] + set +x
[2023-04-05 10:19:33] starting vm and gvproxy...
[2023-04-05 10:19:33] time="2023-04-05T10:19:33+02:00" level=info msg="waiting for packets..."
[2023-04-05 10:19:34] started vm and gvproxy
[2023-04-05 10:19:37] check: ❌ ping fail to IPv4 WSL 2 gateway / Windows host (172.25.144.1)
[2023-04-05 10:19:40] check: ❌ ping fail to IPv4 Windows host (192.168.127.254)
[2023-04-05 10:19:43] check: ❌ ping fail to IPv4 gateway (192.168.127.1)
[2023-04-05 10:19:58] check: ❌ nslookup fail for example.com A using 192.168.127.1
[2023-04-05 10:20:13] check: ❌ nslookup fail for example.com A using 172.25.144.1
[2023-04-05 10:20:28] check: ❌ nslookup fail for example.com A using 1.1.1.1
[2023-04-05 10:20:33] time="2023-04-05T10:20:33+02:00" level=info msg="waiting for clients..."
[2023-04-05 10:20:33] time="2023-04-05T10:20:33+02:00" level=info msg="new connection from remote to 19416"
[2023-04-05 10:20:33] check: ✔️ ping success to IPv4 external host domain (example.com)
[2023-04-05 10:20:33] check: ✔️ ping success to IPv4 external host IP (1.1.1.1)
[2023-04-05 10:20:33] check: ✔️ nslookup success for example.com AAAA using 192.168.127.1
[2023-04-05 10:20:33] check: ✔️ nslookup success for example.com AAAA using 172.25.144.1
[2023-04-05 10:20:48] check: ❌ nslookup fail for example.com AAAA using 1.1.1.1
[2023-04-05 10:20:48] ping: example.com: Address family for hostname not supported
[2023-04-05 10:20:48] check: ➖ ping fail to IPv6 external host (example.com)
[2023-04-05 10:20:49] check: ✔️ wget success for http://example.com
[2023-04-05 10:20:49] check: ✔️ wget success for https://example.com

In the previous release, it worked well with these 2 changes : #180 (comment)

[sakai135]

@adpeyre Can you try and compare how long it takes to run wsl-gvproxy.exe with the exe in WSL and in Windows?

• $(pwd)/wsl-gvproxy.exe -help
• /mnt/c/somewhere/wsl-gvproxy.exe -help (after copying wsl-gvproxy.exe to C:\somewhere)

might be related to microsoft/WSL#8943

[adpeyre]

Yes @sakai135 . I confirm that you said. /mnt/c/somewhere/wsl-gvproxy.exe -help instantly works.
So at this time, this command works :
VMEXEC_PATH=$(pwd)/wsl-vm GVPROXY_PATH=/mnt/c/Users/.../wsl-gvproxy.exe ./wsl-vpnkit. The service starts in 2 seconds.

[kmj251]

Another thing to think about is that in WSL2_RESOLVCONF="/mnt/wsl/resolv.conf". /mnt/ is the default value for the root variable in /etc/wsl.conf. So, if wsl-vpnkit looked at the /etc/wsl.conf file to get the "root" path, it could be a unique way to solve this problem WSL2_RESOLVCONF="$(awk -F'=' '/root/{print $2}' /etc/wsl.conf)wsl/resolv.conf"

[Alchobashko]

@sakai135 I had similar issue but debugging looks different.
After check: ✔️ wget success for https://example.com it hangs.
I can upload .txt debug output if you can take a look at [it?]
For me it seems that there is normal communication going.
wsl-vpnkit debug.txt

Thanks!