Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

cross platform ssh session not working #507

Closed
hgkamath opened this issue Mar 2, 2021 · 19 comments
Closed

cross platform ssh session not working #507

hgkamath opened this issue Mar 2, 2021 · 19 comments
Labels
bug Something isn't working ssh

Comments

@hgkamath
Copy link

hgkamath commented Mar 2, 2021

Describe the bug

Cross platform ssh not working
Attempt to do a wezterm initiated ssh session from virtualbox/fedora-33-linux-VM to host/Win10 failing

The same version of wezterm is installed on both linux and windows.
I would argue that small differences in the wezterm version should not matter, and both linux and windows should be able to interpret a terminal-data-stream of either that of linux or that of windows.

ssh-ing from inside the terminal, which does work, should not be too different from a direct wezterm initiated ssh session.

Environment (please complete the following information):

  • OS: [e.g. Linux X11, Linux Wayland, macOS, Windows]
  • Version: please run wezterm -V and include its output here
wezterm -V
wezterm 20210203-095643-70a364eb 

To Reproduce

Steps to reproduce the behavior.

  • ensure there is an ssh domain in the config
  • give command wezterm connect host-pc
  • enter password in wezterm window

Configuration

  ssh_domains = {
    {
      name="host-pc",
      remote_address="10.20.30.2",
      username="gana",
    },
  },

Be sure to include the relevant section(s) of your wezterm.lua configuration file.

Expected behavior

A clear and concise description of what you expected to happen.
Wezterm ssh from windows to linux should work
Wezterm ssh from linux to windows should work

server side logs

C:\Users\gana>E:\scoopg\apps\wezterm\current\wezterm-mux-server
 2021-03-02T05:10:42.809Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock
 2021-03-02T05:11:29.279Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: An existing connection was forcibly closed by the remote host. (os error 10054)
 2021-03-02T05:11:29.343Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

client side logs

$ wezterm connect host-pc
 2021-03-02T04:51:23.591Z WARN  mux::ssh > while attempting agent auth: [Session(-34)] no identities found in the ssh agent
 2021-03-02T04:51:25.420Z INFO  wezterm_gui::gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.4 is_context_loss_possible=false wezterm version: 20210203-095643-70a364eb
 2021-03-02T04:51:30.153Z ERROR wezterm_client::client       > going to run wezterm cli proxy
 2021-03-02T04:51:39.023Z ERROR wezterm_client::client       > ssh stderr:  2021-03-02T04:51:37.753Z ERROR wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-03-02T04:51:39.085Z ERROR wezterm_client::client       > Error while decoding response pdu: decoding a PDU: reading PDU length: Timed out waiting on socket
 2021-03-02T04:51:39.086Z ERROR wezterm_gui                  > Please install the same version of wezterm on both the client and server! The server reported error 'Error while decoding response pdu: decoding a PDU: reading PDU length: Timed out waiting on socket' while being asked for its version.  This likely means that the server is older than the client.
; terminating
 2021-03-02T04:51:39.087Z ERROR mux::connui                  > while running ConnectionUI loop: recv_timeout: channel is empty and disconnected

@hgkamath hgkamath added the bug Something isn't working label Mar 2, 2021
@wez
Copy link
Member

wez commented Mar 2, 2021

I think the messaging about the version mismatch is a mis-attributed error.

This part of the client side logs:

2021-03-02T04:51:30.153Z ERROR wezterm_client::client       > going to run wezterm cli proxy
 2021-03-02T04:51:39.023Z ERROR wezterm_client::client       > ssh stderr:  2021-03-02T04:51:37.753Z ERROR
 wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made
 because the target machine actively refused it. (os error 10061).  Will try spawning the server.

is normally where the client would launch wezterm-mux-server on your behalf. If the server was already running then that error message indicates that the client doesn't have permission to connect to the socket.

I wonder if the issue might be that wezterm-mux-server was started as an administrator and the client doesn't have access to it?

I'd suggest terminating the manually launched wezterm-mux-server and trying connecting again and see if the client error message is different.

@hgkamath
Copy link
Author

hgkamath commented Mar 2, 2021

I started wezterm-mux-server as the client logs seems to suggest I should run something on the host. I was also wanting to capture some logs on host. In the wezterm-mux-server logs given in the issue-description, the last two error lines occurred after the client was started. The wezterm-mux-server was run in a cmd prompt as the same regular user as the wezterm client used to start the wezterm ssh session

However, the wezterm ssh fails even when no wezterm or wezterm-mux-server process is started on the host. I checked in windows task-manager.
Below, is a fresh log capture on client with no wezterm-mux-server running

$ wezterm connect host-pc
 2021-03-02T12:42:39.612Z WARN  mux::ssh > while attempting agent auth: [Session(-34)] no identities found in the ssh agent
 2021-03-02T12:42:39.740Z INFO  wezterm_gui::gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.4 is_context_loss_possible=false wezterm version: 20210203-095643-70a364eb
 2021-03-02T12:42:42.259Z ERROR wezterm_client::client       > going to run wezterm cli proxy
 2021-03-02T12:42:43.750Z ERROR wezterm_client::client       > ssh stderr:  2021-03-02T12:42:42.104Z ERROR wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-03-02T12:42:43.810Z ERROR wezterm_client::client       > Error while decoding response pdu: decoding a PDU: reading PDU length: Timed out waiting on socket
 2021-03-02T12:42:43.811Z ERROR wezterm_gui                  > Please install the same version of wezterm on both the client and server! The server reported error 'Error while decoding response pdu: decoding a PDU: reading PDU length: Timed out waiting on socket' while being asked for its version.  This likely means that the server is older than the client.
; terminating
 2021-03-02T12:42:43.812Z ERROR mux::connui                  > while running ConnectionUI loop: recv_timeout: channel is empty and disconnected

captured on another run inside the cmd host

C:\Users\gana>
C:\Users\gana>
C:\Users\gana>
C:\Users\gana>dir C:\Users\gana\.local\share\wezterm\
 Volume in drive C is WINOS
 Volume Serial Number is DC21-D9A1

 Directory of C:\Users\gana\.local\share\wezterm

03/02/2021  07:42 AM    <DIR>          .
03/02/2021  07:42 AM    <DIR>          ..
02/16/2021  08:35 PM            16,897 check_update
02/10/2021  05:30 PM                 0 gui-sock-12296
02/12/2021  10:20 AM                 0 gui-sock-12684
02/04/2021  08:29 AM                 0 gui-sock-15012
02/05/2021  06:02 PM                 0 gui-sock-16072
03/02/2021  07:42 AM                 0 sock
               6 File(s)         16,897 bytes
               2 Dir(s)  11,879,034,880 bytes free

C:\Users\gana>del C:\Users\gana\.local\share\wezterm\sock

C:\Users\gana>del C:\Users\gana\.local\share\wezterm\gui-sock*

C:\Users\gana>rem wezterm ssh client is run now, password login is attempted

C:\Users\gana>dir C:\Users\gana\.local\share\wezterm\
 Volume in drive C is WINOS
 Volume Serial Number is DC21-D9A1

 Directory of C:\Users\gana\.local\share\wezterm

03/02/2021  07:53 AM    <DIR>          .
03/02/2021  07:53 AM    <DIR>          ..
02/16/2021  08:35 PM            16,897 check_update
03/02/2021  07:53 AM                 0 sock
               2 File(s)         16,897 bytes
               2 Dir(s)  11,878,375,424 bytes free

note that sock file is created.

@hgkamath
Copy link
Author

hgkamath commented Mar 4, 2021

wezterm is installed via scoop
it seems to find the wezterm socket C:\Users\gana.local\share\wezterm\sock
scoop has a wezterm shim in Scoop\shims, which is in the $env:PATH.
I tried creating an additional weaterm-mux-server shim, no difference.
When logging in via ssh, I confirmed that the shims are in the $env:PATH. The sshd is setup to login with powershell as the default shell.
I think the linux wezterm client can invoke the wezterm-mux-server on host regardless of whether the wezterm-mux-server shim is present, (with only the wezterm shim)
Don't know how it does that.

@wez wez added Windows Issue applies to Microsoft Windows and removed Windows Issue applies to Microsoft Windows labels Mar 22, 2021
wez added a commit that referenced this issue Mar 26, 2021
The wincng based build doesn't recognize newer keys which makes it
impossible to connect to a reasonably up to date Fedora installation.

This commit points to my branch of ssh2-rs that has some changes to
build ssh2 against the vendored openssl that is already part of
the dependency graph for wezterm.

refs: #507
wez added a commit that referenced this issue Mar 28, 2021
wez added a commit that referenced this issue Mar 28, 2021
@wez wez added the ssh label Mar 28, 2021
@wez
Copy link
Member

wez commented Mar 29, 2021

Could you give the latest nightly build a try? I think the main blocker was 9745a24 but there have been a number of improvements around ssh that I think will help too!

@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Mar 29, 2021
@hgkamath
Copy link
Author

hgkamath commented Mar 29, 2021

First checked with the last release (info about nightly in next comment)
windows scoop/linux rpms had both been updated.
result: same as previous release.

[gana@antares ]$ wezterm -V
wezterm 20210314-114017-04b7cedd

[gana@antares ]$ wezterm connect host-pc  
 2021-03-29T15:05:58.646Z WARN  mux::ssh > while attempting agent auth: [Session(-34)] no identities found in the ssh agent
 2021-03-29T15:05:58.817Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.5 is_context_loss_possible=false wezterm version: 20210314-114017-04b7cedd
 2021-03-29T15:06:02.610Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-03-29T15:06:09.252Z ERROR wezterm_client::client  > ssh stderr:  2021-03-29T15:06:08.418Z ERROR wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-03-29T15:06:09.312Z ERROR wezterm_client::client  > Error while decoding response pdu: decoding a PDU: reading PDU length: Timed out waiting on socket
 2021-03-29T15:06:09.317Z ERROR wezterm_gui             > Please install the same version of wezterm on both the client and server! The server reported error 'Error while decoding response pdu: decoding a PDU: reading PDU length: Timed out waiting on socket' while being asked for its version.  This likely means that the server is older than the client.
; terminating
 2021-03-29T15:06:09.317Z ERROR mux::connui             > while running ConnectionUI loop: recv_timeout: channel is empty and disconnected

@hgkamath
Copy link
Author

hgkamath commented Mar 29, 2021

!! some progress but no success

Downloaded got the nightly from https://github.com/wez/wezterm/releases/nightly
Overwrote the windows scoop app directory, Updated the VM/linux fc33 rpm

[gana@antares ]$ wezterm -V
wezterm 20210314-114017-04b7cedd-116-g1af47804

[gana@antares ]$ wezterm connect host-pc  
 2021-03-29T15:28:37.312Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.5 is_context_loss_possible=false wezterm version: 20210314-114017-04b7cedd-116-g1af47804
 2021-03-29T15:28:40.476Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-03-29T15:28:42.524Z ERROR wezterm_client::client  > ssh stderr:  2021-03-29T15:28:41.673Z ERROR wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-03-29T15:28:43.106Z ERROR wezterm_client::client  > ssh stderr:  2021-03-29T15:28:42.254Z ERROR wezterm_client::client > stdout: 
 2021-03-29T15:28:42.254Z ERROR wezterm_client::client > stderr: 

 2021-03-29T15:28:43.174Z ERROR wezterm_client::client  > ssh stderr:  2021-03-29T15:28:42.323Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock

 2021-03-29T15:28:43.445Z ERROR wezterm_client::client  > ssh stderr:  2021-03-29T15:28:42.594Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

 2021-03-29T15:28:43.553Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.5 is_context_loss_possible=false wezterm version: 20210314-114017-04b7cedd-116-g1af47804
 2021-03-29T15:28:43.749Z ERROR wezterm_client::client  > got serial 111 without a corresponding promise

Observations

  • Both windows host, linux have the same nightly version
  • Wezterm moves past the ssh login prompt with messages "Running wezterm client proxy", "Checking Server version"
  • Last fleeting message on this window is (i think) "Version check OK! requesting pane list."
  • Wezterm closes the ssh login prompt dialog-terminal window
  • Wezterm opens another regular terminal-window with a tab in it, and a + button
  • This windows remains in a regular light background (my theme) for about 9 seconds, then the terminal-region color changes to a darker shade, with an overlaid message in the top right corner, counting the seconds elapsed, "wezterm: 17s⏳since last response". I've seen the second count go upto about 450 seconds
  • Clicking the + button, is not responsive and does not open a new tab
  • In windows task manager, two additional sshd process can be seen to have been spawned. A wezterm.exe, wezterm-mux-server.exe also seen to have been spawned
  • All 4 spawned processes on windows-host die quickly soon after, if the wezterm is killed via Ctrl-C in the gnome-terminal in which it was started.

@hgkamath
Copy link
Author

hgkamath commented Mar 29, 2021

Partial success!! if wezterm-mux-server is manually prestarted.

The ssh connection from wezterm on linux, succeeds, if on the windows host-pc, I manually pre-start the wezterm-mux-server in a command window (or in a wezterm terminal window with powershell)

in windows command prompt

C:\Users\gana>wezterm-mux-server
 2021-03-29T16:12:55.493Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock
 2021-03-29T16:13:07.695Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

In linux gnome-terminal:

[gana@antares ]$ wezterm connect host-pc  
 2021-03-29T16:13:04.574Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.5 is_context_loss_possible=false wezterm version: 20210314-114017-04b7cedd-116-g1af47804
 2021-03-29T16:13:07.509Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-03-29T16:13:08.669Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.3.5 is_context_loss_possible=false wezterm version: 20210314-114017-04b7cedd-116-g1af47804
  • Clicking the + button opens a new power-shell on the remote host-pc, no relogin required
  • In a new tab ssh session, powershell session that has been started, issuing "exit" command will not automatically close the tab, but leaves a dangling terminal. However, the ctrl-shift-w key combination brings the "kill this tab and all contained panes" dialog, which seems reasonable.
  • Client if killed via ctrl-C, if restarted, will re-open all previous tabs in proper state, including dangling exitted ones.
  • Closing all opened tabs, will however, will not only close the client window, but will also terminate the wezterm-mux-server.exe process on the host, necessitating one to manually restart that again, if one wanted to reconnect. This may be unreasonable, especially, if the client was not the one to start it, and prevents future re-connection.
  • A prestarted wezterm.exe terminal without running the wezterm-mux-server.exe, on the windows host, does not help.

wez added a commit that referenced this issue Apr 3, 2021
This has been a commonly requested feature in the past week,
and it's a reasonable one.  The mux server inherited the
close-when-done behavior from when it used to be an alternate
front-end in the same executable as the gui, but it doesn't
need to be that way any more.

We also need to accomodate that case in the client: if the
newly attached domain doesn't result in any panes being imported,
we need to spawn a new command there in order to keep the client
alive.  The pre-existing check for whether the mux was empty had
false positives because the local mux may still reference the
pane from the connection UI, which would finish closing out shortly
after we had decided not to spawn anything, and then the client
would close.

refs: #631
refs: #507
@wez
Copy link
Member

wez commented May 30, 2021

Would you mind updating both the client and server to the latest nightly and let me know how things work out for you?

@wez wez added the waiting-on-op Waiting for more information from the original poster label May 30, 2021
@no-response
Copy link

no-response bot commented Jun 13, 2021

This issue has been automatically closed because there has been no response to the request for more information from the original author. With only the information that is currently in the issue, there isn't enough information to take further action. Please reach out if you have or find the answers we need so that we can investigate further.

@no-response no-response bot closed this as completed Jun 13, 2021
@hgkamath
Copy link
Author

hgkamath commented Jul 2, 2021

Same wezterm version is installed on both host-windows-10 and guest-fedora-34

wezterm -V
wezterm 20210502-154244-3f7122cb

Without wezterm mux server prestarted

[gana@antares ~]$ wezterm connect host-pc
 2021-07-02T04:01:16.925Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb
 2021-07-02T04:01:21.721Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-07-02T04:01:27.315Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:01:27.960Z WARN  wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-07-02T04:01:29.911Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:01:30.556Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock

 2021-07-02T04:01:30.251Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:01:30.895Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

 2021-07-02T04:01:30.270Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb
 2021-07-02T04:01:30.641Z ERROR wezterm_client::client  > got serial 111 without a corresponding promise

with wezterm mux-server

PS C:\Users\gana> E:\scoopg\apps\wezterm\current\wezterm-mux-server.exe
 2021-07-02T04:08:07.067Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock
 2021-07-02T04:08:26.353Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value
 2021-07-02T04:08:38.891Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: An existing connection was forcibly closed by the remote host. (os error 10054)

[gana@antares ~]$ wezterm connect host-pc
 2021-07-02T04:08:20.961Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb
 2021-07-02T04:08:24.720Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-07-02T04:08:25.730Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb

As before, the ssh connection succeeds if the wezterm-mux-server is pre-started in a cmd-window on host

@no-response no-response bot removed the waiting-on-op Waiting for more information from the original poster label Jul 2, 2021
@no-response no-response bot reopened this Jul 2, 2021
@hgkamath
Copy link
Author

hgkamath commented Jul 2, 2021

same with

wezterm -V
wezterm 20210630-133255-ba42367f

without wezterm-mux-server

[gana@antares ~]$ wezterm connect capella-pc
 2021-07-02T04:37:16.950Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:37:17.086Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:37:17.103Z WARN  wezterm_ssh::config  > ssh configuration uses options that require two-phase parsing, which isn't supported
 2021-07-02T04:37:17.270Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210630-133255-ba42367f
 2021-07-02T04:37:20.295Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-07-02T04:37:21.348Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:21.938Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:37:21.348Z ERROR wezterm_client::client  > ssh stderr: 
 2021-07-02T04:37:21.348Z ERROR wezterm_client::client  > ssh stderr: 

 2021-07-02T04:37:21.790Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:22.423Z WARN  wezterm_client::client > While connecting to C:\Users\gana\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-07-02T04:37:22.047Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:22.680Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:37:22.332Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:22.965Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:37:22.356Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:22.989Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock

 2021-07-02T04:37:22.595Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:23.228Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

 2021-07-02T04:37:22.612Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:37:23.244Z WARN  wezterm_term::terminalstate    > unhandled DecPrivateMode 9001

 2021-07-02T04:37:22.757Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210630-133255-ba42367f
 2021-07-02T04:37:22.874Z ERROR wezterm_client::client  > got serial 111 without a corresponding promise
^C

with wezterm-mux-server

C:\Users\gana>E:\scoopg\apps\wezterm\current\wezterm-mux-server.exe
 2021-07-02T05:17:05.801Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\gana\.local/share/wezterm\sock
 2021-07-02T05:17:06.060Z WARN  wezterm_term::terminalstate    > unhandled DecPrivateMode 9001
 2021-07-02T05:17:16.025Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value
After ctrl-D or killing window:
2021-07-02T05:17:33.501Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: An existing connection was forcibly closed by the remote host. (os error 10054)

[gana@antares ~]$ wezterm connect capella-pc
 2021-07-02T04:38:41.201Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:38:41.224Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of ...
 2021-07-02T04:38:41.235Z WARN  wezterm_ssh::config  > ssh configuration uses options that require two-phase parsing, which isn't supported
 2021-07-02T04:38:41.377Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210630-133255-ba42367f
 2021-07-02T04:38:43.861Z ERROR wezterm_client::client  > going to run wezterm cli proxy
 2021-07-02T04:38:44.922Z ERROR wezterm_client::client  > ssh stderr:  2021-07-02T04:38:45.514Z ERROR luahelper::serde_lua > Ignoring unknown field `font_antialias` in struct of type `Config`. Did you mean one of 
 2021-07-02T04:38:44.922Z ERROR wezterm_client::client  > ssh stderr: swap_backspace_and_delete`, 

 2021-07-02T04:38:44.979Z INFO  wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 12.0.0, 256 bits) OpenGL ES 3.2 Mesa 21.1.3 is_context_loss_possible=false wezterm version: 20210630-133255-ba42367f
[gana@antares ~]$ 

As before, the ssh connection succeeds if the wezterm-mux-server is pre-started in a cmd-window on host

  • ps. the logs also indicate that in this version there is some change with font-alias = "Subpixel" config I need to figure out what to do with it. ... replaced it with freetype_load_target = "Normal",

  • noticed that unlike before, an exit from ssh tab session, does not keep tab lingering around

  • perhaps the below needs to be filed as a separate bug

    • Start a new wezterm ssh-window wezterm connect host-pc
    • Start another new wezterm ssh-window wezterm connect host-pc , or from another local wezterm window-session, from its +button start a new wezterm ssh domain session which will open in a new tab
    • Close any one of the wezterm ssh-domain windows
    • In addition to the one window being closed, all open wezterm-ssh-domain-session-windows to that ssh-domain will be closed, but local tabs if any, may survive. If a local tab is present, only the ssh-tabs dissapear, leaving the window open with only the local-tabs
  • EVEN STRANGER, each open wezterm-ssh-domain-session-windows are mirror-clones of one-another

    • Enter a command and execute in any one window. The same command can be in real-time seen to be typed and executed in all other wezterm-ssh-domain-session-windows.
    • Start a new ssh tab in one window, identical tab is created in the other wezterm-ssh-domain-session-windows. newly created local tabs are not mirrored this way
    • I wonder what would happen if two different machines or logins initiated a wezterm-ssh-domain-session-window to the same use account on a machine, will all of them get mirror-clones. I expect that with this implementation, each machine/# will get a mirror of the same ssh domain session.
    • This is not a bad feature, it may have its uses, such as tandem troubleshooting by multiple users or simultaneous mirror terminals in multiple location. Its just that when one wants a mirror, one should explicitly ask for it by session-ID, and the person who first owns the session-ID should grant creation of the mirror.

@xiangpeng2008
Copy link

Actually how to ssh domain from Windows 10 to linux ?
I have both wezterm installed on Windows 10 and remote centos 7.
And configured SSH domain as said https://wezfurlong.org/wezterm/multiplexing.html.

But how could I launch this command wezterm connect my.server in windows ?
When I launch in wezterm of windows 10, I got
image

@hgkamath
Copy link
Author

hgkamath commented Oct 17, 2021

When applications are started from command shells, in contrast to start menu launcher shortcuts, You need to set the executable path environment variable for the OS, which is 'Path' for windows, 'PATH' for linux.
Google how to put the location (folder-path) of westerm-gui.exe or wezterm.exe in the path environment variable.
%Path% (for cmd.exe) or $env.Path (for powershell) , $PATH for bash/linux
The environment variable can be permanently set on boot in system properties

@xiangpeng2008
Copy link

xiangpeng2008 commented Oct 17, 2021

great this works
As I never used command line on Windows before, I didn't realize wezterm connect my.server means path/wezterm.exe connect my.server @ :)

@xiangpeng2008
Copy link

xiangpeng2008 commented Oct 17, 2021

It looks like wezterm imgcat doesn't work with ssh domain

wezterm-mux-server just keeps using 100% CPU with rendering image

image

If I start wezterm.exe ( without connect my.server ), and ssh to linux, then wezterm imgcat works, is this expected ?
image

@wez
Copy link
Member

wez commented Oct 17, 2021

It looks like wezterm imgcat doesn't work with ssh domain

wezterm-mux-server just keeps using 100% CPU with rendering image

image

If I start wezterm.exe ( without connect my.server ), and ssh to linux, then wezterm imgcat works, is this expected ? image

@xiangpeng2008 Could you file a separate issue for this?

@wez
Copy link
Member

wez commented Dec 5, 2021

@hgkamath would you mind giving the nightly build a try in about 45 minutes or so?
I made some changes as part of looking into #1358 that might also help with this one

@wez wez removed the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Dec 5, 2021
@hgkamath
Copy link
Author

hgkamath commented Dec 5, 2021

I'll try my best to get to it within a couple of days. presently computer in semi-configured state as I juggle disks around, trying to move above from raw partitions to vdisks. I'm also investigating switching from vbox to whpx/qemu. I'll update in this comment when I set things back up.

@wez wez closed this as completed Mar 31, 2023
@github-actions
Copy link
Contributor

github-actions bot commented May 1, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 1, 2023
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
bug Something isn't working ssh
Projects
None yet
Development

No branches or pull requests

3 participants