why do we need printk on sending syn flood cookie?

why do we need printk on sending syn flood cookie?

[Franchoze Eric]

 Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.

Something like this:
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index fe193e5..5574adc 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1230,8 +1230,10 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	__u32 isn = TCP_SKB_CB(skb)->when;
 #ifdef CONFIG_SYN_COOKIES
 	int want_cookie = 0;
+	int want_cookie_no_warn = 0;
 #else
 #define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
+#define want_cookie_no_warn 0 
 #endif
 
 	/* Never answer to SYNs send to broadcast or multicast */
@@ -1246,7 +1248,10 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 #ifdef CONFIG_SYN_COOKIES
 		if (sysctl_tcp_syncookies) {
 			want_cookie = 1;
-		} else
+			if (sysctl_tcp_syncookies == 2)
+				want_cookie_no_warn = 1;
+		}
+		else
 #endif
 		goto drop;
 	}
@@ -1296,6 +1301,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 
 #ifdef CONFIG_SYN_COOKIES
 		want_cookie = 0;	/* not our kind of cookie */
+		want_cookie_no_warn = 0;	/* no printk on syn flood */
 #endif
 		tmp_ext.cookie_out_never = 0; /* false */
 		tmp_ext.cookie_plus = tmp_opt.cookie_plus;
@@ -1328,7 +1334,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 
 	if (want_cookie) {
 #ifdef CONFIG_SYN_COOKIES
-		syn_flood_warning(skb);
+		if (!want_cookie_no_warn)
+			syn_flood_warning(skb);
 		req->cookie_ts = tmp_opt.tstamp_ok;
 #endif
 		isn = cookie_v4_init_sequence(sk, skb, &req->mss);

Re: why do we need printk on sending syn flood cookie?

[Florian Westphal]

Franchoze Eric <franchoze@yandex.ru> wrote:
>  Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.

It is handled exactly like other printks in the networking path,
e.g. receipt of tcp wscale == 15.

Why does this need special treatment?

Re: Re: why do we need printk on sending syn flood cookie?

[Franchoze Eric]

02.08.10, 12:17, "Florian Westphal" <fw@strlen.de>:

> Franchoze Eric  wrote:
>  >  Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
>  
>  It is handled exactly like other printks in the networking path,
>  e.g. receipt of tcp wscale == 15.
>  
>  Why does this need special treatment?
>  

For now I see "possible SYN flooding on port %d. Sending cookies.\n" message each second on my server. I know that there are a lot of SYNs and I know that kernel sends cookie. Why do I need so mach printk?
So I suggested add new value to /proc/sys/net/ipv4/tcp_syncookies, which will enable cookie but this printk will be turned off.

Re: why do we need printk on sending syn flood cookie?

[Mitchell Erblich]

On Aug 2, 2010, at 9:11 AM, Franchoze Eric wrote:

> 
> 
> 02.08.10, 12:17, "Florian Westphal" <fw@strlen.de>:
> 
>> Franchoze Eric  wrote:
>>> Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
>> 
>> It is handled exactly like other printks in the networking path,
>> e.g. receipt of tcp wscale == 15.
>> 
>> Why does this need special treatment?
>> 
> 
> For now I see "possible SYN flooding on port %d. Sending cookies.\n" message each second on my server. I know that there are a lot of SYNs and I know that kernel sends cookie. Why do I need so mach printk?
> So I suggested add new value to /proc/sys/net/ipv4/tcp_syncookies, which will enable cookie but this printk will be turned off.


Once print per sec is a very good GENERIC informative msg to an admin that 
this system either has some  very small config'd or default values
(normally set up as a percentage of memory or set sock option and/or .. )
and/or that for some reason that a large number of SYNs are being rec'vd
and/or that a number of connections are being un/intentionally being
retried and/or dropped

Remember each printk may only be a small fraction of the number of SYNs
rcv'd and this fraction COULD depend on the Mb/Gb of the intf(s) or more
likely some type of  avg of summation of the number of network paths
involved.

Mitchell Erblich



> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: why do we need printk on sending syn flood cookie?

[Franchoze Eric]

02.08.10, 22:10, "Mitchell Erblich" <erblichs@earthlink.net>:

> 
>  On Aug 2, 2010, at 9:11 AM, Franchoze Eric wrote:
>  
>  > 
>  > 
>  > 02.08.10, 12:17, "Florian Westphal" :
>  > 
>  >> Franchoze Eric  wrote:
>  >>> Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
>  >> 
>  >> It is handled exactly like other printks in the networking path,
>  >> e.g. receipt of tcp wscale == 15.
>  >> 
>  >> Why does this need special treatment?
>  >> 
>  > 
>  > For now I see "possible SYN flooding on port %d. Sending cookies.\n" message each second on my server. I know that there are a lot of SYNs and I know that kernel sends cookie. Why do I need so mach printk?
>  > So I suggested add new value to /proc/sys/net/ipv4/tcp_syncookies, which will enable cookie but this printk will be turned off.
>  
>  
>  Once print per sec is a very good GENERIC informative msg to an admin that 
>  this system either has some  very small config'd or default values
>  (normally set up as a percentage of memory or set sock option and/or .. )
>  and/or that for some reason that a large number of SYNs are being rec'vd
>  and/or that a number of connections are being un/intentionally being
>  retried and/or dropped
>

There is no much settings to tune syn requests.
tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow
  
As for me, than I have about 3000 clients which do a little bit less then 3000 SYNs for nginx port.
I'm ok with sending syn cookies to clients. Also it's not possible to turn syncs off with setting
bigger value to tcp_max_syn_backlog and application works well so I would simple remove 
this messages from dmesg.

If I limit syncs with iptables it starts to drop needed packets. So it's no solution. That's why I think that we need turn off 
printk without turning off syn cookies.  

>  Remember each printk may only be a small fraction of the number of SYNs
>  rcv'd and this fraction COULD depend on the Mb/Gb of the intf(s) or more
>  likely some type of  avg of summation of the number of network paths
>  involved.
>  
>  Mitchell Erblich
>  
>  
>  
>  > --
>  > To unsubscribe from this list: send the line "unsubscribe netdev" in
>  > the body of a message to majordomo@vger.kernel.org
>  > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>  
>  

Re: why do we need printk on sending syn flood cookie?

[Mitchell Erblich]

On Aug 2, 2010, at 2:14 PM, Franchoze Eric wrote:

> 
> 
> 02.08.10, 22:10, "Mitchell Erblich" <erblichs@earthlink.net>:
> 
>> 
>> On Aug 2, 2010, at 9:11 AM, Franchoze Eric wrote:
>> 
>>> 
>>> 
>>> 02.08.10, 12:17, "Florian Westphal" :
>>> 
>>>> Franchoze Eric  wrote:
>>>>> Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
>>>> 
>>>> It is handled exactly like other printks in the networking path,
>>>> e.g. receipt of tcp wscale == 15.
>>>> 
>>>> Why does this need special treatment?
>>>> 
>>> 
>>> For now I see "possible SYN flooding on port %d. Sending cookies.\n" message each second on my server. I know that there are a lot of SYNs and I know that kernel sends cookie. Why do I need so mach printk?
>>> So I suggested add new value to /proc/sys/net/ipv4/tcp_syncookies, which will enable cookie but this printk will be turned off.
>> 
>> 
>> Once print per sec is a very good GENERIC informative msg to an admin that 
>> this system either has some  very small config'd or default values
>> (normally set up as a percentage of memory or set sock option and/or .. )
>> and/or that for some reason that a large number of SYNs are being rec'vd
>> and/or that a number of connections are being un/intentionally being
>> retried and/or dropped
>> 
> 
> There is no much settings to tune syn requests.
> tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow

The key is that you need a reproduceable test case and determine what type of
changes you want to make.

also review the listen (backlog) code and : tcp.h: TCP_SYNQ_HSIZE

	Other than that, their are MANY changes that can be done to scale this section
	of code.

	What is the latency of serving an ACK? What is a RTT of a SYN/ACK?
	Why is each client trying to ESTABLISH a connection at the same time?
	etc.

	Is your server capable of serving 3000 clients? Are they sending 1 MTU per sec,
	or are they doing 1000s of pings per sec, or are they doing bulk-data-transfer or?
	Thus, even if you are able to keep 3000 connections open at one time, can
	 your server properly respond to their requests in a timely manner?

	Mitchell Erblich
 
> 
> As for me, than I have about 3000 clients which do a little bit less then 3000 SYNs for nginx port.
> I'm ok with sending syn cookies to clients. Also it's not possible to turn syncs off with setting
> bigger value to tcp_max_syn_backlog and application works well so I would simple remove 
> this messages from dmesg.
> 
> If I limit syncs with iptables it starts to drop needed packets. So it's no solution. That's why I think that we need turn off 
> printk without turning off syn cookies.  
> 
>> Remember each printk may only be a small fraction of the number of SYNs
>> rcv'd and this fraction COULD depend on the Mb/Gb of the intf(s) or more
>> likely some type of  avg of summation of the number of network paths
>> involved.
>> 
>> Mitchell Erblich
>> 
>> 
>> 
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> 
>> 

Re: Re: why do we need printk on sending syn flood cookie?

[Franchoze Eric]

03.08.10, 02:30, "Mitchell Erblich" <erblichs@earthlink.net>:

> 
>  On Aug 2, 2010, at 2:14 PM, Franchoze Eric wrote:
>  
>  > 
>  > 
>  > 02.08.10, 22:10, "Mitchell Erblich" :
>  > 
>  >> 
>  >> On Aug 2, 2010, at 9:11 AM, Franchoze Eric wrote:
>  >> 
>  >>> 
>  >>> 
>  >>> 02.08.10, 12:17, "Florian Westphal" :
>  >>> 
>  >>>> Franchoze Eric  wrote:
>  >>>>> Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
>  >>>> 
>  >>>> It is handled exactly like other printks in the networking path,
>  >>>> e.g. receipt of tcp wscale == 15.
>  >>>> 
>  >>>> Why does this need special treatment?
>  >>>> 
>  >>> 
>  >>> For now I see "possible SYN flooding on port %d. Sending cookies.\n" message each second on my server. I know that there are a lot of SYNs and I know that kernel sends cookie. Why do I need so mach printk?
>  >>> So I suggested add new value to /proc/sys/net/ipv4/tcp_syncookies, which will enable cookie but this printk will be turned off.
>  >> 
>  >> 
>  >> Once print per sec is a very good GENERIC informative msg to an admin that 
>  >> this system either has some  very small config'd or default values
>  >> (normally set up as a percentage of memory or set sock option and/or .. )
>  >> and/or that for some reason that a large number of SYNs are being rec'vd
>  >> and/or that a number of connections are being un/intentionally being
>  >> retried and/or dropped
>  >> 
>  > 
>  > There is no much settings to tune syn requests.
>  > tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow
>  
>  The key is that you need a reproduceable test case and determine what type of
>  changes you want to make.
>  
>  also review the listen (backlog) code and : tcp.h: TCP_SYNQ_HSIZE
>  
>  	Other than that, their are MANY changes that can be done to scale this section
>  	of code.
>  
>  	What is the latency of serving an ACK? What is a RTT of a SYN/ACK?
>  	Why is each client trying to ESTABLISH a connection at the same time?
>  	etc.
>  
>  	Is your server capable of serving 3000 clients? Are they sending 1 MTU per sec,
>  	or are they doing 1000s of pings per sec, or are they doing bulk-data-transfer or?
>  	Thus, even if you are able to keep 3000 connections open at one time, can
>  	 your server properly respond to their requests in a timely manner?
>  
>  	Mitchell Erblich
>   

Thanks about TCP_SYNQ_HSIZE, I will take a look at this code.  The other questions are not easy to answer because of they require some measurements.
In general my machine is routed with forward http proxy and kernel reports syn flood at this port. Because of huge number of client behind proxy and they do 
requests at the same time and there is situation that a lot of SYNCs came to the same time.

So as I understand, this problem has to be fixed somewhere and simple removing printk does not work here.

>  > 
>  > As for me, than I have about 3000 clients which do a little bit less then 3000 SYNs for nginx port.
>  > I'm ok with sending syn cookies to clients. Also it's not possible to turn syncs off with setting
>  > bigger value to tcp_max_syn_backlog and application works well so I would simple remove 
>  > this messages from dmesg.
>  > 
>  > If I limit syncs with iptables it starts to drop needed packets. So it's no solution. That's why I think that we need turn off 
>  > printk without turning off syn cookies.  
>  > 
>  >> Remember each printk may only be a small fraction of the number of SYNs
>  >> rcv'd and this fraction COULD depend on the Mb/Gb of the intf(s) or more
>  >> likely some type of  avg of summation of the number of network paths
>  >> involved.
>  >> 
>  >> Mitchell Erblich
>  >> 
>  >> 
>  >> 
>  >>> --
>  >>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>  >>> the body of a message to majordomo@vger.kernel.org
>  >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  >> 
>  >> 
>  >> 
>  
>  
>  

Re: why do we need printk on sending syn flood cookie?

[Mitchell Erblich]

On Aug 2, 2010, at 3:30 PM, Mitchell Erblich wrote:

> 
> On Aug 2, 2010, at 2:14 PM, Franchoze Eric wrote:
> 
>> 
>> 
>> 02.08.10, 22:10, "Mitchell Erblich" <erblichs@earthlink.net>:
>> 
>>> 
>>> On Aug 2, 2010, at 9:11 AM, Franchoze Eric wrote:
>>> 
>>>> 
>>>> 
>>>> 02.08.10, 12:17, "Florian Westphal" :
>>>> 
>>>>> Franchoze Eric  wrote:
>>>>>> Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
>>>>> 
>>>>> It is handled exactly like other printks in the networking path,
>>>>> e.g. receipt of tcp wscale == 15.
>>>>> 
>>>>> Why does this need special treatment?
>>>>> 
>>>> 
>>>> For now I see "possible SYN flooding on port %d. Sending cookies.\n" message each second on my server. I know that there are a lot of SYNs and I know that kernel sends cookie. Why do I need so mach printk?
>>>> So I suggested add new value to /proc/sys/net/ipv4/tcp_syncookies, which will enable cookie but this printk will be turned off.
>>> 
>>> 
>>> Once print per sec is a very good GENERIC informative msg to an admin that 
>>> this system either has some  very small config'd or default values
>>> (normally set up as a percentage of memory or set sock option and/or .. )
>>> and/or that for some reason that a large number of SYNs are being rec'vd
>>> and/or that a number of connections are being un/intentionally being
>>> retried and/or dropped
>>> 
>> 
>> There is no much settings to tune syn requests.
>> tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow
> 
> The key is that you need a reproduceable test case and determine what type of
> changes you want to make.
> 
> also review the listen (backlog) code and : tcp.h: TCP_SYNQ_HSIZE
> 
> 	Other than that, their are MANY changes that can be done to scale this section
> 	of code.
> 
> 	What is the latency of serving an ACK? What is a RTT of a SYN/ACK?
> 	Why is each client trying to ESTABLISH a connection at the same time?
> 	etc.
> 
> 	Is your server capable of serving 3000 clients? Are they sending 1 MTU per sec,
> 	or are they doing 1000s of pings per sec, or are they doing bulk-data-transfer or?
> 	Thus, even if you are able to keep 3000 connections open at one time, can
> 	 your server properly respond to their requests in a timely manner?
> 
> 	Mitchell Erblich
> 
>> 
>> As for me, than I have about 3000 clients which do a little bit less then 3000 SYNs for nginx port.
>> I'm ok with sending syn cookies to clients. Also it's not possible to turn syncs off with setting
>> bigger value to tcp_max_syn_backlog and application works well so I would simple remove 
>> this messages from dmesg.
>> 
>> If I limit syncs with iptables it starts to drop needed packets. So it's no solution. That's why I think that we need turn off 
>> printk without turning off syn cookies.  
>> 
>>> Remember each printk may only be a small fraction of the number of SYNs
>>> rcv'd and this fraction COULD depend on the Mb/Gb of the intf(s) or more
>>> likely some type of  avg of summation of the number of network paths
>>> involved.
>>> 
>>> Mitchell Erblich
>>> 
>>> 

actually, MAYBE a PATCH of the freq (1x/sec, 1x/5 secs, 1x/30secs, 1x/60secs, 1x/3600 secs) with
1x per sec as the default of the printks WOULD be considered?

Mitchell Erblich

>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> 
>>> 
>>> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html