| Message ID | 503419D3.1080700@linlab.net |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
On Wed, 2012-08-22 at 01:29 +0200, Alex Bergmann wrote: > Hi David, > > I'm not 100% sure, but it looks like I found an RFC mismatch with the > current default values of the TCP implementation. > > Alex > > From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001 > From: Alexander Bergmann <alex@linlab.net> > Date: Wed, 22 Aug 2012 00:29:08 +0200 > Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments > > Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to > RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that > defines a minimum retransmission window for SYN segments of at least > 180secs. > > Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only > a timeout of 63secs. > > ((2 << 5) - 1) * 3 secs = 189 secs > ((2 << 5) - 1) * 1 secs = 63 secs Strange maths ... here I have : (1+2+4+8+16) * 3 = 93 secs vs (1+2+4+8+16) * 1 = 31 secs So even before said commit, we were not rfc1122 compliant. Using 7 retries would give 127 seconds, still not rfc compliant. > > To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for > SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must > be changed to 7 reties. > > ((2 << 7) - 1) * 1 secs = 255 secs > > This would result in an ETIMEDOUT of 4 minutes 15 seconds. > > Signed-off-by: Alexander Bergmann <alex@linlab.net> > --- > include/net/tcp.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 1f000ff..7eaae19 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo); > * 15 is ~13-30min depending on RTO. > */ > > -#define TCP_SYN_RETRIES 5 /* number of times to retry active opening a > +#define TCP_SYN_RETRIES 7 /* number of times to retry active opening a > * connection: ~180sec is RFC minimum */ > > -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a > +#define TCP_SYNACK_RETRIES 7 /* number of times to retry passive opening a > * connection: ~180sec is RFC minimum */ > > #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT Nice catch ! I kind of disagree with the SYNACK part. RFC 1122 says in 4.2.3.5 : However, the values of R1 and R2 may be different for SYN and data segments. In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes. The application can close the connection (i.e., give up on the open attempt) sooner, of course. I am not sure SYNACK segments were considered as a 'SYN segment' in this section. (as the application cannot 'close' the connection on the passive side, only kernel is aware of a SYN_RECV socket) Increasing TCP_SYNACK_RETRIES from 5 to 7 or 8 amplifies the SYN/synflood problem. A valid client should retransmit its SYN packet for 180 seconds, I dont believe we should make sure the SYNACK will be sent for 180 seconds as well. If we _really_ want to have a 3 minutes R2 for SYNACK, I suggest changing things to that we dont send more than 5 SYNACKS, maybe using RTO=6 after one retransmit current situation : 1 sec 2 sec 4 sec 8 sec 16 sec ---- total of 31 seconds 1 sec 12 sec // switch to RTO = 6 24 sec 48 sec 96 sec ----- total of 181 seconds -- 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
On 08/22/2012 10:06 AM, Eric Dumazet wrote: >> Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only >> a timeout of 63secs. >> >> ((2 << 5) - 1) * 3 secs = 189 secs >> ((2 << 5) - 1) * 1 secs = 63 secs > > Strange maths ... here I have : > > (1+2+4+8+16) * 3 = 93 secs > vs > (1+2+4+8+16) * 1 = 31 secs > > So even before said commit, we were not rfc1122 compliant. > > Using 7 retries would give 127 seconds, still not rfc compliant. You're missing the timeout after the 5th SYN packet was sent. This would result in another 32 seconds (96 seconds). The timeout is calculated here: net/ipv4/tcp_timer.c(146:150) if (boundary <= linear_backoff_thresh) timeout = ((2 << boundary) - 1) * rto_base; else timeout = ((2 << linear_backoff_thresh) - 1) * rto_base + (boundary - linear_backoff_thresh) * TCP_RTO_MAX; > >> >> To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for >> SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must >> be changed to 7 reties. >> >> ((2 << 7) - 1) * 1 secs = 255 secs >> >> This would result in an ETIMEDOUT of 4 minutes 15 seconds. >> >> Signed-off-by: Alexander Bergmann <alex@linlab.net> >> --- >> include/net/tcp.h | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/net/tcp.h b/include/net/tcp.h >> index 1f000ff..7eaae19 100644 >> --- a/include/net/tcp.h >> +++ b/include/net/tcp.h >> @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo); >> * 15 is ~13-30min depending on RTO. >> */ >> >> -#define TCP_SYN_RETRIES 5 /* number of times to retry active opening a >> +#define TCP_SYN_RETRIES 7 /* number of times to retry active opening a >> * connection: ~180sec is RFC minimum */ >> >> -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a >> +#define TCP_SYNACK_RETRIES 7 /* number of times to retry passive opening a >> * connection: ~180sec is RFC minimum */ >> >> #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT > > Nice catch ! > > I kind of disagree with the SYNACK part. I will look into this. > RFC 1122 says in 4.2.3.5 : > > However, the values of R1 and R2 may be different for SYN > and data segments. In particular, R2 for a SYN segment MUST > be set large enough to provide retransmission of the segment > for at least 3 minutes. The application can close the > connection (i.e., give up on the open attempt) sooner, of > course. > > I am not sure SYNACK segments were considered as a 'SYN segment' in this > section. (as the application cannot 'close' the connection on the passive > side, only kernel is aware of a SYN_RECV socket) > > Increasing TCP_SYNACK_RETRIES from 5 to 7 or 8 amplifies the > SYN/synflood problem. > > A valid client should retransmit its SYN packet for 180 seconds, I dont > believe we should make sure the SYNACK will be sent for 180 seconds as > well. > > If we _really_ want to have a 3 minutes R2 for SYNACK, I suggest > changing things to that we dont send more than 5 SYNACKS, maybe using > RTO=6 after one retransmit > > current situation : > 1 sec > 2 sec > 4 sec > 8 sec > 16 sec > ---- > total of 31 seconds > > > 1 sec > 12 sec // switch to RTO = 6 > 24 sec > 48 sec > 96 sec > ----- > total of 181 seconds > > > -- 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
On Wed, 2012-08-22 at 10:48 +0200, Alex Bergmann wrote: > On 08/22/2012 10:06 AM, Eric Dumazet wrote: > >> Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only > >> a timeout of 63secs. > >> > >> ((2 << 5) - 1) * 3 secs = 189 secs > >> ((2 << 5) - 1) * 1 secs = 63 secs > > > > Strange maths ... here I have : > > > > (1+2+4+8+16) * 3 = 93 secs > > vs > > (1+2+4+8+16) * 1 = 31 secs > > > > So even before said commit, we were not rfc1122 compliant. > > > > Using 7 retries would give 127 seconds, still not rfc compliant. > > You're missing the timeout after the 5th SYN packet was sent. This > would result in another 32 seconds (96 seconds). > > The timeout is calculated here: > > net/ipv4/tcp_timer.c(146:150) > > if (boundary <= linear_backoff_thresh) > timeout = ((2 << boundary) - 1) * rto_base; > else > timeout = ((2 << linear_backoff_thresh) - 1) * rto_base + > (boundary - linear_backoff_thresh) * TCP_RTO_MAX; Thats the code yes but you miss the fact that last occurence of the timer doesnt send a frame on the _network_ R2 is derived from the last frame sent. Fact that the connect() is a bit long to return to user space is not relevant. We could block the task for 2 hours and still be non RFC compliant. Actual 5 frames are sent, so the effective global timeout is the one I quoted. 1 + 2 + 4 + 8 + 16 and its 31 Just do a tcpdump and you can see it. -- 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
On 08/22/2012 10:58 AM, Eric Dumazet wrote: > On Wed, 2012-08-22 at 10:48 +0200, Alex Bergmann wrote: >> On 08/22/2012 10:06 AM, Eric Dumazet wrote: >>>> Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only >>>> a timeout of 63secs. >>>> >>>> ((2 << 5) - 1) * 3 secs = 189 secs >>>> ((2 << 5) - 1) * 1 secs = 63 secs >>> >>> Strange maths ... here I have : >>> >>> (1+2+4+8+16) * 3 = 93 secs >>> vs >>> (1+2+4+8+16) * 1 = 31 secs >>> >>> So even before said commit, we were not rfc1122 compliant. >>> >>> Using 7 retries would give 127 seconds, still not rfc compliant. >> >> You're missing the timeout after the 5th SYN packet was sent. This >> would result in another 32 seconds (96 seconds). >> >> The timeout is calculated here: >> >> net/ipv4/tcp_timer.c(146:150) >> >> if (boundary <= linear_backoff_thresh) >> timeout = ((2 << boundary) - 1) * rto_base; >> else >> timeout = ((2 << linear_backoff_thresh) - 1) * rto_base + >> (boundary - linear_backoff_thresh) * TCP_RTO_MAX; > > Thats the code yes but you miss the fact that last occurence of the > timer doesnt send a frame on the _network_ > > R2 is derived from the last frame sent. > > Fact that the connect() is a bit long to return to user space is not > relevant. We could block the task for 2 hours and still be non RFC > compliant. > > Actual 5 frames are sent, so the effective global timeout is the one I > quoted. > > 1 + 2 + 4 + 8 + 16 and its 31 > > Just do a tcpdump and you can see it. Actual 6 SYN frames are sent. The initial one and 5 retries. The kernel is waiting another 32 seconds for a SYN+ACK and then gives the ETIMEDOUT back to userspace. Do you mean that we have to send another SYN packet after the 3 minutes? -- 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
On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote: > Actual 6 SYN frames are sent. The initial one and 5 retries. > first one had a t0 + 0 delay. How can it count ??? > The kernel is waiting another 32 seconds for a SYN+ACK and then gives > the ETIMEDOUT back to userspace. > > Do you mean that we have to send another SYN packet after the 3 minutes? > First SYN is not a retransmit R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31 If you read RFC it states : "In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes." That means that the last _retransmit_ MUST happen after 180 seconds. And not : Send all the restransmits at t0 + 1, then wait 180 seconds before giving connect() a timeout indication. -- 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
On Wed, 2012-08-22 at 12:00 +0200, Eric Dumazet wrote: > On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote: > > > Actual 6 SYN frames are sent. The initial one and 5 retries. > > > > first one had a t0 + 0 delay. How can it count ??? > > > The kernel is waiting another 32 seconds for a SYN+ACK and then gives > > the ETIMEDOUT back to userspace. > > > > Do you mean that we have to send another SYN packet after the 3 minutes? > > > > First SYN is not a retransmit > > R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31 > > If you read RFC it states : > > "In particular, R2 for a SYN segment MUST > be set large enough to provide retransmission of the segment > for at least 3 minutes." > > > That means that the last _retransmit_ MUST happen after 180 seconds. > > And not : > > Send all the restransmits at t0 + 1, then wait 180 seconds before giving > connect() a timeout indication. > > Therefore, the minimal connect() timeout should be : 180 + 100 seconds (allowing 100 seconds for the SYNACKs sent in answer of the very last retransmit to come back) (100 seconds is the R2 for non SYN frames) RFC quote : The value of R2 SHOULD correspond to at least 100 seconds. -- 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
On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <alex@linlab.net> wrote: > Hi David, > > I'm not 100% sure, but it looks like I found an RFC mismatch with the > current default values of the TCP implementation. > > Alex > > From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001 > From: Alexander Bergmann <alex@linlab.net> > Date: Wed, 22 Aug 2012 00:29:08 +0200 > Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments > > Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to > RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that > defines a minimum retransmission window for SYN segments of at least > 180secs. > > Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only > a timeout of 63secs. > > ((2 << 5) - 1) * 3 secs = 189 secs > ((2 << 5) - 1) * 1 secs = 63 secs > > To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for > SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must > be changed to 7 reties. > > ((2 << 7) - 1) * 1 secs = 255 secs > > This would result in an ETIMEDOUT of 4 minutes 15 seconds. This issue occurred to me right after I submitted the patch for RFC6298. I did not commit any more change because RFC compliance aside, 180secs just seem like eternity in the Internet age. (See my past post on this at http://marc.info/?l=linux-netdev&m=130759078118866&w=2) Jerry > > Signed-off-by: Alexander Bergmann <alex@linlab.net> > --- > include/net/tcp.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 1f000ff..7eaae19 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo); > * 15 is ~13-30min depending on RTO. > */ > > -#define TCP_SYN_RETRIES 5 /* number of times to retry active opening a > +#define TCP_SYN_RETRIES 7 /* number of times to retry active opening a > * connection: ~180sec is RFC minimum */ > > -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a > +#define TCP_SYNACK_RETRIES 7 /* number of times to retry passive opening a > * connection: ~180sec is RFC minimum */ > > #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT > -- > 1.7.8.6 > > -- > 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
On Wed, Aug 22, 2012 at 3:03 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > On Wed, 2012-08-22 at 12:00 +0200, Eric Dumazet wrote: >> On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote: >> >> > Actual 6 SYN frames are sent. The initial one and 5 retries. >> > >> >> first one had a t0 + 0 delay. How can it count ??? >> >> > The kernel is waiting another 32 seconds for a SYN+ACK and then gives >> > the ETIMEDOUT back to userspace. >> > >> > Do you mean that we have to send another SYN packet after the 3 minutes? >> > >> >> First SYN is not a retransmit >> >> R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31 >> >> If you read RFC it states : >> >> "In particular, R2 for a SYN segment MUST >> be set large enough to provide retransmission of the segment >> for at least 3 minutes." >> >> >> That means that the last _retransmit_ MUST happen after 180 seconds. >> >> And not : >> >> Send all the restransmits at t0 + 1, then wait 180 seconds before giving >> connect() a timeout indication. >> >> > > Therefore, the minimal connect() timeout should be : 180 + 100 seconds > > (allowing 100 seconds for the SYNACKs sent in answer of the very last > retransmit to come back) > > (100 seconds is the R2 for non SYN frames) > > RFC quote : The value of R2 SHOULD > correspond to at least 100 seconds. I agree if you take RFC1122 literally the last retransmission must happen no less than 3 minutes from the 1st SYN... Oh actually it'd be 3 minutes plus initRTO because the 3 minutes applies only to "retransmission" as in "R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes.: But IMHO 6 retries providing 1+2+4+8+16+32 = 63 secs retransmission plus 64 secs wait time totaling 127 secs is really plenty enough. You have a good point on SYN-ACK. Jerry > > > > -- > 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
On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote: > On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <alex@linlab.net > <mailto:alex@linlab.net>> wrote: > > Hi David, > > I'm not 100% sure, but it looks like I found an RFC mismatch with the > current default values of the TCP implementation. > > Alex > > From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001 > From: Alexander Bergmann <alex@linlab.net <mailto:alex@linlab.net>> > Date: Wed, 22 Aug 2012 00:29:08 +0200 > Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments > > Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to > RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that > defines a minimum retransmission window for SYN segments of at least > 180secs. > > Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only > a timeout of 63secs. > > ((2 << 5) - 1) * 3 secs = 189 secs > ((2 << 5) - 1) * 1 secs = 63 secs > > To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for > SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must > be changed to 7 reties. > > ((2 << 7) - 1) * 1 secs = 255 secs > > This would result in an ETIMEDOUT of 4 minutes 15 seconds. > > > This issue occurred to me right after I submitted the patch for RFC6298. > I did not commit any more change because RFC compliance aside, 180secs > just seem like eternity in the Internet age. > > (See my past post on this at > http://marc.info/?l=linux-netdev&m=130759078118866&w=2) Okay, I missed that post during my search about the current situation. Thanks, Alex > Jerry > > > Signed-off-by: Alexander Bergmann <alex@linlab.net > <mailto:alex@linlab.net>> > --- > include/net/tcp.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 1f000ff..7eaae19 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int > state, int timeo); > * 15 is ~13-30min depending on RTO. > */ > > -#define TCP_SYN_RETRIES 5 /* number of times to retry > active opening a > +#define TCP_SYN_RETRIES 7 /* number of times to retry > active opening a > * connection: ~180sec is RFC > minimum */ > > -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive > opening a > +#define TCP_SYNACK_RETRIES 7 /* number of times to retry passive > opening a > * connection: ~180sec is RFC > minimum */ > > #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy > TIME-WAIT > -- > 1.7.8.6 > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > <mailto:majordomo@vger.kernel.org> > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote: > On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote: > > This issue occurred to me right after I submitted the patch for RFC6298. > > I did not commit any more change because RFC compliance aside, 180secs > > just seem like eternity in the Internet age. > > > > (See my past post on this at > > http://marc.info/?l=linux-netdev&m=130759078118866&w=2) > > Okay, I missed that post during my search about the current situation. I would suggest to increase TCP_SYN_RETRIES from 5 to 6. 180 secs is eternity, but 31 secs is too small. Can you repost a v2, only changing TCP_SYN_RETRIES ? -- 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
> I would suggest to increase TCP_SYN_RETRIES from 5 to 6. > > 180 secs is eternity, but 31 secs is too small. Wasn't the intention of the long delay to allow a system acting as a router to reboot? I suspect that is why it (and some other TCP timers) are in minutes. David
On Thu, 2012-08-23 at 13:35 +0100, David Laight wrote: > > I would suggest to increase TCP_SYN_RETRIES from 5 to 6. > > > > 180 secs is eternity, but 31 secs is too small. > > Wasn't the intention of the long delay to allow a system > acting as a router to reboot? > I suspect that is why it (and some other TCP timers) > are in minutes. One could argue that if an application really wants to connect to a peer, it should probably handle failures and retries. But for unaware (basic ?) applications, the 3 -> 1 change reduced by a 3 factor the timeout. So a transient network failure has now more chance to impact them. Not all applications run inside a browser or under human control... -- 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
diff --git a/include/net/tcp.h b/include/net/tcp.h index 1f000ff..7eaae19 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo); * 15 is ~13-30min depending on RTO. */ -#define TCP_SYN_RETRIES 5 /* number of times to retry active opening a +#define TCP_SYN_RETRIES 7 /* number of times to retry active opening a * connection: ~180sec is RFC minimum */ -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a +#define TCP_SYNACK_RETRIES 7 /* number of times to retry passive opening a * connection: ~180sec is RFC minimum */ #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT