Once you've configured the DISPLAY environment variable, you can easily check if it's set correctly with X410.
Start X410 in 'Floating Desktop' mode
When you start X410 in 'Floating Desktop' mode, X410 shows a colorful background. That background turns to black as soon as an X-Window client app makes a connection. You can use this behavior to easily check whether or not your DISPLAY environment variable is set correctly.
Set the DISPLAY environment variable
- Windows Subsystem for Linux (WSL)
- Hyper-V Virtual Machines
- Docker Desktop for Windows
- X11 Forwarding over SSH
Start any X-Window client app
As mentioned in Step 1, the background of X410 desktop window will be changed immediately to black and show your X-Window GUI app if the DISPLAY environment variable is set properly.
For your testing, we recommend using a simple X-Window client program such as 'xclock' or 'xcalc'. In order to use those classic X11 apps, you may need to install a software package first. For example, if you're using Ubuntu, you can use those apps after installing 'x11-apps' package.
sudo apt install x11-apps
If the DISPLAY environment variable is not configured correctly, X11 client apps cannot connect to X410 (no changes to the colorful background of X410) and display an error message such as the one shown below:
$ xcalc
Error: Can't open display: 172.19.64.1:0.0TROUBLESHOOTING
If you cannot open your X-Window client apps via X410 even after configuring the DISPLAY environment variable, try checking the followings.
If you're using X11 forwarding over SSH for your remote servers, please note that the following check points are about the local DISPLAY environment variable before you're connected to a remote server. When you use X11 forwarding over SSH, your remote SSH server automatically sets the DISPLAY environment variable for your SSH sessions; you should not alter that DISPLAY environment variable. Once you successfully configure your local DISPLAY environment variable, your X11 forwarding over SSH should also work flawlessly for any remote server.
OS platform where your X-Window client apps are running
Even if you use a Hyper-V virtual machine, you may not be able to use the VSOCK connection method depending on the version of OS kernel running in your virtual machine. So, check the capabilities of your platform and make sure it supports the connection method you're configuring the DISPLAY environment variable for.
Especially when you're configuring the DISPLAY environment variable in Windows Subsystem for Linux (WSL), check the version of WSL your Linux distro is running on. WSL has two versions, version 1 (WSL1) and version 2 (WSL2). For WSL1, you simply need to set the DISPLAY environment variable to 127.0.0.1:0.0, but you need to set the variable a bit more elaborately in WSL2. Since you can freely customize the default WSL version, your Linux distro might be running in an unexpected version of WSL. For listing and checking the WSL version for your Linux distros, you can use the following Windows command:
wsl.exe -l -vNetwork connections
If you're using TCP for connecting your X-Window client apps and X410, make sure the network in your server is working properly. Especially when you're using WSL2 or virtual machines, the virtual network provided by Windows for those environments can get corrupted unexpectedly. You can use commands like ping or traceroute from those environments to see if its Windows host (where X410 is running) is reachable.
You don't need the Internet for X410, but for quickly checking if the network is working properly, you can try the ping or traceroute command against popular websites (ex. google.com); if they are reachable, X410 should also be reachable from your X-Window client apps.
'Access Control' options in X410 Settings
You must enable the connection method you've chosen for the DISPLAY environment variable in X410 Settings. For example, if you're setting up X410 for WSL2 with TCP connections, you must have the WSL2 option selected under » in X410 Settings. You can explicitly select that option by clicking it or automatically have it selected by enabling its related option, .
DISPLAY environment variable
TCP
If you've configured the DISPLAY environment variable to dynamically extract an IP address from a system file or an external program, make sure that IP address is correctly pointing to your Windows host and usable for making connections.
For example, if you're extracting an IP address from '/etc/resolv.conf' file for WSL2, check that address against the IP address shown in ipconfig.exe in Windows Command Prompt (or PowerShell) and X410 Settings; you should see the same address in all cases.
| WSL2 | Hyper-V Virtual Machines | |
| DISPLAY environment variable |  |
 |
| ipconfig.exe |  |
 |
| X410 Settings |  |
 |
If you're familiar with nc (netcat) command, you can use it for testing the TCP connections without actually running a Linux GUI app. If you're using Ubuntu or similar, you can install it by using the following command:
sudo apt install netcatOnce you have an IP address for your Windows host as shown above, you can try connecting directly to X410 with nc. For example, let's assume that we found an IP address for Windows host as '172.30.32.1', you can then execute the following command:
nc -v 172.30.32.1 6000'6000' is the TCP port number for the display number '0' in X410. If you're using a display number '1' for X410, it becomes '6001' and so forth (= 6000 + display_number).
You should get the following message if X410 can be connected and ready for your Linux:
Connection to 172.30.32.1 6000 port [tcp/x11] succeeded!
If you're getting the following error message, there is a problem with Windows network and/or firewall settings. It could also be caused by third-party security software if you're using one. All in all, check those related settings and make sure X410 is not blocked or quarantined.
nc: connect to 172.30.32.1 port 6000 (tcp) failed: Connection refused
For additional WSL troubleshooting, check the following post from Microsoft:
VSOCK
If you're using VSOCK connections and running a data relay background program, make sure it's configured correctly.
You can also try making a direct VSOCK connection from a command-line tool. For example, if you're using Ubuntu, you can try testing VSOCK connections with ncat.
sudo apt install ncatIf X410 is configured for VSOCK at the display number '0', you can execute the following command. '2' is the address for connecting back to Windows host and '6000' is the port number for display number '0' (Please be aware of the 'verbose' switch bug in ncat version 7.8.0):
$ ncat --vsock 2 6000After executing the command, press <ENTER> key a couple of times; the background of X410 desktop window should then be turned to black as mentioned above if VSOCK connections are useable.
$ ncat --vsock 2 6000
Ncat: Connection timed out.If you're getting a timeout error, try restarting X410 after completely shutting it down. You should also check the Windows registry entries if you're using X410 with Hyper-V virtual machines.
| WSL2 | Hyper-V Virtual Machines | |
| Requires adding Windows Registry entries | No | Yes |
Windows reserved TCP port ranges
If you are using X410 over TCP connections, you should be aware that there are reserved ranges of TCP ports for Windows own use. Those TCP port ranges seem to be changing every time you restart Windows. However, when one of those ranges include the port number that X410 uses (i.e., 6000 + display_number), your Linux GUI apps cannot connect to X410 and show various error messages (ex. can't open display, connection refused etc.).
In order to check the reserved TCP port ranges, execute the following command in Windows Command Prompt (or PowerShell).
netsh int ipv4 show excludedportrange protocol=tcpIf the range list includes 6000 + display_number, try executing the following commands (requires administrator privileges) and restart the WinNAT (Windows NAT Driver) service. Windows should then reallocate its reserved TCP port ranges.
net stop winnat
net start winnat
Similar problems and their workarounds are also discussed in the following post.
Huge amount of ports are being reservedWindows Defender Firewall inbound rules
When you install X410, X410 is automatically added to Windows Defender Firewall for allowing full inbound TCP connections since you can selectively allow such connections within X410 already. However, since that configuration can be altered or removed by other software, check 'Windows Defender Firewall with Advanced Security' settings in Windows and make sure X410 is fully allowed for inbound TCP connections.
If you've additionally installed third-party security or anti-malware software, you should also check its settings and make sure it's not blocking inbound connections that are needed for X410; as VSOCK is only used for internal connections among virtual machines and their host, you should focus on checking its TCP connection firewall settings.