nc fails to connect the first time and then succeeds

Thomas Wolff
Tue Apr 21 16:30:18 GMT 2020

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 <> 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:
> FAQ:        
> Documentation:
> Unsubscribe info:

More information about the Cygwin mailing list