[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Issue #2580 revisited: Windows unclean TCP close [SEVERE]

From: Paul Charlton <techguru_at_byiq.com>
Date: Thu, 22 Oct 2009 06:52:11 -0700

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Thursday, October 22, 2009 1:51 AM
> To: Paul Charlton
> Cc: 'Bob Denny'; dev_at_subversion.tigris.org
> Subject: Re: Issue #2580 revisited: Windows unclean TCP close [SEVERE]
> On Wed, Oct 21, 2009 at 10:33:32PM -0700, Paul Charlton wrote:
> > I did read this entire thread ... the problem is the linux sshd/child
> > process, per http://tools.ietf.org/html/rfc1122#page-87, see section
> >
> > Just for kicks, also see
> >
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_t
> ermin
> > ation
> >
> > Under this situation, I would not advocate changing the windows
> > implementation to "correct" the mis-behavior of the linux sshd and
> its child
> > process.
> What would you suggest doing instead?

Fix SVNSERVE to respond correctly to the handshake it is receiving from
sshd. I am not currently set up to do the test, but anyone who is running
SSHD+SVNSERVE could run their SSHD in DEBUG mode and see what the handshake
is and where SVNSERVE is dropping the ball.

> If Bob's patch fixes the problem without causing undesired side-
> effects,
> then that's fine by me.

This problem with SVNSERVE can also manifest itself without the windows
client, and Bob's changes will not fix the other sources of the problem (for
example, when someone kills the client from the Windows Task Manager).
Fixing SVNSERVE will eliminate the whole class of problems.

More specifically, there are routers and NAT devices out there which also
can end the session with a TCP RST to the server (instead of FIN/ACK), I am
pretty sure my old NetGear NAT would do that even under legitimate
circumstance, and the RFC does permit it.

> (I'm not going to commit the patch myself simply because I cannot test
> it since I don't have a Windows machine. And I'd rather see the effects
> of what I commit with my own eyes.)
> > Also, to quote your original post -- "sshd goes into bozo mode and
> leaves
> > its svnserve subprocess running." I haven't looked into the sources,
> but if
> > I recall correctly, sshd under this circumstance is sending "SIGHUP"
> to the
> > child process (svnserve), giving it the opportunity to flush buffers
> ...
> > which would mean that svnserve is not responding correctly to
> external
> > signals.
> The default action for SIGHUP is terminating the process.
> I don't see anything in the svnserve source code overriding SIGHUP.
> Stefan
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=2410122

Received on 2009-10-22 15:52:34 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.