Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4638758ybi; Tue, 30 Jul 2019 05:39:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFF1+qTKgCNOvVaOtkBuEppJ2aO2dwUYCdQUouiVtwP4LhLB2EjcbJZILFSnBqK/QzHAQC X-Received: by 2002:a62:6344:: with SMTP id x65mr43481372pfb.111.1564490360898; Tue, 30 Jul 2019 05:39:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564490360; cv=none; d=google.com; s=arc-20160816; b=fFpjZIOd3rw4mHQbdHzpdR740brrvoVYi3bCJgSVyyhscEVq9fZqxVM6ue0cCcgP9j bRDxMgqHmkdfA0oj/b0OmseHpgwoKDSN9ueXI8F0QQPT6KqCSX4iuHFLULc1qHOpvg4E ePbrrtocHWgJKQbaPnryc5KvBRKnuUYeNuRyc53sqchlnDnXnIKb6YydZ3bBIRV1Ra8b pLbxh+8zVKH/g4ZjzUdXU0x9C9nNV+42vMduZ9GCaTUYCOUqDVYFmohJQP8eij4eoHxd XwPXM4Ugcf1vAZYNJ12ChGj2tZGD1pz725N80lI4N1hpOEG7RLH8ZwUIt1c5+GGw4D/k IQ6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=XZMQJ3FvYMofVIKYJJGF1rOFvFdk709HF9/ALbSFuU4=; b=zscl9bKLhyIC0a84ScqnWS8iCi+a1eNNdeNAVSi1dLctrlOpX1NLDCaqhFP3Qtpiwv 5o/Ej+7ckcbbU3djFTkYqsx+FLkRnkek6ALjIt9vLY7AJdGgVeYGNgtYmX+0hhn4c/QC hQJgON96CjHIudr86iDk2JGVfZZn6Lqza1pcxZ1nMKvX/NQxU5QD2AVDUY6CoPcfAMpD Y8I0RN0ApbGkQPdnFzFMLbr64yqOMjmIhmYpb18hgm1GOx/0oYvR1F40eYPkV7XqByOo Ihaw771Kv5zIj+Ohy9ZihPaZ8KP0tkQlWYQIPpZqRefOoOvcfWvolnDKAJuDRcZIVtOD 1Iig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n6si27754276pjb.73.2019.07.30.05.39.05; Tue, 30 Jul 2019 05:39:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730449AbfG3MgJ (ORCPT + 99 others); Tue, 30 Jul 2019 08:36:09 -0400 Received: from Chamillionaire.breakpoint.cc ([193.142.43.52]:42196 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726190AbfG3MgJ (ORCPT ); Tue, 30 Jul 2019 08:36:09 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1hsRLy-0003m8-Pk; Tue, 30 Jul 2019 14:35:42 +0200 Date: Tue, 30 Jul 2019 14:35:42 +0200 From: Florian Westphal To: Rundong Ge Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de, roopa@cumulusnetworks.com, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, bridge@lists.linux-foundation.org, nikolay@cumulusnetworks.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] bridge:fragmented packets dropped by bridge Message-ID: <20190730123542.zrsrfvcy7t2n3d4g@breakpoint.cc> References: <20190730122534.30687-1-rdong.ge@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190730122534.30687-1-rdong.ge@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rundong Ge wrote: > Given following setup: > -modprobe br_netfilter > -echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables > -brctl addbr br0 > -brctl addif br0 enp2s0 > -brctl addif br0 enp3s0 > -brctl addif br0 enp6s0 > -ifconfig enp2s0 mtu 1300 > -ifconfig enp3s0 mtu 1500 > -ifconfig enp6s0 mtu 1500 > -ifconfig br0 up > > multi-port > mtu1500 - mtu1500|bridge|1500 - mtu1500 > A | B > mtu1300 How can a bridge forward a frame from A/B to mtu1300? > With netfilter defragmentation/conntrack enabled, fragmented > packets from A will be defragmented in prerouting, and refragmented > at postrouting. Yes, but I don't see how that relates to the problem at hand. > But in this scenario the bridge found the frag_max_size(1500) is > larger than the dst mtu stored in the fake_rtable whitch is > always equal to the bridge's mtu 1300, then packets will be dopped. What happens without netfilter or non-fragmented packets? > This modifies ip_skb_dst_mtu to use the out dev's mtu instead > of bridge's mtu in bridge refragment. It seems quite a hack? The above setup should use a router, not a bridge.