Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4940305ybi; Tue, 30 Jul 2019 10:50:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqx++x8vXnY/MtrcHYK7ySLa6STwC3F6zsHaX2WDiC323DgkIcXOwSpqJZYXstnhyNPHY2H6 X-Received: by 2002:a17:902:f089:: with SMTP id go9mr115923990plb.81.1564509000192; Tue, 30 Jul 2019 10:50:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564509000; cv=none; d=google.com; s=arc-20160816; b=RBDQ1Bt7d5qibiRNDGvMzYhr5LAo86eLiBS8t5ZuTAYBQ40S3W15w9A4L/uptsJpEu Przy1TFwoOkB5s0jlM86Ss/MSy0DC8UigtJZruRAw7G5K8wy9pCgDjevn9SZhNaf51b+ RKRGUKRk0fKsTWs7heERdMMHFVYKxDAYOQBNLdaReiOFLGhvf9DO7vw1fPa2WmIItlFT 1lI/sfdUvd54BYhpskmADQCKxr3faNRNVQXUuwJK0U5vrNkgt6N7MbYs77NHpeapdQPn Qizzi5C94MtCBB+9s9K7uiWuwCVwnIPPQy1V7w04jhFIQKBYPvYNeLbYn7CjiPeJRqgH DaGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4+QxDKECEbt2nsi9n15vlp6tEfk79Z3ydNqFgvycDug=; b=jx7kjQOFR00ce5mKkTzwgruo2gzgMf9TIGshcPWNnZ34IluqMttq9K4XOBRQ8vDk3e jHLkq6SsQo2hlHQBLGkr6/GDPO25sCLDjbrNhtfX6xE9Aa+gFQkXRN3JUCump42RkZ7P LhJXOqbVEcuiqrKzJ/M/uZDjJ/Y3rtdIerx45j87/Sig/bPhO7rq6qONFm1DAZ/bd3kZ mgQJAhG4dOasxOlU3kqU7G35WyvjQbByjBI+Zh4h4AHqUGytHuiD4yaGV7Y+OjvKtlBf PekCUDjwrfEktpaXEUjuuyFL9ILU8Hu0hfjSZNnrwTbiRzSbmtfce1a5UgGFEV45J3jI qFjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lbbXElZc; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t16si26749124ply.133.2019.07.30.10.49.45; Tue, 30 Jul 2019 10:50:00 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lbbXElZc; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727600AbfG3NuS (ORCPT + 99 others); Tue, 30 Jul 2019 09:50:18 -0400 Received: from mail-ua1-f65.google.com ([209.85.222.65]:41184 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725871AbfG3NuS (ORCPT ); Tue, 30 Jul 2019 09:50:18 -0400 Received: by mail-ua1-f65.google.com with SMTP id 34so25465464uar.8; Tue, 30 Jul 2019 06:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4+QxDKECEbt2nsi9n15vlp6tEfk79Z3ydNqFgvycDug=; b=lbbXElZcWDWcO7idRfKRT150JkbaE34ZAm5/7WQDWq5VmH58byLnlTttxLjULzGnHi juIjzfAjttSH+39RkV37/FitX0rPvUZjgqNlP8vrm00v0kNql78LyEheKW1AkIAmz4Hr etUy5fge2yzDyv/fLs3IIaWr4M7LBfGOQVr8BtCESNX+Do6SoDJ2tS0KgeYravub+ozp yHOS4INVM3CYGw8okECC5dy8I41Sk1AAsWaLM2PXz3FctBuH69ARB5Ddof1scefU7Gy3 TODHQ18+YhCJHQC2eSWwGl8MvutnGGuJaIIW9IOdwVbIQkc2oZQz5ap0aAEhFV5qTgRj CuAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4+QxDKECEbt2nsi9n15vlp6tEfk79Z3ydNqFgvycDug=; b=bCkG3t0qhhGwo5nOfK7XhY3XEnWBObuO5n/TsGojmBZDy4REDTO5o0rQxEsXOmKrbF cU7swAePAy/LRxb/cTYyRVbKqyyfwDtHNQzeSr/+xC/F+emFKB0K5B/vfAuC+pRRFxjA zCPglN+1zb5734xB/OUJbxFzbmX0He2Klbmp0nL9s9m4q21THsnyuomn6Mk23rii5lLG WvadAX3CEz209ZSBhTxsmwRr64bMtyMkXn8S8qT31mSsnXdOssFyN85QaTGxLFFu/U0Z Dote48J2WDj07hXUH0I0vItolS2kKHpUppPqlX1Uf3G8e8PDLm+4+d+paNOqvQjkU5DW qzGg== X-Gm-Message-State: APjAAAXpBFZaWtvtAJNqgnpNhgqxV259JzQPxApWoMQ3G4yHn38Z7ymE Mu1/tsWDo5Kc346pLsDcealx6zusn3yVe5rsaw== X-Received: by 2002:a9f:25e9:: with SMTP id 96mr57807432uaf.95.1564494616946; Tue, 30 Jul 2019 06:50:16 -0700 (PDT) MIME-Version: 1.0 References: <20190730122534.30687-1-rdong.ge@gmail.com> <20190730123542.zrsrfvcy7t2n3d4g@breakpoint.cc> In-Reply-To: <20190730123542.zrsrfvcy7t2n3d4g@breakpoint.cc> From: Rundong Ge Date: Tue, 30 Jul 2019 21:50:05 +0800 Message-ID: Subject: Re: [PATCH] bridge:fragmented packets dropped by bridge To: Florian Westphal Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, Pablo Neira Ayuso , kadlec@netfilter.org, Roopa Prabhu , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, bridge@lists.linux-foundation.org, nikolay@cumulusnetworks.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > How can a bridge forward a frame from A/B to mtu1300? It is free for user to set different MTU for bridge ports. In our case only tcp traffic between A/B and mtu 1300, and mss negotiation can make packets less than 1300. > What happens without netfilter or non-fragmented packets? Without br_netfilter it works fine, there is no defragmentation and refragmentation, fragmented packets will egress directly. Florian Westphal =E4=BA=8E2019=E5=B9=B47=E6=9C=8830=E6=97=A5= =E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=888:35=E5=86=99=E9=81=93=EF=BC=9A > > 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= .