kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #46438
[Bug 1270237] Re: prevent the conntrack table from filling up in the kernel
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
precise' to 'verification-done-precise'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-precise
** Tags added: verification-needed-quantal
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1270237
Title:
prevent the conntrack table from filling up in the kernel
Status in “linux” package in Ubuntu:
Fix Released
Status in “linux-lts-raring” package in Ubuntu:
Invalid
Status in “linux” source package in Precise:
Fix Committed
Status in “linux-lts-raring” source package in Precise:
Fix Committed
Status in “linux” source package in Quantal:
Fix Committed
Status in “linux-lts-raring” source package in Quantal:
Invalid
Status in “linux” source package in Raring:
Invalid
Status in “linux-lts-raring” source package in Raring:
Invalid
Bug description:
[Impact]
When running a server for an extended amount of time the conntrack table can fill up.
Here is the netfilter discussion: http://www.spinics.net/lists/netfilter-devel/msg26759.html
[Fix]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6547a221871f139cc56328a38105d47c14874cbe
Present in 3.11 >
[Test Case]
From the patch:
When loose tracking is enabled (default), non-syn packets cause
creation of new conntracks in established state with default timeout for
established state (5 days). This causes the table to fill up with UNREPLIED
when the 'new ack' packet happened to be the last-ack of a previous,
already timed-out connection.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1270237/+subscriptions
References