Re: conntrack, idle TCP connection and keep-alives

[Patrick McHardy <kaber@trash.net>]

On Sun, Oct 27, 2013 at 09:49:47PM +0100, Jozsef Kadlecsik wrote:
> On Sun, 27 Oct 2013, Jozsef Kadlecsik wrote:
> 
> > On Sun, 27 Oct 2013, Patrick McHardy wrote:
> > 
> > > On Sun, Oct 27, 2013 at 07:32:44PM +0000, Patrick McHardy wrote:
> > > > On Sun, Oct 27, 2013 at 11:23:17PM +0400, WGH wrote:
> > > > > On 27.10.2013 23:20, Patrick McHardy wrote:
> > > > > > On Sun, Oct 27, 2013 at 08:14:19PM +0100, Jozsef Kadlecsik wrote:
> > > > > >> I think a single flag could be sufficient: if the timer in conntrack goes 
> > > > > >> off and the entry is in the ESTABLISHED state and this flag is not set, 
> > > > > >> then send a TCP keepalive packet and start the timer with a short timeout. 
> > > > > >> If we receive the reply packet, then the long ESTABLISHED timeout value 
> > > > > >> can be restored and the flag cleared.
> > > > > > Sure, I think we wouldn't even need that flag, we can just send the keepalive
> > > > > > and set a short timeout. If a RST is received, the connection is killed
> > > > > > anyway, otherwise it will be refreshed with the ESTABLISHED timeout.
> > > > > >
> > > > > > But we do need a timestamp value to pass PAWS.
> > > > > I believe you forgot the third scenario: neither ACK nor RST is received
> > > > > in reply.
> > > > 
> > > > Actually no, "... and set a short timeout ...".
> > > 
> > > Well, OK, we do need a flag to distinguish normal timeout from probe 
> > > timeout. But still I don't see how we can do this without increasing the 
> > > size of every conntrack by at least 4 bytes.
> > 
> > Yes, you're right: PAWS assumes all packets carry timestamps option, an 
> > option-less ACK isn't sufficient. And increasing every conntrack entry 
> > does seem too expensive when the application itself could send keep-alive 
> > packets.
> 
> Looking at the source code, actually, the Linux TCP stack handles 
> gracefully TCP packets without timestamp options when sender originally 
> announced TCP timestamps. So it seems to me we could send a simple, 
> option-less "keep-alive" packet. RFC1323 does not discuss the case but if 
> the option is missing, stacks should fall back to the base handling, 
> isn't it? ;-)

That would be one option. Alternatively we could just make it optional
by putting it into an extend or, looking at the NAT structure, shrink
it a bit more for the NAT case to make up for the size increase by
moving the PPtP helper data to an extend.