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.
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
