Message-ID: <4C88FCD4.20709@cwilson.fastmail.fm>
Date: Thu, 09 Sep 2010 11:27:16 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: RSH hangs indefinitely
References: <loom DOT 20100909T063036-735 AT post DOT gmane DOT org>
In-Reply-To: <loom.20100909T063036-735@post.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 9/9/2010 12:37 AM, 7force wrote:
> Here is the situation I have and the things I did to get it:-
> 
> 1. Initiate an RCP connection from Server A (Windows Vista) via Cygwin to Server
> B (Linux).

You haven't specified which computer is running the rsh server, and
which computer is running the rcp client.  But, it doesn't really
matter...you'd get the same behavior either way.

> 2. Disconnect the RJ45 cable to simulate a server down event (@ Server B).

This is not a "server down" event.  This is a "network disconnection"
event -- they are different.  If the "server is down", there are several
possibilities: (a) the computer is reachable via the network, but no
process (rshd) is listening on port 514/tcp (or the firewall is blocking
connection attempts with "reject") (b) the computer isn't on the network
at all (or the firewall is blocking connections with "drop").

At best, you're simulating (b), but not (a).

> This is where I notice two possibilities.
> 
> Scenario #1
> RJ45 unplug while the RCP/RSH is synchronising (used netstat). In this case, the
> session at Server A will close nicely.

Yep. This is standard protection from a SYN FLOOD attack, built in to
most modern TCP (kernel) stacks.  Without this, a bad guy could send
thousands of SYN packets to the server. The server responds to each with
a SYN/ACK, and the (half-open) connection waits in the SYN_RCVD
state...for an ACK that never arrives.  Without some sort of timeout,
this could exhaust the server's resources, at zero cost to the attacker.
 Bad news.

> Scenario #2
> RJ45 unplug after the RCP/RSH hits ESTABLISHED (used netstat). This is when the
> session at Server A will remain opened indefinitely. I have waited more than two
> hours for it to close but it's not happening yet (or ever).

So, let me make sure I understand: rcp/rsh works for you.  However, if
you physically disrupt the connection after it is ESTABLISHED (e.g.
after the SYN, SYN/ACK, ACK sequence is complete), the server continues
to listen on the socket rather than closing it.

That's...pretty much the design behavior of a TCP connection, on any
platform (unless your higher level protocol implements its own timeout
semantics and keep-alive behavior; rcp/rsh does not).

Once a connection is established, neither side will shut it down until a
FIN or RST packet (or a FIN/ACK packet) is sent from one side to the other.

If you physically disrupt the connection, then that packet can't be
sent...and the connection will not be closed.

For very simple protocols like rcp/rsh, this is what you want: if you've
rsh'ed to another computer, the terminal might just sit there with no
input for days -- and no data being transmitted between the two
computers over the connection.  You wouldn't want the server to hang up
on you.

Smarter protocols, like telnet, implement their own timeout semantics,
and the clients continually send background "keep alive" packets.  If
the server doesn't get those packets regularly, it assumes the
connection has been disrupted, and closes the socket.  But that has
nothing to do with the low-level TCP protocol (e.g. "ESTABLISHED", etc).

> Question:-
> 1. Is this a Windows issue or a Cygwin issue?

It's a TCP/IP issue. I *think* you'll see the same behavior between two
linux boxes.

> 2. How do I remedy this issue?

You don't.  Stop unplugging network cables. :-)

Oh, and use a smarter -- and more secure -- protocol.  I don't think you
will encounter this behavior with scp/ssh.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple