TCP_CONNTRACK_ESTABLISHED 5days
(Sent this to the linux-net list; seems this list is more appropriate. Sorry for any inconvenient xposting)
I fail to understand why TCP_CONNTRACK_ESTABLISHED has to be 5 days.
It's not configurable from /proc, but I see nothing wrong in changing the source to, say, 1 day. Would someone educate me, pls.
/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c :
static unsigned long tcp_timeouts[]
= { 30 MINS, /* TCP_CONNTRACK_NONE, */
5 DAYS, /* TCP_CONNTRACK_ESTABLISHED, */ 2 MINS, /* TCP_CONNTRACK_SYN_SENT, */ 60 SECS, /* TCP_CONNTRACK_SYN_RECV, */ 2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */ 2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */ 10 SECS, /* TCP_CONNTRACK_CLOSE, */ 60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */ 30 SECS, /* TCP_CONNTRACK_LAST_ACK, */ 2 MINS, /* TCP_CONNTRACK_LISTEN, */
};
Signature · 2 lines
Kind regards, Mogens Valentin
Quoted 19 lines · Mogens Valentin
(Sent this to the linux-net list; seems this list is more appropriate. Sorry for any inconvenient xposting)
I fail to understand why
TCP_CONNTRACK_ESTABLISHEDhas to be 5 days.
It's not configurable from /proc, but I see nothing wrong in changing the source to, say, 1 day. Would someone educate me, pls.
/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c:static unsigned long tcp_timeouts[]
= { 30 MINS, /*TCP_CONNTRACK_NONE, */5 DAYS, /* TCP_CONNTRACK_ESTABLISHED, */ 2 MINS, /* TCP_CONNTRACK_SYN_SENT, */ 60 SECS, /* TCP_CONNTRACK_SYN_RECV, */ 2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */ 2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */ 10 SECS, /* TCP_CONNTRACK_CLOSE, */ 60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */ 30 SECS, /* TCP_CONNTRACK_LAST_ACK, */ 2 MINS, /* TCP_CONNTRACK_LISTEN, */
Quoted 2 lines
};
Sorry, I had missed /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..
If we keep, say, a browser connection open longer than those 10m, it's supposed to either use keepalive, or an established session will simply be setup for another 10m, right? Won't that create some additional load for a busy server, i.e. something else that this thought-of browser session?
To the maintainer of ip_conntrack_proto_tcp.c (Paul Russell?):
Wouldn't it be fair to change TCP_CONNTRACK_ESTABLISHED permanently?
Signature · 2 lines
Kind regards, Mogens Valentin
Quoted 4 lines
Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..If we keep, say, a browser connection open longer than those 10m, it's supposed to either use keepalive, or an established session will simply be setup for another 10m, right?
hm... depends on a few factors.
a normal browser session should be closed after GET has delivered all data, there is no need to keep the connection established. e.g. online-banking should use keepalive not only for this purpose.
and it depends on your other firewall settings (syn flag etc).
i got 500 clients, nobody claimed any troubles so far.
Quoted 1 line
Won't that create some additional load for a busy server, i.e. something else that this thought-of browser session?
hm... there may exist some application, which need this, but i never saw one.
Quoted 2 lines
To the maintainer of
ip_conntrack_proto_tcp.c(Paul Russell?):
Wouldn't it be fair to changeTCP_CONNTRACK_ESTABLISHEDpermanently?
the question is, what would be a good value?
everyone can change this value in a easy way.
Quoted 2 lines
Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..
I would not set ip_conntrack_tcp_timeout_established to any thing lower than tcp_fin_timeout. I would be tempted to set ip_conntrack_tcp_timeout_established to approximately double what tcp_fin_timeout is set to. I don't know of any reason that conntrack would need to keep things for twice tcp_fin_timeout, but I'd rather be safe than sorry. Besides even double of tcp_fin_timeout is CONSIDERABLY less than 5 days.
Grant. . . .
Quoted 5 lines · Grant
Quoted 2 lines
Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..I would not set
ip_conntrack_tcp_timeout_establishedto any thing lower thantcp_fin_timeout. I would be tempted to setip_conntrack_tcp_timeout_establishedto approximately double whattcp_fin_timeoutis set to. I don't know of any reason that conntrack would need to keep things for twicetcp_fin_timeout, but I'd rather be safe than sorry. Besides even double oftcp_fin_timeoutis CONSIDERABLY less than 5 days.
Hmm, dunno if various distros set tcp_fin_timeout differently. With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this). Are you saying that Mouritz' 10mins will in some (distro?) cases violate
ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ?
Anyway, /usr/src/linux/Documentation/filesystems/proc.txt says
tcp_fin_timeout
---------------
The length of time in seconds it takes to receive a final FIN before the socket is always closed. This is strictly a violation of the TCP specification, but required to prevent denial-of-service attacks.
I'm having trouble understanding the 'strictly a violation' part. Is it a (iana) crime to define tcp_fin_timeout?
Signature · 2 lines
Kind regards, Mogens Valentin
Quoted 4 lines
Hmm, dunno if various distros set
tcp_fin_timeoutdifferently. With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this). Are you saying that Mouritz' 10mins will in some (distro?) cases violate
ip_conntrack_tcp_timeout_established>=tcp_fin_timeout* 2 ?
No, not at all. I'm merely stating that I see no reason to have ip_conntrack_tcp_timeout_established any higher than tcp_fin_timeout safe for some small head room. Seeing as how the time was for 5 days, I see no reason to hold it open for twice the tcp_fin_timeout period for safe head room. Any thing beyond tcp_fin_timeout and your local TCP stack will have closed the connection any way. As soon as I type this I start wondering about systems behind a firewall. Hmm... Something to think about.
Quoted 10 lines
Anyway,
/usr/src/linux/Documentation/filesystems/proc.txtsays
tcp_fin_timeout
---------------
The length of time in seconds it takes to receive a final FIN before the socket is always closed. This is strictly a violation of the TCP specification, but required to prevent denial-of-service attacks.I'm having trouble understanding the 'strictly a violation' part. Is it a (iana) crime to define
tcp_fin_timeout?
I have not (recently) read (enough) of the TCP specification to know for sure what is in violation, but I would be willing to bet that a TCP ""conversation is to remain in the open state (Syn, Syn-Ack, Ack-Ack...) state until both sides close the connection gracefully or see a reset. Thus if we artificially close the connection we are violating the TCP specification by doing such. Seeing as how this is usually not a problem... This is sort of like what the TARPIT target is targeting. TARPIT will take a TCP connection to the established state and release all resources but not honor a close of the connection. This failure to close the connection causes the sending system to get stuck in the TARPIT (hens the name) until it is willing to forcefully close the connection from it's end via timeout.
Grant. . . .
Quoted 13 lines · Mogens Valentin
Quoted 11 lines · Grant
Quoted 2 lines
Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..I would not set
ip_conntrack_tcp_timeout_establishedto any thing lower thantcp_fin_timeout. I would be tempted to setip_conntrack_tcp_timeout_establishedto approximately double whattcp_fin_timeoutis set to. I don't know of any reason that conntrack would need to keep things for twicetcp_fin_timeout, but I'd rather be safe than sorry. Besides even double oftcp_fin_timeoutis CONSIDERABLY less than 5 days.
Quoted 5 lines
Hmm, dunno if various distros set
tcp_fin_timeoutdifferently. With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this). Are you saying that Mouritz' 10mins will in some (distro?) cases violate
ip_conntrack_tcp_timeout_established>=tcp_fin_timeout* 2 ?
In debian3.1 it is 5 days too !!!
The question now, what troubles would happen if we kep it/changed it !?!?!
Quoted 16 lines
Anyway,
/usr/src/linux/Documentation/filesystems/proc.txtsays
tcp_fin_timeout
---------------
The length of time in seconds it takes to receive a final FIN before the socket is always closed. This is strictly a violation of the TCP specification, but required to prevent denial-of-service attacks.I'm having trouble understanding the 'strictly a violation' part. Is it a (iana) crime to define
tcp_fin_timeout?--
Kind regards,
Mogens Valentin
Signature · 3 lines
Mohamed Eldesoky www.eldesoky.net RHCE
Quoted 16 lines · Mohamed Eldesoky
Quoted 14 lines · Mogens Valentin
Quoted 11 lines · Grant
Quoted 2 lines
Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..I would not set
ip_conntrack_tcp_timeout_establishedto any thing lower thantcp_fin_timeout. I would be tempted to setip_conntrack_tcp_timeout_establishedto approximately double whattcp_fin_timeoutis set to. I don't know of any reason that conntrack would need to keep things for twicetcp_fin_timeout, but I'd rather be safe than sorry. Besides even double oftcp_fin_timeoutis CONSIDERABLY less than 5 days.
Quoted 8 lines
Quoted 5 lines
Hmm, dunno if various distros set
tcp_fin_timeoutdifferently. With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this). Are you saying that Mouritz' 10mins will in some (distro?) cases violate
ip_conntrack_tcp_timeout_established>=tcp_fin_timeout* 2 ?In debian3.1 it is 5 days too !!!
Yes, it's kernel defined, distros doesn't set it any differently, AFAIK.
Quoted 1 line
The question now, what troubles would happen if we kep it/changed it !?!?!
None. When sessions timeout, so be it. When need be, a new session will be setup. Works fine for me now.
Signature · 7 lines
Kind regards, Mogens Valentin Horse dropping have an easy life, they don't have to work and can smoke.. -- Mogens Valentin