Local companion expose port of local machine to remote machine

[0Grit]

I need to debug embedded targets that are physically connected to my local machine and or network.

The path of least resistance for the moment is to have a gdbserver listening on port 2331 waiting for a gdb client within the remote workspace to connect.

[0Grit]

@loujaybee @gtsiolis

[iQQBot]

You can use ssh port forward

[0Grit]

Working on that now.

[0Grit]

But I'm getting connection timed out

ssh -F C:Users\SomeUser\AppData\Local\Temp\gitpod_ssh_config -R 2331:localhost:2331 teal-cougar-abcdefghijk.ws-us17.gitpod.io

[iQQBot]

Host name seem error, it not contain gitpod.it

[iQQBot]

Open and check host name. C:Users\SomeUser\AppData\Local\Temp\gitpod_ssh_config

[0Grit]

[0Grit]

ssh -F C:\Users\SomeUser\AppData\Local\Temp\gitpod_ssh_config -R 2331:localhost:2331 teal-cougar-a34yifdw.ws-us17.gitpod.io

[iQQBot]

ssh -F C:\Users\SomeUser\AppData\Local\Temp\gitpod_ssh_config -R 2331:localhost:2331 teal-cougar-a34yifdw

[iQQBot]

Just use host field

[0Grit]

The GDB server I am using now fails to start after succesfully ssh forwarding the port.

[0Grit]

[iQQBot]

Wait a second

[0Grit]

Should I run this from my remote workspace?

[iQQBot]

No, only run on local machine
I run a nginx on my local machine, and open ssh forward, then run curl at workspace, it works.

maybe you need -N flag?

ssh -F C:\Users\SomeUser\AppData\Local\Temp\gitpod_ssh_config -R 2331:localhost:2331 -N teal-cougar-a34yifdw

[0Grit]

About to try. Doesn't have anything to do with the fact that I'm just trying to serve up a raw tcp socket?

[0Grit]

Just realized the original command gae me an ssh connection on the command line into the remote workspace.

[0Grit]

Still failing with -N

[iQQBot]

No, you can forward any raw tcp socket

[0Grit]

I should have the local companion open during this?

[iQQBot]

yes, you need open.

[iQQBot]

you can start GDB first then start ssh forward

[0Grit]

Will try

[0Grit]

No luck.

[iQQBot]

you can try http first , exclude the reasons
maybe gdb version incompatibility?

[ila-embsys]

I described found approach in Discord and want to repost it here because spend a lot of time getting it to works.

Companion App should be run with 'auto-tunnel=false'.

"gitpod-local-companion-windows.exe --auto-tunnel=false".
And then get SSH Remote Port Forwarding:
"ssh -R 3333:localhost:3333 -F C:\Users<SomeUser>\AppData\Local\Temp\gitpod_ssh_config "

Pay attention to run ssh with localhost cause as I understood, Companion App will proxying shh to Gitpod by itself.

Necessary to use 'auto-tunnel=false' because when Remote Port Forwarding forwards local opened port 3333 to the remote side, the function 'auto-tunnel' see that the forwarded port 3333 showed up on the remote side and it tries to open the same port 3333 on the local side again in the backward direction. But will falls cause GDB already used the same port.

Another bad case without 'auto-tunnel=false' is that GitPod remembers previously opened ports on the remote side and if try to run Companion App before GDB it opens successfully port on the local side and GDB will fall cause the port will be busy.

Also, the approach works on Linux but is broken on Windows.

[ila-embsys]

In the related issue #6247 with remote port forwarding, we have resolved another connection problem.

For future readers: "localhost" can be resolved by the system to ipv6 "::1" address. If a target application listens on the ipv4 address -- the port forwarding will not work.

In the case of embedded development, such tools like J-Link GDB and OpenOCD listens to on ipv4 address.

So, the resulting command lines should be like:

gitpod-local-companion-windows.exe --auto-tunnel=false

ssh -R 3333:127.0.0.1:3333 -F C:\Users\<user>\AppData\Local\Temp\gitpod_ssh_config  <gitpod-instanse-id>

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[loujaybee]

Spoke with a user about this today (@konne) the use case is this:

1. They are running a headed chrome inside of Gitpod (and using https://playwright.dev/)
2. They are running a headless Chrome on local to view changes made in Gitpod
3. They need some easier way to expose local port to Gitpod

I'll see if @konne is able to provide a replication of this setup, if not we can also create one to support with this issue.

[loujaybee]

Related internal document [1]

[ila-embsys]

If anyone would be interested in using from their code the described approach of opening local ports, I have a Rust library which I have used to do it.

The library can open local ports to remote GitPod instances by passing hostname of instance, ran instance ID and desired ports.

It is poorly designed. In particular, there is long blocking on some function calls. But as an idea it works and may end up helpful to someone.

[loujaybee]

Thanks for raising @0Grit !

For remote port forwarding, please see:

• [ws-proxy] SSH gateway support full channel type #10291
• SSH Gateway doesn't support remote port-forward #10248

Which should be compatible with the copy/paste SSH which you can get from the dashboard:

• https://www.gitpod.io/docs/ides-and-editors/command-line
• https://www.gitpod.io/changelog/ssh-directly-into-workspaces

A nice extension here would be to provide out of the box methods to do typical ssh -L and ssh -R commands, baked into a desktop CLI / gp cli, which is similar to the request here:

• Gitpod port control via gp-cli #9286

But that would also require:

• gp cli availble also on local computer (ssh/open workspace from desktop CLI / local app) #9287

So unless there's anything else required here, I'll close the issue 🙏

Also added some notes to:

• https://github.com/gitpod-io/website/issues/2020

To better document some local app functionalities, as described above by @ila-embsys