* conntrack, idle TCP connection and keep-alives
@ 2013-10-26 20:14 WGH
2013-10-27 15:34 ` Phil Oester
0 siblings, 1 reply; 13+ messages in thread
From: WGH @ 2013-10-26 20:14 UTC (permalink / raw)
To: netfilter-devel
Hello!
It seems that, when masquerading, conntrack silently drops idle
connection after nf_conntrack_tcp_timeout_established seconds. This's
pretty terrible, as application inside the network, if it never sends
anything, will never know that connection was dropped.
RFC 5382 gives us a solution to this:
> A NAT can check if an endpoint for a session has crashed by sending a
> TCP keep-alive packet and receiving a TCP RST packet in response.
However, it I couldn't find such feature in netfilter. It would be
pretty nice to have.
It would be much more effective than enabling keep-alives system-wide
(which is not even possible in practice). It makes sense that NAT has to
manage such things, as only NAT knows the timeouts of itself. If there's
a NAT along the route, it will send keep-alives (overhead, but
inevitable). If there's no NATs, there will be no keep-alives. Simple.
AFAIK, Cisco implements this under name Dead Connection Detection.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-26 20:14 conntrack, idle TCP connection and keep-alives WGH
@ 2013-10-27 15:34 ` Phil Oester
2013-10-27 18:01 ` Patrick McHardy
2013-10-27 18:22 ` WGH
0 siblings, 2 replies; 13+ messages in thread
From: Phil Oester @ 2013-10-27 15:34 UTC (permalink / raw)
To: WGH; +Cc: netfilter-devel
On Sun, Oct 27, 2013 at 12:14:48AM +0400, WGH wrote:
> It seems that, when masquerading, conntrack silently drops idle
> connection after nf_conntrack_tcp_timeout_established seconds. This's
> pretty terrible, as application inside the network, if it never sends
> anything, will never know that connection was dropped.
If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
to an insanely high value. You do realize, of course, that the conntrack
table has a finite number of entries.
> RFC 5382 gives us a solution to this:
> > A NAT can check if an endpoint for a session has crashed by sending a
> > TCP keep-alive packet and receiving a TCP RST packet in response.
>
> However, it I couldn't find such feature in netfilter. It would be
> pretty nice to have.
Keepalives should be done in the application, not in the firewall.
Phil
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 15:34 ` Phil Oester
@ 2013-10-27 18:01 ` Patrick McHardy
2013-10-27 18:38 ` Patrick McHardy
2013-10-27 18:22 ` WGH
1 sibling, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2013-10-27 18:01 UTC (permalink / raw)
To: Phil Oester; +Cc: WGH, netfilter-devel
On Sun, Oct 27, 2013 at 08:34:09AM -0700, Phil Oester wrote:
> On Sun, Oct 27, 2013 at 12:14:48AM +0400, WGH wrote:
> > It seems that, when masquerading, conntrack silently drops idle
> > connection after nf_conntrack_tcp_timeout_established seconds. This's
> > pretty terrible, as application inside the network, if it never sends
> > anything, will never know that connection was dropped.
>
> If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
> to an insanely high value. You do realize, of course, that the conntrack
> table has a finite number of entries.
>
> > RFC 5382 gives us a solution to this:
> > > A NAT can check if an endpoint for a session has crashed by sending a
> > > TCP keep-alive packet and receiving a TCP RST packet in response.
> >
> > However, it I couldn't find such feature in netfilter. It would be
> > pretty nice to have.
>
> Keepalives should be done in the application, not in the firewall.
Actually I think its a pretty nice idea to reduce breakage introduced
by NATs. There a millions of embedded devices that use very small timeout
values to reduce memory usage, at the cost of frequently breaking idle
connections.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 15:34 ` Phil Oester
2013-10-27 18:01 ` Patrick McHardy
@ 2013-10-27 18:22 ` WGH
1 sibling, 0 replies; 13+ messages in thread
From: WGH @ 2013-10-27 18:22 UTC (permalink / raw)
To: Phil Oester; +Cc: netfilter-devel
On 27.10.2013 19:34, Phil Oester wrote:
> If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
> to an insanely high value. You do realize, of course, that the conntrack
> table has a finite number of entries.
It'll delay the problem, but not fix it. Besides, it'll worsen the
situtation that established timeout intended to fix - genuinely crashed
connections will linger for said insane value.
> Keepalives should be done in the application, not in the firewall.
Why not, actually? It isn't strictly keep-alive in application sense,
but rather a way that NAT may use to detect broken connections. It
addresses breakage caused by NAT itself, while keep-alives issued by
application will address other problems (like physical connection loss),
if necessary.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 18:01 ` Patrick McHardy
@ 2013-10-27 18:38 ` Patrick McHardy
2013-10-27 19:14 ` Jozsef Kadlecsik
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2013-10-27 18:38 UTC (permalink / raw)
To: Phil Oester; +Cc: WGH, netfilter-devel
On Sun, Oct 27, 2013 at 06:01:30PM +0000, Patrick McHardy wrote:
> On Sun, Oct 27, 2013 at 08:34:09AM -0700, Phil Oester wrote:
> > On Sun, Oct 27, 2013 at 12:14:48AM +0400, WGH wrote:
> > > It seems that, when masquerading, conntrack silently drops idle
> > > connection after nf_conntrack_tcp_timeout_established seconds. This's
> > > pretty terrible, as application inside the network, if it never sends
> > > anything, will never know that connection was dropped.
> >
> > If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
> > to an insanely high value. You do realize, of course, that the conntrack
> > table has a finite number of entries.
> >
> > > RFC 5382 gives us a solution to this:
> > > > A NAT can check if an endpoint for a session has crashed by sending a
> > > > TCP keep-alive packet and receiving a TCP RST packet in response.
> > >
> > > However, it I couldn't find such feature in netfilter. It would be
> > > pretty nice to have.
> >
> > Keepalives should be done in the application, not in the firewall.
>
> Actually I think its a pretty nice idea to reduce breakage introduced
> by NATs. There a millions of embedded devices that use very small timeout
> values to reduce memory usage, at the cost of frequently breaking idle
> connections.
The downside seems to be that we'd need to keep track of timestamp values
to send valid keepalives, which also costs extra memory. I don't think that
cost is justifiable for NAT keepalives alone.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 18:38 ` Patrick McHardy
@ 2013-10-27 19:14 ` Jozsef Kadlecsik
2013-10-27 19:20 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Jozsef Kadlecsik @ 2013-10-27 19:14 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Phil Oester, WGH, netfilter-devel
On Sun, 27 Oct 2013, Patrick McHardy wrote:
> On Sun, Oct 27, 2013 at 06:01:30PM +0000, Patrick McHardy wrote:
> > On Sun, Oct 27, 2013 at 08:34:09AM -0700, Phil Oester wrote:
> > > On Sun, Oct 27, 2013 at 12:14:48AM +0400, WGH wrote:
> > > > It seems that, when masquerading, conntrack silently drops idle
> > > > connection after nf_conntrack_tcp_timeout_established seconds. This's
> > > > pretty terrible, as application inside the network, if it never sends
> > > > anything, will never know that connection was dropped.
> > >
> > > If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
> > > to an insanely high value. You do realize, of course, that the conntrack
> > > table has a finite number of entries.
> > >
> > > > RFC 5382 gives us a solution to this:
> > > > > A NAT can check if an endpoint for a session has crashed by sending a
> > > > > TCP keep-alive packet and receiving a TCP RST packet in response.
> > > >
> > > > However, it I couldn't find such feature in netfilter. It would be
> > > > pretty nice to have.
> > >
> > > Keepalives should be done in the application, not in the firewall.
> >
> > Actually I think its a pretty nice idea to reduce breakage introduced
> > by NATs. There a millions of embedded devices that use very small timeout
> > values to reduce memory usage, at the cost of frequently breaking idle
> > connections.
>
> The downside seems to be that we'd need to keep track of timestamp values
> to send valid keepalives, which also costs extra memory. I don't think that
> cost is justifiable for NAT keepalives alone.
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.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 19:14 ` Jozsef Kadlecsik
@ 2013-10-27 19:20 ` Patrick McHardy
2013-10-27 19:23 ` WGH
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2013-10-27 19:20 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Phil Oester, WGH, netfilter-devel
On Sun, Oct 27, 2013 at 08:14:19PM +0100, Jozsef Kadlecsik wrote:
> On Sun, 27 Oct 2013, Patrick McHardy wrote:
>
> > On Sun, Oct 27, 2013 at 06:01:30PM +0000, Patrick McHardy wrote:
> > > On Sun, Oct 27, 2013 at 08:34:09AM -0700, Phil Oester wrote:
> > > > On Sun, Oct 27, 2013 at 12:14:48AM +0400, WGH wrote:
> > > > > It seems that, when masquerading, conntrack silently drops idle
> > > > > connection after nf_conntrack_tcp_timeout_established seconds. This's
> > > > > pretty terrible, as application inside the network, if it never sends
> > > > > anything, will never know that connection was dropped.
> > > >
> > > > If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
> > > > to an insanely high value. You do realize, of course, that the conntrack
> > > > table has a finite number of entries.
> > > >
> > > > > RFC 5382 gives us a solution to this:
> > > > > > A NAT can check if an endpoint for a session has crashed by sending a
> > > > > > TCP keep-alive packet and receiving a TCP RST packet in response.
> > > > >
> > > > > However, it I couldn't find such feature in netfilter. It would be
> > > > > pretty nice to have.
> > > >
> > > > Keepalives should be done in the application, not in the firewall.
> > >
> > > Actually I think its a pretty nice idea to reduce breakage introduced
> > > by NATs. There a millions of embedded devices that use very small timeout
> > > values to reduce memory usage, at the cost of frequently breaking idle
> > > connections.
> >
> > The downside seems to be that we'd need to keep track of timestamp values
> > to send valid keepalives, which also costs extra memory. I don't think that
> > cost is justifiable for NAT keepalives alone.
>
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 19:20 ` Patrick McHardy
@ 2013-10-27 19:23 ` WGH
2013-10-27 19:32 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: WGH @ 2013-10-27 19:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Jozsef Kadlecsik, Phil Oester, netfilter-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 19:23 ` WGH
@ 2013-10-27 19:32 ` Patrick McHardy
2013-10-27 19:34 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2013-10-27 19:32 UTC (permalink / raw)
To: WGH; +Cc: Jozsef Kadlecsik, Phil Oester, netfilter-devel
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 ...".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 19:32 ` Patrick McHardy
@ 2013-10-27 19:34 ` Patrick McHardy
2013-10-27 19:50 ` Jozsef Kadlecsik
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2013-10-27 19:34 UTC (permalink / raw)
To: WGH; +Cc: Jozsef Kadlecsik, Phil Oester, netfilter-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 19:34 ` Patrick McHardy
@ 2013-10-27 19:50 ` Jozsef Kadlecsik
2013-10-27 20:49 ` Jozsef Kadlecsik
0 siblings, 1 reply; 13+ messages in thread
From: Jozsef Kadlecsik @ 2013-10-27 19:50 UTC (permalink / raw)
To: Patrick McHardy; +Cc: WGH, Phil Oester, netfilter-devel
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.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 19:50 ` Jozsef Kadlecsik
@ 2013-10-27 20:49 ` Jozsef Kadlecsik
2013-10-28 9:29 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Jozsef Kadlecsik @ 2013-10-27 20:49 UTC (permalink / raw)
To: Patrick McHardy; +Cc: WGH, Phil Oester, netfilter-devel
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? ;-)
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conntrack, idle TCP connection and keep-alives
2013-10-27 20:49 ` Jozsef Kadlecsik
@ 2013-10-28 9:29 ` Patrick McHardy
0 siblings, 0 replies; 13+ messages in thread
From: Patrick McHardy @ 2013-10-28 9:29 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: WGH, Phil Oester, netfilter-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-10-28 9:29 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-26 20:14 conntrack, idle TCP connection and keep-alives WGH
2013-10-27 15:34 ` Phil Oester
2013-10-27 18:01 ` Patrick McHardy
2013-10-27 18:38 ` Patrick McHardy
2013-10-27 19:14 ` Jozsef Kadlecsik
2013-10-27 19:20 ` Patrick McHardy
2013-10-27 19:23 ` WGH
2013-10-27 19:32 ` Patrick McHardy
2013-10-27 19:34 ` Patrick McHardy
2013-10-27 19:50 ` Jozsef Kadlecsik
2013-10-27 20:49 ` Jozsef Kadlecsik
2013-10-28 9:29 ` Patrick McHardy
2013-10-27 18:22 ` WGH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).