et -t does not accept IP address

[tsunamaru]

I'm using ET to port-forward kube-apiserver to my local machine using et -t and looks like it does not accept IP address specified like ${LOCAL_ADDR}":"${LOCAL_PORT}":"${REMOTE_ADDR}":"${REMOTE_PORT}. This is perfectly working combination with SSH, but not with ET.

Some examples:

# will listen on *:10 and forward to *:50005
et -t 10.96.0.1:50005:127.1.1.1:8443 kube-master

# will listen on *:50005 and forward to *:127
et -t 50005:127.1.1.1:8443 kube-master

# will listen on *:50005 and forward to *:8443, doesn't work for me since remote is bind to 127.1.1.1:8443
et -t 50005:8443 kube-master

SSH example:

# will listen on 10.96.0.1:50005 and forward to 127.1.1.1:8443, just as it should be
ssh -L 10.96.0.1:50005:127.1.1.1:8443 kube-master

Would be really nice to see such functionality present in EternalTerminal!

[MisterTea]

Interesting, thanks for the clear issue description. I don't believe ip addresses are supported at all. I think what's happening is the "10.96.0.1" is being passed to stoi and turned into "10", and "50005:127.1.1.1:8443" is being turned into "50005". Stoi is very tolerant of malformed numbers.

Would you be willing to write this PR? There's a few parts:

1. Change the parsing code here to accept ip addresses: https://github.com/MisterTea/EternalTerminal/blob/master/src/base/TunnelUtils.cpp#L4
2. Remove this check

   EternalTerminal/src/terminal/forwarding/PortForwardHandler.cpp

   Line 66 in 2f8dfdd

   if (sourceName != nullptr) {

3. If the name exists, use it here instead of hardcoding localhost:

   EternalTerminal/src/terminal/forwarding/PortForwardHandler.cpp

   Line 100 in 2f8dfdd

   SocketEndpoint ipv6Localhost;

[tsunamaru]

@MisterTea would love to help with PR, but sadly I don't know C++
Hope somebody can pick this up.

Do you accept bounties, by the way? If yes, I would happily sponsor implementation of this feature.

[jshort]

Looking this over. Unfortunately due to the the history of how --tunnel and --reversetunnel work (i.e. source:dest or source-range:dest-range), coming up with a syntax similar to vanilla ssh -L will likely be non-intuitive. However, the legacy behavior hinges on a single colon (":") in the cli argument so I can have this new feature request assume standard ssh -L argument semantics if there is more than one colon. Let me play around with it.