netdev - Re: BSD 4.2 style TCP keepalives

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]

Date:	Wed, 6 Jan 2010 15:50:55 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Rick Jones <rick.jones2@...com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	ilpo.jarvinen@...sinki.fi
Subject: Re: BSD 4.2 style TCP keepalives

On Wed, Jan 06, 2010 at 09:21:49AM -0800, Rick Jones wrote:
> David Miller wrote:
> >From: Neil Horman <nhorman@...driver.com>
> >Date: Tue, 5 Jan 2010 21:07:56 -0500
> >
> >
> >>Dave, If that patch fixes the problem (waiting on test results now,
> >>but I figure it will), what if we add a parameter to tcp_sequence
> >>(and tcp_validate_incomming), that represents an offset to trim from
> >>end_seq (so that we can effectively ignore the garbage byte)?
> >
> >
> >Sure, we could do that too, and it would be an improvement.
> >
> >Let's first wait for test results and also give a bit for
> >others to potentially come up with implementation ideas.
> 
> Might it suffice to simply enable TCP keepalives on the Linux end?
> Or is that too big a kludge?
> 
I imagine that would prevent the consequences of the problem (which is that,
after not responding to several of these older keep-alives, the connection gets
reset), but doing so requires that we know the keepalive interval configured on
the peer, and we don't normally know that.  What we need to do here is be able
to respond to these old keep alives (arguably)

Neil

> rick jones
> 
--
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