public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Christoph Paasch <christoph.paasch@uclouvain.be>,
	Corey Hickey <bugfood-ml@fatooh.org>,
	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 14:08:47 -0700	[thread overview]
Message-ID: <1376946527.4226.80.camel@edumazet-glaptop> (raw)
In-Reply-To: <alpine.DEB.2.00.1308192207130.27869@blackhole.kfki.hu>

On Mon, 2013-08-19 at 22:13 +0200, Jozsef Kadlecsik wrote:
> On Mon, 19 Aug 2013, Eric Dumazet wrote:
> 
> > On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> >
> > > It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> > > duplicate acks in tcp_sock->sacked_out.
> > 
> > Yeah, but here, this is conntrack who is blocking the thing.
> > 
> > TCP receiver has no chance to 'fix' it.
> > 
> > See conntrack is one of those buggy middle box as well.
> > 
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
> 
> I beg you pardon: why conntrack should be relaxed, when it is expected
> to do more strict TCP checkings (RFC5961, Section 5.).
> 
> Also, it's clearly a broken middle box. Don't shoot the messenger.

Frames are dropped by conntrack, before TCP receiver can even have a
choice.

So Christoph patch would be of no use for Corey.

I do not think I shot anyone, only stated the truth.

We have workarounds in our stack to 'fix' bugs from others, there
is no shame in this.

Glad to see you are interested in RFC 5961 support, as conntrack is
known to break the ACK challenges in response to RST messages (section
3)

  parent reply	other threads:[~2013-08-19 21:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-18  5:55 NAT stops forwarding ACKs after PMTU discovery Corey Hickey
2013-08-18 15:24 ` 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
2013-08-19 18:10                           ` Eric Dumazet
2013-08-19 19:29                             ` [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks Christoph Paasch
2013-08-19 19:29                               ` [RFC 1/2] Use acked_out for reno-style ack acounting instead of sacked_out Christoph Paasch
2013-08-19 19:29                               ` [RFC 2/2] Account acked_out in sack, if the sack is invalid Christoph Paasch
2013-08-19 21:22                               ` [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks Corey Hickey
2013-08-20  7:36                                 ` Christoph Paasch
2013-08-22  3:32                               ` David Miller
2013-08-22  4:15                                 ` Corey Hickey
2013-08-19 14:43                   ` NAT stops forwarding ACKs after PMTU discovery Christoph Paasch
2013-08-19 20:13                   ` Jozsef Kadlecsik
2013-08-19 20:43                     ` Christoph Paasch
2013-08-19 21:08                     ` Eric Dumazet [this message]
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=1376946527.4226.80.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=bugfood-ml@fatooh.org \
    --cc=christoph.paasch@uclouvain.be \
    --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