linux-kernel - RE: [PATCH 1/1] tcp: Wrong timeout for SYN segments

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]

Message-ID: <1345726283.5904.842.camel@edumazet-glaptop>
Date:	Thu, 23 Aug 2012 14:51:23 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Alex Bergmann <alex@...lab.net>,
	"H.K. Jerry Chu" <hkjerry.chu@...il.com>, davem@...emloft.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: RE: [PATCH 1/1] tcp: Wrong timeout for SYN segments

On Thu, 2012-08-23 at 13:35 +0100, David Laight wrote:
> > I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
> > 
> > 180 secs is eternity, but 31 secs is too small.
> 
> Wasn't the intention of the long delay to allow a system
> acting as a router to reboot?
> I suspect that is why it (and some other TCP timers)
> are in minutes.

One could argue that if an application really wants to connect to a
peer, it should probably handle failures and retries.

But for unaware (basic ?) applications, the 3 -> 1 change reduced by a 3
factor the timeout. So a transient network failure has now more
chance to impact them.

Not all applications run inside a browser or under human control...



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/