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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 2 Dec 2009 16:44:03 +0100
From:	Frederic Leroy <fredo@...rox.org>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
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, Dec 02, 2009 at 02:59:20PM +0200, Ilpo Järvinen wrote:
> 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 :
> 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.

If you want, I can add printk when a rto is made, in order to compare with tcpdump.

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

I can confirm now that 2.6.31 works well.

I made a little change during the test : 
Instead of launching scp on sg, I launched it from houba.
The scp command return then  to bash with an error, without stalling.
Which appears to me logical because the connection is killed from houba point of view.
 
> In one of the cases, also the sg end dies (the 4th case). I suppose that 
> was running earlier kernel already?

This case was the one with tcp_frto=2 and tcp_timestamps=0 on houba.

I only rebooted sg two days ago. It still 2.6.32-rc5. Nothing had been changed on this host during all tests.
tcp_frto=2
tcp_timestamps=1

-- 
Frédéric Leroy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html