Please don't "top-post".
Am 21.04.2020 um 17:14 schrieb Jack Adrian Zappa via Cygwin:
Nm. I figured it out. Seems if you don't specify what type of
listener, it'll default to IP4. When you create a sender, it'll try
first using IP6 and then fall back to IP4. It's that first connection
that is causing the failure. If you specify the listener to use IP6,
then it works fine.
OK, but what's the solution? How do you specify that in your scenario?
Thanks,
A
On Tue, Apr 21, 2020 at 3:48 AM Jack Adrian Zappa <adrianh....@gmail.com> wrote:
I was trying to do some testing of a ssh port forwarding issue I was
having, by trying to reduce the problem into something simpler. So I
reached for netcat (nc). Turns out that when trying to connect a
listener to a sender directly, it will fail first and then succeed.
Example:
In terminal 1 we do:
$ nc -l 1234
nc waits. In terminal 2 we do:
$ nc -v localhost 1234
nc: connect to localhost port 1234 (tcp) failed: Connection refused
Connection to localhost 1234 port [tcp/*] succeeded!
The initial failure is fine when connecting directly, but this failure
is disastrous when connecting through an ssh connection. This is
because when the sshd connects to the nc listener, it will first fail
and then succeed. However, that first failure makes the sshd think
that there is no connection to be had and just closes the tunnel,
making the nc sender just terminate.
Is this a coding error or somehow by design? If by design, then why?
If by error, then when can we expect this to be fixed?
Thanks,
Adrian
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple