netdev - Re: scp stalls mysteriously

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0912021438030.20416@melkinpaasi.cs.helsinki.fi>
Date:	Wed, 2 Dec 2009 14:59:20 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Frederic Leroy <fredo@...rox.org>
cc:	Netdev <netdev@...r.kernel.org>, Asdo <asdo@...ftmail.org>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: scp stalls mysteriously

On Wed, 2 Dec 2009, Frederic Leroy wrote:

> Le Tue, 1 Dec 2009 22:27:01 +0200 (EET),
> "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> a écrit :
> 
> > On Tue, 1 Dec 2009, Frederic Leroy wrote:
> >
> > Thanks, I'll hopefully have some time tomorrow to go through all the
> > new ones.

Thanks for the logs. ...It is very much confirmed now that the connection 
suddently dies.

What is directly inferrable from the logs: Losses happen. RTO is triggered 
for the first time (for some reason also fast retransmit is missing and it 
most likely it should have preceeded RTO), however, the retransmission 
that RTO should make is never captured into the tcpdump. Then when RTO 
triggers for the second time, the connection silently dies immediately and 
consistently for some reason. ...From that point on resets are sent if the 
peer keeps trying.

> > Also,
> > I wonder if you have had some working (past) kernel version?
> 
> I tried a 2.6.31, and it seems to work. If it really work (connection
> don't stall everytime at the moment), I'll try to make a "git bisect"
> asap.

In one of the cases, also the sg end dies (the 4th case). I suppose that 
was running earlier kernel already?

-- 
 i.