diff mbox

Crazy TCP bug (keepalive flood?) in 2.6.32?

Message ID alpine.DEB.2.00.1001191308490.14108@wel-95.cs.helsinki.fi
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Ilpo Järvinen Jan. 19, 2010, 11:17 a.m. UTC
On Tue, 19 Jan 2010, Denys Fedoryshchenko wrote:

> On Tuesday 19 January 2010 11:10:12 you wrote:
> > Hi,
> > thank you for testing. So srtt and rttvar is zero in any of those cases.
> > Ilpo, it is a bug in tcp_rtt_estimator then, I suppose?
> > 
> > There is also a code comment in tcp_input.c, saying:
> > > * NOTE: clamping at TCP_RTO_MIN is not required, current algo
> > > * guarantees that rto is higher.
> > 
> > So we either fix tcp_rtt_estimator or simply clamp at TCP_RTO_MIN?
> > 
> > Damian
> > 
> > > On Monday 11 January 2010 15:02:34 you wrote:
> > >> On Sat, 26 Dec 2009, Denys Fedoryshchenko wrote:
> > >>> Few more dumps. I notice:
> > >>> 1)Ack always equal 1
> > >>> 2)It is usually first segment of data sent (?)
> > >>>
> > >>> Maybe some value not initialised properly?
> > >>
> > >> Can you see if the RTO lower bound is violated (I added some printing of
> > >> vars there too already now if it turns out to be something):
> > >>
> > >> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > >> index 65b8ebf..d84469f 100644
> > >> --- a/net/ipv4/tcp_ipv4.c
> > >> +++ b/net/ipv4/tcp_ipv4.c
> As i see in code it is rounding RTO to minimum value.
> It fixes my problem seems.
> 
> Btw just a bit about my environment - wireless networks (sometimes lossy!) 
> with low speed (128-512Kbps) customers working over pppoe. Maybe it will give 
> a tip why rtt value is too low.

What I find most strange in it is the fact that when it triggers for the 
first time, the srtt and mdev are zero, not some value in between 0 and 
200ms. Therefore I suspect that this case might be something that we've 
overlooked where srtt/mdev are not valid at all.

Maybe the patch below helps...

Comments

Denys Fedoryshchenko Jan. 23, 2010, 9:37 p.m. UTC | #1
On Tuesday 19 January 2010 13:17:51 you wrote:
> On Tue, 19 Jan 2010, Denys Fedoryshchenko wrote:
> > On Tuesday 19 January 2010 11:10:12 you wrote:
> > > Hi,
> > > thank you for testing. So srtt and rttvar is zero in any of those
> > > cases. Ilpo, it is a bug in tcp_rtt_estimator then, I suppose?
> > >
> > > There is also a code comment in tcp_input.c, saying:
> > > > * NOTE: clamping at TCP_RTO_MIN is not required, current algo
> > > > * guarantees that rto is higher.
> > >
> > > So we either fix tcp_rtt_estimator or simply clamp at TCP_RTO_MIN?
> > >
> > > Damian
> > >
> > > > On Monday 11 January 2010 15:02:34 you wrote:
> > > >> On Sat, 26 Dec 2009, Denys Fedoryshchenko wrote:
> > > >>> Few more dumps. I notice:
> > > >>> 1)Ack always equal 1
> > > >>> 2)It is usually first segment of data sent (?)
> > > >>>
> > > >>> Maybe some value not initialised properly?
> > > >>
> > > >> Can you see if the RTO lower bound is violated (I added some
> > > >> printing of vars there too already now if it turns out to be
> > > >> something):
> > > >>
> > > >> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > > >> index 65b8ebf..d84469f 100644
> > > >> --- a/net/ipv4/tcp_ipv4.c
> > > >> +++ b/net/ipv4/tcp_ipv4.c
> >
> > As i see in code it is rounding RTO to minimum value.
> > It fixes my problem seems.
> >
> > Btw just a bit about my environment - wireless networks (sometimes
> > lossy!) with low speed (128-512Kbps) customers working over pppoe. Maybe
> > it will give a tip why rtt value is too low.
> 
> What I find most strange in it is the fact that when it triggers for the
> first time, the srtt and mdev are zero, not some value in between 0 and
> 200ms. Therefore I suspect that this case might be something that we've
> overlooked where srtt/mdev are not valid at all.
> 
> Maybe the patch below helps...
> 
Seems after this patch (and debug patch with warnings) my dmesg is clean.
--
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 mbox

Patch

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 65b8ebf..c8166d7 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -401,6 +417,9 @@  void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
 		 * (see draft-zimmermann-tcp-lcd) */
 		if (code != ICMP_NET_UNREACH && code != ICMP_HOST_UNREACH)
 			break;
+		/* A bit too strict, just want to be on the safe side for now */
+		if (sk->sk_state != TCP_ESTABLISHED)
+			break;
 		if (seq != tp->snd_una  || !icsk->icsk_retransmits ||
 		    !icsk->icsk_backoff)
 			break;