From: Phil Oester <kernel@linuxace.com>
To: Christoph Paasch <christoph.paasch@uclouvain.be>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Corey Hickey <bugfood-ml@fatooh.org>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
Linux Netdev List <netdev@vger.kernel.org>,
netfilter-devel@vger.kernel.org
Subject: Re: NAT stops forwarding ACKs after PMTU discovery
Date: Mon, 19 Aug 2013 11:00:43 -0700 [thread overview]
Message-ID: <20130819180043.GA31511@linuxace.com> (raw)
In-Reply-To: <20130819171519.GA4008@cpaasch-mac>
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
next prev parent reply other threads:[~2013-08-19 18:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <521061B4.1030508@fatooh.org>
2013-08-18 15:24 ` NAT stops forwarding ACKs after PMTU discovery Eric Dumazet
2013-08-18 16:59 ` Corey Hickey
2013-08-18 21:23 ` Jozsef Kadlecsik
2013-08-19 0:00 ` Eric Dumazet
2013-08-19 0:03 ` Eric Dumazet
2013-08-19 8:43 ` Corey Hickey
2013-08-19 12:33 ` Christoph Paasch
2013-08-19 13:24 ` Eric Dumazet
2013-08-19 13:49 ` Christoph Paasch
2013-08-19 13:58 ` Eric Dumazet
2013-08-19 14:35 ` Phil Oester
2013-08-19 15:32 ` Eric Dumazet
2013-08-19 15:33 ` Christoph Paasch
2013-08-19 16:00 ` Eric Dumazet
2013-08-19 17:15 ` Christoph Paasch
2013-08-19 18:00 ` Phil Oester [this message]
2013-08-19 18:10 ` Eric Dumazet
2013-08-19 14:43 ` Christoph Paasch
2013-08-19 20:13 ` Jozsef Kadlecsik
2013-08-19 20:43 ` Christoph Paasch
2013-08-19 21:08 ` Eric Dumazet
2013-08-19 22:07 ` Jozsef Kadlecsik
2013-08-20 4:18 ` Corey Hickey
2013-08-19 18:22 ` Corey Hickey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130819180043.GA31511@linuxace.com \
--to=kernel@linuxace.com \
--cc=bugfood-ml@fatooh.org \
--cc=christoph.paasch@uclouvain.be \
--cc=eric.dumazet@gmail.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).