nc fails to connect the first time and then succeeds

nc fails to connect the first time and then succeeds

[Jack Adrian Zappa]

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

Re: nc fails to connect the first time and then succeeds

[Jack Adrian Zappa]

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

Re: nc fails to connect the first time and then succeeds

[Thomas Wolff]

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