From patchwork Mon Aug 19 22:07:00 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jozsef Kadlecsik X-Patchwork-Id: 268310 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id E923A2C0129 for ; Tue, 20 Aug 2013 08:07:06 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751187Ab3HSWHE (ORCPT ); Mon, 19 Aug 2013 18:07:04 -0400 Received: from smtp0.kfki.hu ([148.6.0.25]:35407 "EHLO smtp0.kfki.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751132Ab3HSWHD (ORCPT ); Mon, 19 Aug 2013 18:07:03 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp0.kfki.hu (Postfix) with ESMTP id 3E88D4D401F; Tue, 20 Aug 2013 00:07:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at smtp0.kfki.hu Received: from smtp0.kfki.hu ([127.0.0.1]) by localhost (smtp0.kfki.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7wWtoZ0i2UQ; Tue, 20 Aug 2013 00:07:01 +0200 (CEST) Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114]) by smtp0.kfki.hu (Postfix) with ESMTP id E58524D401C; Tue, 20 Aug 2013 00:07:00 +0200 (CEST) Received: by blackhole.kfki.hu (Postfix, from userid 1000) id 94DB5208181; Tue, 20 Aug 2013 00:07:00 +0200 (CEST) Date: Tue, 20 Aug 2013 00:07:00 +0200 (CEST) From: Jozsef Kadlecsik To: Eric Dumazet cc: Christoph Paasch , Corey Hickey , Linux Netdev List , netfilter-devel@vger.kernel.org Subject: Re: NAT stops forwarding ACKs after PMTU discovery In-Reply-To: <1376946527.4226.80.camel@edumazet-glaptop> Message-ID: References: <521061B4.1030508@fatooh.org> <1376839467.21329.36.camel@edumazet-glaptop> <1376870425.4226.25.camel@edumazet-glaptop> <1376870592.4226.27.camel@edumazet-glaptop> <5211DAA6.1070302@fatooh.org> <20130819123314.GC3583@cpaasch-mac> <1376918657.4226.59.camel@edumazet-glaptop> <20130819134919.GF3583@cpaasch-mac> <1376920685.4226.61.camel@edumazet-glaptop> <1376946527.4226.80.camel@edumazet-glaptop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org On Mon, 19 Aug 2013, Eric Dumazet wrote: > 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. Yes, exactly. > I do not think I shot anyone, only stated the truth. There's a middlebox in the path wich breaks SACK completely and conntrack drops (technically marks as INVALID) the packets with bogus SACK options. It can be fixed by fixing the middlebox, or disabling SACK by the TCPOPTSTRIP target, or by relaxing conntrack. For the latter, the next untested patch may be sufficient: However it is good to cover the issue thus? > 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) *Any* netfilter configuration where the non-allowed TCP packets are dropped and not rejected breaks the ACK challenges. That is why I consider only section 5 useful from RFC 5961. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary --- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c index 7dcc376..8b5d783 100644 --- a/net/netfilter/nf_conntrack_proto_tcp.c +++ b/net/netfilter/nf_conntrack_proto_tcp.c @@ -649,6 +649,11 @@ static bool tcp_in_window(const struct nf_conn *ct, receiver->td_end, receiver->td_maxend, receiver->td_maxwin, receiver->td_scale); + /* Fall back to ACK when SACK is bogus */ + if (!(before(sack, receiver->td_end + 1) && + after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1))) + sack = ack; + pr_debug("tcp_in_window: I=%i II=%i III=%i IV=%i\n", before(seq, sender->td_maxend + 1), after(end, sender->td_end - receiver->td_maxwin - 1),