Wont run on latest insider build (for WSL 2)

[myoung34]

Worked until latest version of windows (insider build for WSL 2 support)

C:\Users\3vilp\AppData\Local\wsltty\bin>ver

Microsoft Windows [Version 10.0.18917.1000]

[myoung34]

Update: reinstalled wsltty but now the error is a bit different:

[donperi]

Same issue.

[mintty]

This way of starting the wsltty-installed copy of mintty was never supposed to run. You would use the shortcut (desktop or start menu) or, from a cmd.exe, the WSL.bat script.

[myoung34]

This is from debugging post upgrade.

/bin/wslbridge: Exit 1.
wslbridge error: failed to start backend process
note: backend error output: wslbridge-backend: wslbridge-backend.cc:45: int {anonymous}::connectSocket(int, const string&): Assertion `connectRet == 0' failed.

is what happens when i run it from a .bat

Ive already opened rprichard/wslbridge#44 as a result

[binkley]

For me after migrating an Ubuntu distro to WSL 2, wsltty window opens, and closes again. I'm unsure how to get some error text to examine.

I've tried wsl.bat (same behavior), and usual way of running (same behavior) is this desktop shortcut:

%LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL= --configdir="%APPDATA%\wsltty" -~ 

[mintty]

Does "WSL 2" still work for anybody? Would anyone open an issue with WSL about broken interworking?
Is there any MS publication about what they did to break it?

[mintty]

Also, does reverting to WSL 1 fix the issue?
wsl --set-default-version 1

[Biswa96]

WSL2 works in my PC well. @mintty are you using insider builds? There are many issues that have to be fixed. I also did break it in first time. Check if DHCP Client, DNS Client and Host Network Service are running properly. This may be worth of reading https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes.

@myoung34 How did you debug wslbridge? Mine only shows wslbridge error: failed to start backend process. May you provide a lazy debugging steps (minimal works) for both frontend and backend?

[myoung34]

@Biswa96 mine shows that error as well as of yesterday

[identityope]

@mintty reverting to WSL 1 will fix the issue

[mintty]

I don't have WSL 2 yet (or the required Windows update).
What happens if you run a cmd console window and invoke wsl there - does it run inside the window as it used to, or does it open a new window (as suggested by the descriptions that they are running in a VM now)?

[myoung34]

wsl runs fine from cmd.exe, thats currently the only way to get into wsl 2.
wsltty (namely wslbridge) are just plain broken after the insider update

[therealkenc]

The diverge is that WSL2 isn't on localhost as with WSL1, so the INADDR_LOOPBACK premise wslbridge is based on no longer holds. Worse, the IP address of the vEthernet interface of the VM isn't stable.

[ed] A reasonable-ish workaround for now is to use stock mintty (Windows Git's is convenient) and then ssh.exe to the VM's IP (whatever it is at the time).

[ed2]

thats currently the only way to get into wsl 2.

Or PuTTY, or ttyd, or NCSA telnet from 1987.

[mintty]

Is any relevant information in the registry? How would wslbridge connect to its backend anyway?

[therealkenc]

Is any relevant information in the registry?

Not to the question at hand. Spitballing (and not thinking about it very hard) one could spawn wsl.exe ifconfig and parse the output of the eth0 address. You can do that on WSL1 too. Maybe as QFE you could use an environment variable (WSLTTY_IPV4ADDR) and make the user set it.

WSL2 is (to a first order) the same as a Hyper-V Linux Container on Windows. Imagine hypothetical "mintty for Windows Docker".

[mintty]

If you have an idea how to solve the issue, go ahead and try it.
Also I'd appreciate if someone reports a bug to WSL.

[therealkenc]

Also I'd appreciate if someone reports a bug to WSL.

You can track tangential #3279 although that isn't exactly on point and won't address the problem. To the extent that one flips status it would obviate the need for the bridge.

As of this writing today, the cause of the wsltty fail is by-design, analogous to WSL#4106, because WSL now has its own IP space (indeed by popular request).

This said (and complicating matters) I gather sharing 127.0.0.1 in WSL2 is being complemented. Landing zone for that will probably end up being WSL#4199. However, note if that one ever flips status, it will almost certainly be behind a flag. Because sharing localhost breaks everything that doesn't want to share Window's IP space. The killer app being Samba.

[Biswa96]

From the hint by @therealkenc

The diverge is that WSL2 isn't on localhost as with WSL1, so the INADDR_LOOPBACK premise wslbridge is based on no longer holds.

I have tried with HyperV sockets. See my hvtool project. But the problem is that cygwin does not support it, see this mail.

[mintty]

conhost --vtmode ...: Is that the trick to avoid handling the ConPty API directly?

[Biswa96]

No. Assume that as alternative of $TERM. You can find more details in microsoft/terminal. BTW, this can be used in Cygwin DLL itself. Also resizing the mintty window will not wrap text (there may be issue about this in mintty).

[therealkenc]

Also resizing the mintty window will not wrap text (there may be issue about this in mintty).

Not exactly "in mintty" per se. To do this (air quote) "right" can use the ConPTY interface and call PseudoConsoleResize(). I do this here in wslterm.

My motivation (if that's the word) for doing the pty code in a mintty fork is that mintty was patched upstream for wslbridge _anyway_and doing it all in mintty makes the solution a one-stop-shop. [Full disclosure, I also (incorrectly) thought hacking up child.c would be more trivial and a quicker path to victory.] I had a rawpty (by another name) in mind too, so you are totally on the right track.

What we're really writing here is a win32 port of socat. I call dibs on the github repo names wslcat and winsocat if I ever get around to writing it. Or Bis, feel really really encouraged to beat me to it. This is the summer so my time-sink hours are more limited. But anyway, the WSL side of wslbridge in its present form (I hate using the word 'WSL' like that because it has nothing to do with WSL) is really just socat (n.b. CLI below is typed blind off cuff):

C:\> winsocat -,raw,echo=0 tcp:localhost:3023 wsl.exe -d Ubuntu-18.04

and on the Linux side...

$ socat tcp-l:3023,reuseaddr,fork exec:/bin/bin,pty,setsid,setpgid,stderr,ctty &

Which is exactly, as the wslbridge readme says, quoth "connecting to the WSL command-line environment over TCP sockets, as with ssh, but without the overhead of configuring an SSH server".

Not that you would do it that way, because we don't need to tunnel (read: telnet) tty over tcp. Again hand-waving:

C:\> winsocat -,raw,echo=0 exec:"wsl.exe",pty,setsid,setpgid,stderr,ctty

Which is Biswa96's rawpty. Or something like that.

And as a closing note, if it isn't obvious, that should ideally be built into wsl.exe by the MSFT devs, fixing WSL#3279, and obviating the need for any this.

[mintty]

@therealkenc: I tried your mintty-conpty patch yesterday but it did not work for me.
@Biswa96: I just tried rawpty and it runs WSL. A distribution parameter is missing, and on exit it returns to cygwin only after you resize the terminal. The major problem, however, and probably caused by conpty, is that it intercepts escape sequence handling. Most character attributes do not work, most requests do not work or return conpty's own response, not mintty's, e.g. the primary device attribute: echo -e '\e[c'; echo -e '\e[>c', echo -e '\e[18t' and others do not get a response at all.

[therealkenc]

@therealkenc: I tried your mintty-conpty patch yesterday but it did not work for me.

Alright, appreciate someone trying. I think I have a guess as to the problem (I made precisely zero effort at config management let alone an installer). I'll edit this post once it is fixed.

[edit] I spun up a fresh Windows 10 1903 install in a VM and it seems to run okay here, so I'd need more deets on "did not work". I had assumed because I just blindly copied the two MSYS2 dlls maybe it was dependent on existence my own MSYS2 dev environment being present, but I guess not. I've also enabled issue submissions on the github repro. Sorry about that. I wasn't intending to obstinate; I just cloned mintty and literally never noticed they don't allow issue submissions, and my repo inherited the settings. No need for you (or anyone) to submit bug reports, mind. I don't really expect or intend wslterm to take over the world. But it would be nice to know it a least runs (and fix it if it doesn't). I'll try to get around to restoring the launch error reporting tomorrow.

[mintty]

@Biswa96, I write:

The major problem, however, and probably caused by conpty, is that it intercepts escape sequence handling. Most character attributes do not work, ...

Maybe the culprit is the ENABLE_VIRTUAL_TERMINAL_PROCESSING flags, because it enables MS's own handling of escape sequences (https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences), which is the wrong thing to do when running applications (like WSL) from a dedicated terminal.
See these issues for some background information:
rprichard/winpty#140
rprichard/winpty#89
rprichard/winpty#92

[mintty]

Test and demo file for text attributes attached.
text-attributes.txt
There are of course lots of other escapes to be checked, both directions.

I have the impression that if we use conhost, and maybe even if we use ConPTY at all, we are artifically restricted to the set of escapes that MS grants us, by handling them in their own idea of "terminal" implementation. Maybe we should request them to provide a transparent mode, passing all escapes unfiltered.

[mintty]

Maybe we should request them to provide a transparent mode, passing all escapes unfiltered.

Actually, that is microsoft/terminal#1173

[mintty]

I guess, access via ssh would work well, but you'd need to setup an ssh server first, in every WSL distribution, right? And how do you find the IP/port to connect to?

[AiOO]

I have same issue on Windows 10 18945.1001 & WSLtty 3.0.2.

Unfortunately, reverting to WSL 1 can't fix issue. 😢 <- This is my misunderstanding. Reverting command wsl --set-version <Distro> 1 is failed...

[dafa321]

wsl --set-version 1 was failed first time for me when from production to insider program,
since then has been working switch between wsl 1 & 2 or latest 18945.1001 inside update .
just make sure do a back up

[Biswa96]

Cygwin now has Windows ConPTY support. See this commit. Released in Cygwin 3.1.0-0.3 test build. So, wsl.exe and other Windows console programs can be executed directly in mintty, no need to use wslbridge or winpty related programs.

[mintty]

wsl.exe and other Windows console programs can be executed directly in mintty, no need to use wslbridge or winpty related programs.

I had tried that already and yes, it works. Unfortunately, this way wsl enforces the restricted MS terminal model, i.e. it interprets escape sequences on itw own and the result is not really mintty anymore.
I expect this problem will be resolved once MS gives us conpty "pass-through" mode.

[mintty]

@Biswa96, does either wslbridge or wslbridge2 work for you with WSL 2 as one of your comments above suggests?
According to microsoft/terminal#1173 (comment), WSL 2 does not change the way it runs in the Windows console. However, that statement is based on the assumption that grabbing the console would use ReadConsoleOutput which wslbridge does not do in fact, checking the sources. So I wonder how wslbridge actually works; how does it retrieve application output and why would that not work with WSL 2 anymore?

[mintty]

@Biswa96, in your new tool suite, hvpty apparently works as a gateway to WSL 2.
How does it achieve that? What's the difference to wslbridge2, what's the difference to rawpty?
Could wslbridge2 and hvpty be united so they work in common for both WSL 1 and WSL 2?

[Biswa96]

Could wslbridge2 and hvpty be united so they work in common for both WSL 1 and WSL 2?

Just provide a code sample about how to distinguish WSL1 and WSL2 without reading registry and any undocumented methods. There are many ways to do that with undocumented methods.

The rest of the questions are too broad. I will try to add the working procedure in project's README.

[mintty]

What undocumented methods are you aware of? I wouldn't mind reading the registry, the Flags key seems to have the indication (bit 3, mask 0x80).
As a fallback, scanning the output of wsl -l -v would work.

[mintty]

Mintty already scans the registry for option --WSL anyway. I would otherwise integrate the distinction there.

[Biswa96]

What undocumented methods are you aware of?

WslReverse is full of those.

It is hard (but not impossible) to combine wslbridge2 (for WSL1) and hvpty (for WSL2) because working principle is very different.

On the other hand rawpty is for everything.

[mintty]

Unfortunately, as I said above (#171 (comment)), rawpty does not connect WSL to mintty functionality transparently; rather it restricts the environment to the MS terminal idea. But wslbridge2 and hvpty do not do that. What's the difference?

[Biswa96]

Oooo... Now I understand your query. Remember, once I said about the idea of making a telnet + ssh like thing. wslbridge2 uses AF_INET and hvpty uses AF_HYPERV. Both uses their own backend to spawn a master/slave pty in WSL then sucks the raw buffer from slave side through sockets. See this beautiful piece of art. Whereas rawpty uses the ConPTY implementation in a "raw" way.

Also I have tested the text-attributes.txt file that you had provided before.

[mintty]

Can you add the -l option also to hvpty, please? Or rather the handling for argv[0][0] == '-'.

Also, not to break #156 again, static linking of the backend will be good.
It will require my getpwuid patch, though.

[mintty]

Furthermore, wslbridge2 does not support the special -C~ parameter value.
Also, hvpty does not have options -t (maybe not needed) and -e. -C~ not checked.

[mintty]

Released 3.0.5.

[mjbright]

I frankly didn't understand a lot of what was discussed here, but came here as I seemed to have the same problem on WSL2.

I'm on OS build [Version 10.0.19041.113].
This is the first time I've used ttyd in quite a while, I downloaded 1.6.0 and was seeing "Connection Closed".

So I just ran ttyd as
ttyd -p 1111 wsl.exe bash
and this worked fine.

I maybe missed the point of this discussion, but in case this simple workaround helps someone ...

[mintty]

So what is ttyd, where did you get if from, and what's the problem that it solves for you?

[mjbright]

Oops, sorry I hadn't realized I'd ended up on wsltty
(I'm using https://github.com/tsl0922/ttyd).