[X] Listening in another process because of copied preset

[usefulz]

Hi all!

I use 2 KiTTy sessions presets to open SSH tunnels (D8000 on one preset, D8003 on another) in separate geographical locations with different FoxyProxy rules per proxy (127.0.0.1:8000 and 127.0.0.1:8003 respectively)

I have other long-lived SSH session presets open also for things I have to keep an eye on (IRC, lab, msf, e.g.). When I connect to preset 1 (I have probably about 3 or 4 to preset 1 at any one time) I can access specific resources via proxy 127.0.0.1:8000 fine with no problems, but if I have to connect to the resource that requires proxy 127.0.0.1:8003 it hangs and times out sometimes until I taskkill, and connect only to preset 2. That is, until I taskkill /F /IM putty.exe (renamed kitty.exe to putty.exe) It's weird as well, because I can still access the resources that requires preset 1 tunnel port being active, just not preset 2. Having to kill 4 ssh windows to console a runaway server is getting rather boring. This is something that never happened with PuTTy.

Trying to do it the obvious way by duplicate session triggers this error: 2020-01-13 20:33:15 Local port 8003 SOCKS dynamic forwarding failed: Network error: Address already in use If I go to the window for session with preset 2 Right click on titlebar -> Port Forwarding It shows [C] 8003 -> D If I open up a duplicate, it shows [X] 8003 (pid?) -> D

I don't however have preset 2 open very often, so when I do connect it should have the tunnel port active in that process, but I haven't yet copied the event log on that one as it happens. I do notice though that it has an address already in use error as well.

Through process of elimination, I figured out that I must have copied (loaded, edited, saved) preset 2 onto preset 3 (which had D8003 as well and was open) and saved. Then when I have preset 3 open, and I try to open preset 2 it doesn't work because the port is already in use.

The idea of posting it as an issue is

1. as a lesson learned, hopefully will save someone some time one day :)
2. maybe label as enhancement to not let you assign local socks ports that are: a) in use already b) included in another preset

[lars18th]

Hi @usefulz ,

The management of the tunnels is a work of the user and not a responsability of the SSH client.

However, I have one suggestion for @cyd01 :

• When creating tunnels, check the listening port (local or remote) before open it. And if it's occuped, then inform to the user about it and don't open it. Futhermore, in the list of tunnels in the GUI window, please mark grayed the not openend sockets.

Regards.

[lars18th]

Hi @cyd01 ,

Please, can you consider this enhancement? More or less is a simple check before opening a listening socket and show a modal window if the opening fails.

Regards.

[lars18th]

Hi @usefulz ,

This issue is quite old. So in order to close undeed issues, I make a question to you:

• You suggest to include an improvement over the last changes regarding the port forwarding, or you're satisfied?

If not, then please, explain your idea. For example, I'm thinking on a simple modal window with a message if you connect to a server with a port forwarding enabled and if the listening socket is ocupied. This warning message will be off by default, but you can enable it if you want. You agree with this idea?

Regards.

[usefulz]

Hi @lars18th, apologies for the lateness of my reply 😅

I believe the popup message regarding the listening sock duplication should be enabled by default and when OK'd out, it should close the new window. It may be logical to have another option to select a temporary different port mapping or proceed without mapping the duplicated listening port(s) bound to the additional windows, but still proceed with SSH connection.