From: William Allen Simpson <hidden> Date: 2011-01-12 17:43:08
With the recent flurry of messages related to TCPCT, I devoted a nice
snowy Saturday afternoon to updating the socket option code. Linux is
rather behind on TCPCT implementation, so this will help with future
software compatibility.
Currently, any userland programs written to RFC-to-be-6013 will not
interoperate with Linux 2.6.33 and beyond. I've made these patches
for 2.6.37 -- they'll also need to be ported to earlier releases.
I'm not on this list, so anybody with comments should CC me. Thanks.
From: William Allen Simpson <hidden> Date: 2011-01-12 17:59:44
Use most recently specified symbols of RFC-to-be-6013.
Permit setting either cookie or s_data (alternatively).
Split the data value from socket option header, saving more than
1K of stack space in the handler by copying long data values
directly from user space into the kref block.
Signed-off-by: William.Allen.Simpson@gmail.com
---
include/linux/tcp.h | 35 ++++++++++++-----
net/ipv4/tcp.c | 102 +++++++++++++++++++++++++++++++++++---------------
2 files changed, 96 insertions(+), 41 deletions(-)
From: Eric Dumazet <hidden> Date: 2011-01-12 18:05:31
Le mercredi 12 janvier 2011 à 12:52 -0500, William Allen Simpson a
écrit :
Use most recently specified symbols of RFC-to-be-6013.
Allows different global s_data limits for SYN and SYN_ACK.
CC: "Eric W. Biederman" <redacted>
CC: Stephen Hemminger <redacted>
CC: Andi Kleen <redacted>
Signed-off-by: William.Allen.Simpson@gmail.com
Should be :
Signed-off-by: William Allen Simpson <redacted>
Hmm, patch is not inlined, so I have to copy/paste
+static int tcp_cookie_max = TCP_COOKIE_MAX;
...
/* Update system visible IP port range */
static void set_local_port_range(int range[2])
Now sysctl_tcp_cookie_size has a max limit of TCP_COOKIE_MAX, you can
remove the now uneeded check in :
static u8 tcp_cookie_size_check(u8 desired)
...
if (cookie_size >= TCP_COOKIE_MAX)
/* value too large, specify maximum */
return TCP_COOKIE_MAX;
@@ -185,22 +185,37 @@ struct tcp_md5sig {#define TCP_COOKIE_PAIR_SIZE (2*TCP_COOKIE_MAX)/* Flags for both getsockopt and setsockopt */-#define TCP_COOKIE_IN_ALWAYS (1<< 0) /* Discard SYN without cookie */-#define TCP_COOKIE_OUT_NEVER (1<< 1) /* Prohibit outgoing cookies,+#define TCPCT_IN_ALWAYS (1<< 0) /* Discard SYN without cookie */+#define TCPCT_OUT_NEVER (1<< 1) /* Prohibit outgoing cookies,
You end up changing values in kernel userspace API in a way
that is incompatible with older applications. This is not acceptable.
While I agree in principle and argued strongly against it, other
members of the research group (particularly the original project
sponsor) have over-ridden my concerns. I'm sorry to inform you that
many/most participants don't care much about Linux.
Note that the *bits* are the same, and previously compiled programs
(that don't access more advanced features) should continue to run as
they have in the past.
Even though I'm not paid to work on Linux, I'm doing my best to give you
folks a quick heads up and provide code to rectify the very recent changes
that can be propagated back through the stable tree (to 2.6.33).
As always, what you actually do with my code is up to you....
#define TCP_COOKIE_PAIR_SIZE (2*TCP_COOKIE_MAX)
/* Flags for both getsockopt and setsockopt */
-#define TCP_COOKIE_IN_ALWAYS (1<< 0) /* Discard SYN without
cookie */
-#define TCP_COOKIE_OUT_NEVER (1<< 1) /* Prohibit outgoing
cookies,
+#define TCPCT_IN_ALWAYS (1<< 0) /* Discard SYN
without cookie */
+#define TCPCT_OUT_NEVER (1<< 1) /* Prohibit
outgoing cookies,
You end up changing values in kernel userspace API in a way
that is incompatible with older applications. This is not acceptable.
While I agree in principle and argued strongly against it, other
members of the research group (particularly the original project
sponsor) have over-ridden my concerns. I'm sorry to inform you that
many/most participants don't care much about Linux.
Note that the *bits* are the same, and previously compiled programs
(that don't access more advanced features) should continue to run as
they have in the past.
Even though I'm not paid to work on Linux, I'm doing my best to give you
folks a quick heads up and provide code to rectify the very recent changes
that can be propagated back through the stable tree (to 2.6.33).
As always, what you actually do with my code is up to you....
@@ -185,22 +185,37 @@ struct tcp_md5sig {#define TCP_COOKIE_PAIR_SIZE (2*TCP_COOKIE_MAX)/* Flags for both getsockopt and setsockopt */-#define TCP_COOKIE_IN_ALWAYS (1<< 0) /* Discard SYN without cookie */-#define TCP_COOKIE_OUT_NEVER (1<< 1) /* Prohibit outgoing cookies,+#define TCPCT_IN_ALWAYS (1<< 0) /* Discard SYN without cookie */+#define TCPCT_OUT_NEVER (1<< 1) /* Prohibit outgoing cookies,
You end up changing values in kernel userspace API in a way
that is incompatible with older applications. This is not acceptable.
While I agree in principle and argued strongly against it, other
members of the research group (particularly the original project
sponsor) have over-ridden my concerns. I'm sorry to inform you that
many/most participants don't care much about Linux.
How leaving TCP_COOKIE_IN_ALWAYS and TCP_COOKIE_OUT_NEVER definitions so
that user space programs compiles can be a problem to "research group" ?
AFAIK, TCPCT_IN_ALWAYS / TCPCT_OUT_NEVER are not mentioned in
http://www.rfc-editor.org/authors/rfc6013.txt
But TCP_COOKIE_IN_ALWAYS and TCP_COOKIE_OUT_NEVER are ...
Isnt it a bit confusing ?
Note that the *bits* are the same, and previously compiled programs
(that don't access more advanced features) should continue to run as
they have in the past.
Even though I'm not paid to work on Linux, I'm doing my best to give you
folks a quick heads up and provide code to rectify the very recent changes
that can be propagated back through the stable tree (to 2.6.33).
As always, what you actually do with my code is up to you....
Maybe its too early, and we should wait for an official RFC, especially
if you insist breaking API in 6 months.
From: William Allen Simpson <hidden> Date: 2011-01-14 03:00:16
On 1/13/11 12:53 PM, Arnaud Lacombe wrote:
On Thu, Jan 13, 2011 at 12:32 PM, William Allen Simpson
[off-list ref] wrote:
quoted
Even though I'm not paid to work on Linux, I'm doing my best to give you
folks a quick heads up and provide code to rectify the very recent changes
that can be propagated back through the stable tree (to 2.6.33).
As always, what you actually do with my code is up to you....
Is this supposed to be humorous? Maybe folks here find it amusing that
somebody thinks they know more than the *author* about the contents of the
document? Did you note the words above? That is, "very recent changes"?
Perhaps you are viewing an older cached version. Please check for the
current month on every page: "January 2011".
We discussed -- and ultimately decided -- these changes in private email
during the independent review process before making them available to the
general public. That's how the RFC publication procedure works.
I tried to be helpful to the Linux community in advance of publication, so
you would be prepared. I'm sorry that the community here is so lacking in
appreciation for my efforts on your behalf.
As always, what you actually do with my code is up to you....
From: Eric Dumazet <hidden> Date: 2011-01-14 03:08:59
Le jeudi 13 janvier 2011 à 22:00 -0500, William Allen Simpson a écrit :
Is this supposed to be humorous? Maybe folks here find it amusing that
somebody thinks they know more than the *author* about the contents of the
document? Did you note the words above? That is, "very recent changes"?
Perhaps you are viewing an older cached version. Please check for the
current month on every page: "January 2011".
We discussed -- and ultimately decided -- these changes in private email
during the independent review process before making them available to the
general public. That's how the RFC publication procedure works.
I tried to be helpful to the Linux community in advance of publication, so
you would be prepared. I'm sorry that the community here is so lacking in
appreciation for my efforts on your behalf.
As always, what you actually do with my code is up to you....
--
Next time you come here, provide an up2date link for us mere mortals, so
that we can check your code against your claims. We dont trust you
anymore, we had to fix several bugs.
This is getting ridiculous.
As I said, we are going to wait for official RFC, because its time
consuming to review your patches, and nobody asked for early TCPCT
coding in linux kernel (you already said your buddies dont care at all)