Default X Server IP config not working, but alternate value does.

[ckeeney]

If I use the "GWSL Distro Tools" -> "Display/Audio Auto-Exporting", it adds the following lines to my profile:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0 #GWSL
export PULSE_SERVER=tcp:$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}') #GWSL

/etc/resolv.conf is a symlink to /mnt/wsl/resolv.conf, and the contents of that file are:

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 10.255.255.254
search lan

The contents of /etc/wsl.conf are:

[boot]
systemd=true

The XClock app in the about menu properly loads for me, but jetbrains-toolbox is unable to connect to my X Server.

However, when I run ipconfig from my Windows terminal, I see a Ethernet adapter vEthernet (WSL (Hyper-V firewall)): with IP 172.22.112.1. If I use this set DISPLAY to this IP, jetbrains-toolbox loads fine. However, I do not see this IP address listed when I type ifconfig from WSL, and I do not know how to otherwise find this IP address programmatically. I could hardcode the DISPLAY and PULSE_SEVER variables to this IP, and maybe that IP never changes, but this still feels kind of dirty.

I have a few questions:

• Am I supposed to be able to use my nameserver IP as my X Server IP? I see that config used in the docs as well, so I assume that is the case. GWSL was working fine for me for a long time before today, so I believe this is how I used to connect in the past but I cannot anymore.
• Is it expected that my virtual adapter IP is different from my namesever in /etc/resolv./conf
• Is there a way to programmatically get the IP of the WSL virtual adapter from within WSL?

[creinker]

I just had the same issue, and adding these lines instead to my profile fixed it for me:

export DISPLAY=$(ip route show | grep default | awk '{print $3}'):0.0
export PULSE_SERVER=tcp:$(ip route show | grep default | awk '{print $3}')

This is adapted from the solution here: https://github.com/microsoft/WSL/issues/11698#issuecomment-2172289497. Apparently a recent WSL update changed the way DNS works and /etc/resolv.conf is no longer a reliable way to get the host IP. Looks like Microsoft also recently updated their docs to reflect that.

[JosiahWI]

@ckeeney @KMohZaid Thank you for working on this, and thank you for noticing Microsoft's documentation update, @creinker. We want to make sure all guest platforms are supported, and @Pololot64 and I are concerned about the portability of the ip route command. We'd like to support all the WSL Linux guest OSs as well as FreeBSD, NetBSD, and OpenBSD guest OSs, so the change is sadly not as straightforward as fixing this for one specific system. At the bare minimum, it would be good to log an error if the ip tool is not present. It would be helpful to know which guest OSs you have tested this on.

[KMohZaid]

@ckeeney @KMohZaid Thank you for working on this, and thank you for noticing Microsoft's documentation update, @creinker. We want to make sure all guest platforms are supported, and @Pololot64 and I are concerned about the portability of the ip route command. We'd like to support all the WSL Linux guest OSs as well as FreeBSD, NetBSD, and OpenBSD guest OSs, so the change is sadly not as straightforward as fixing this for one specific system. At the bare minimum, it would be good to log an error if the ip tool is not present. It would be helpful to know which guest OSs you have tested this on.

Yes I was planning to update logging system later, also i didn't knew that ip command is not same in all linux OS

[KMohZaid]

However, when I run ipconfig from my Windows terminal, I see a Ethernet adapter vEthernet (WSL (Hyper-V firewall)): with IP 172.22.112.1. If I use this set DISPLAY to this IP, jetbrains-toolbox loads fine.

Wsl Beauty fix the issue

We can use ipconfig.exe in wsl is the way, if ip doesn't works then we can use ipconfig.exe and use sed/grep to get ip

[JosiahWI]

Good find @KMohZaid. It seems ipconfig comes with Windows, so if we can invoke that from within GWSL that's a great fallback.

I suggest we break the fix down into the following stages (separate PRs):

• [ ] Switch to ipconfig.exe which should always work. We want to add a Python function to wrap the call so all future improvements only require a change in one place.
• [ ] Try the ip route list default command before falling back on ipconfig.exe. Not needed.
• [ ] Check uname to detect BSD systems and try the appropriate route command. Not needed.

Could you make a PR for the change to use ipconfig.exe, @KMohZaid?

[Pololot64]

Be careful with ipconfig. Make sure you don't parse it in a way sensitive to regional differences. I know this method was tried in the past. It is worth testing the other solution in more distros first. Unless @JosiahWI you know that ip doesn't work for them. There may be a closed issue related to this.

Edit: see this https://github.com/Opticos/GWSL-Source/pull/9

To make sure we don't create this issue again.

[JosiahWI]

We will want to make sure not to rely on ipconfig being in PATH. The ip route command is unlikely to be available on BSDs - they use a different set of tools for network configuration.

[Pololot64]

I think ipconfig should always be in the path unless it is a misconfigured distro. Worth double checking ofc. It is easy to point to the direct location.

[KMohZaid]

Good find @KMohZaid. It seems ipconfig comes with Windows, so if we can invoke that from within GWSL that's a great fallback.

I suggest we break the fix down into the following stages (separate PRs):

• [ ] Switch to ipconfig.exe which should always work. We want to add a Python function to wrap the call so all future improvements only require a change in one place.
• [ ] Try the ip route list default command before falling back on ipconfig.exe. Perhaps we don't even need to do this; what's the advantage over the ipconfig.exe approach?
• [ ] Check uname to detect BSD systems and try the appropriate route command. Again, maybe we don't need this.

Could you make a PR for the change to use ipconfig.exe, @KMohZaid?

I can try it if I get time

[KMohZaid]

I think ipconfig should always be in the path unless it is a misconfigured distro. Worth double checking ofc. It is easy to point to the direct location.

Yes, window is sharing it's path env with wsl distro path env

[KMohZaid]

ipconfig.exe | grep -A 10 "vEthernet (WSL (Hyper-V firewall))" | grep "IPv4 Address" | sed -E 's/.*: ([0-9.]+)/\1/' OR ipconfig.exe | grep -A 10 "vEthernet (WSL (Hyper-V firewall))" | grep "IPv4 Address" | cut -d ":" -f2 | cut -d " " -f2

if ipconfig not in path variable then we can use static parth

$ which ipconfig.exe
/mnt/c/Windows/system32/ipconfig.exe

Be careful with ipconfig. Make sure you don't parse it in a way sensitive to regional differences. I know this method was tried in the past. It is worth testing the other solution in more distros first. Unless @JosiahWI you know that ip doesn't work for them. There may be a closed issue related to this.

Edit: see this #9

To make sure we don't create this issue again.

and maybe now we dont need of anything else? window ipconfig.exe will be inside its directory. If it is not their means user messed up their window directory

Edited : issue if window installation drive letter is not C: workaround can be this :

❯ ls /mnt/*/Windows/system32/ipconfig.exe
/mnt/c/Windows/system32/ipconfig.exe

~
❯ which ipconfig.exe

~
❯ ls /mnt/c/*/system32/ipconfig.exe
/mnt/c/Windows/system32/ipconfig.exe

~
❯ ls /mnt/c/*/*/ipconfig.exe
/mnt/c/Windows/System32/ipconfig.exe  /mnt/c/Windows/SysWOW64/ipconfig.exe

we can use cut to get any binary if multiple window installation is there, Or have own ipconfig.exe bundled together?

[JosiahWI]

Getting any binary is fine at this point. There should always be one, so I don't think we need to bundle our own. We might eventually want to revisit that if there are significant differences in output between versions if ipconfig.exe that inhibit parsing.

[KMohZaid]

i was and will be unable to add commits here for some time, busy with some other works (in private repo)

[JosiahWI]

This can be assigned to me.

[KMohZaid]

Appreciate

[Pololot64]

Here is my current idea for a way forward. We can add a button for exporting in the "new way". Then I can do a message on update that says "be sure to press this button if things have broken".

That might be the only way atm

[mentalisttraceur]

Btw, you can test for the ip command, and then fall back on the traditional portable netstat -rn:

if command -v ip >/dev/null
then
    DISPLAY="$(ip route show default | awk '{print $3; exit;}')"
else
    DISPLAY="$(netstat -rn | awk '/default/ { print $2; exit; }' )"
fi

Personally, I would do this rather than relying on the less-trivial-to-parse output of a Windows executable. That way you're minimizing dependencies: distro just needs its out-of-the-box standard native functionality, parsing same output format that scripts have been relying on for years (closer to half a century in the case of netstat).

But to add some technical clarity: we can confidently predict a BSD will never run in WSL. They're too non-interchangeable. Linux has an entirely different kernel from the BSDs, each has many system calls and internal details that the other doesn't, etc. The different BSDs are also less plug-and-play than Linux distros on a Linux kernel are - Microsoft can build and ship one WSL-compatible Linux kernel and layer distro's file systems on top, but BSDs are developed in a more coupled way, where their libc and stock utilities make assumptions about that BSD's current kernel, etc. So BSDs simply can't be WSL guests, due to deep technical differences, and we can forecast that none of this will ever need to work on a BSD. The only reason to not just use ip route show default and be done with it is if there's still some Linux distro that's not including ip.

[JosiahWI]

Are you all using VPNs? I think I have reproduced the issue by using a VPN on the Windows host. I think this is a prerequisite for reproducing the issue.

[Pololot64]

@ckeeney I have a question, were you using a VPN?

[Pololot64]

Whoops great minds think alike @JosiahWI

[ckeeney]

I was not using a VPN. I don't even have one I could be using on accident.

[mentalisttraceur]

I'm also not using any VPN.

[KMohZaid]

i was and will be unable to add commits here for some time, busy with some other works (in private repo)

Update : i got addicted to linux, i thought i could use window on external hdd but i can't So i will setup my new linux distro, which is NixOS, btw. And when it will be ready, I will move it to my current stable linux distro, which is Arch, btw.

So this way I will have 80gb free for window partition, than after installing window I can try and contribute to this repo

It will take time, i can't specify how much. I may also forgets about this project.

@JosiahWI appreciate if you taking over

[JosiahWI]

Thank you for the update, @KMohZaid. I am using the WSL2 OpenSUSE and have not had any issues with networking. I don't want to use more disk space to install a second WSL. Thus, I have been unable to reproduce the issue.