[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130819180043.GA31511@linuxace.com>
Date: Mon, 19 Aug 2013 11:00:43 -0700
From: Phil Oester <kernel@...uxace.com>
To: Christoph Paasch <christoph.paasch@...ouvain.be>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Corey Hickey <bugfood-ml@...ooh.org>,
Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
Linux Netdev List <netdev@...r.kernel.org>,
netfilter-devel@...r.kernel.org
Subject: Re: NAT stops forwarding ACKs after PMTU discovery
On Mon, Aug 19, 2013 at 07:15:19PM +0200, Christoph Paasch wrote:
> On 19/08/13 - 09:00:31, Eric Dumazet wrote:
> > On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
> > > Unfortunately, they will hardly go away in the near futur. Rather the
> > > opposite is the case.
> > >
> > >
> > > If you have a public server running, I would be interested in the count of
> > > invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> > > indication for such kind of middlebox between your server and the client,
> > > implying that these connections cannot benefit from TCP-FastRetransmission
> > > and each packet-loss will require an RTO to recover.
> > >
> >
> > If the (random) sequence offset is small rather than completely out of
> > window, it's going to be hard to detect all problems.
It is not small unfortunately. The bug is that with ISN randomization enabled
the PIX leaves the SACK sequence numbers untouched. For reference, the cisco
bug is CSCse14419.
> Yes, it is not possible to make it 100% perfect. But considering the size of
> the seq-space, the probability is rather low that the SACK-block falls
> in-window.
s/rather low/nil/
> > Show us your patch ;)
Or just disable SACK on the box behind the problematic PIX.
Phil
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists