Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp205978rwi; Wed, 12 Oct 2022 18:43:59 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5Wlycf5swhonCrG+sWA1qXuq9o5ci9fHXuXditKu3ZcW2Sl1Lnxg00LR9uQgGGAB3AjRZw X-Received: by 2002:a17:907:7290:b0:78d:ec20:fe4d with SMTP id dt16-20020a170907729000b0078dec20fe4dmr6370008ejc.528.1665625439341; Wed, 12 Oct 2022 18:43:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665625439; cv=none; d=google.com; s=arc-20160816; b=YKZMW7VuRZ1G5dM1LAolSbVbXogxZdU8Q+2nj7Wy/5bFxl+1kakKXybjVjyzzEa+9B h1XuS0KFqx32BCfJfnjFzNQvzl+XUkynfYHulRnKn2wdSGRfpNuvwRwd/E705tNp30gs M7D07yzJqIcVV1z8eHDbRO+zfj1WwzZuF5guFTV0SwtH7SiC9pdcH77wqzMlRh6p0lxb a4pKoupMrdjygEzXvPPt0/JgZ3lMHyumZ8cE1aZ7MrYxlc/CDP4/lC4LJbLMIjC41m2Q nqI+8jfb/Ql+GwrxkZfhlgoj7jnn4tadoH4hqMKZvuTIvZH1QYiXwYfz3VEkO2rP4hk0 j1rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature:dkim-filter; bh=GdYPV5KBTkxnWVzeGkUGYgI1aPUxjUR0g3vCUZl5sAU=; b=XVYxdvwFgAdd5b6+y/mSZ3BACkZ6cU8K0YUJ6qTRXUcQuL9TrH6KCPSsBS+vZr7kI4 uPu64N0BOCK1alwHfXU2vF/9nrnKDJ2hkjmwp77ikyxwf8C4ShoclFgG4OiseZDuCYvR t22rlig8rwFLUBA7ZxIfpK87jg/lfC1zTCqDnpxs9YyMl8GrNOcTfU9Ay3REkuCFydCo TUi60WOqWy9EteWKNYvY2ySdd4QRuZGgqh3mK+83RuRvvrDPtQdykqPWJe/4unZkHL9C 1yg30XBHOeKXETccNqUJdMZ7DeD1+5AwqjNRZIfXVT0kskGVriYd03ZhYUfmfEaANF/9 pGoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@novek.ru header.s=mail header.b=nNqBOu7Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qa42-20020a17090786aa00b0078d8db64fffsi14392531ejc.20.2022.10.12.18.43.33; Wed, 12 Oct 2022 18:43:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@novek.ru header.s=mail header.b=nNqBOu7Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229694AbiJMBZu (ORCPT + 99 others); Wed, 12 Oct 2022 21:25:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbiJMBZr (ORCPT ); Wed, 12 Oct 2022 21:25:47 -0400 X-Greylist: delayed 1368 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 12 Oct 2022 18:25:39 PDT Received: from novek.ru (unknown [213.148.174.62]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BD9EB56D0; Wed, 12 Oct 2022 18:25:35 -0700 (PDT) Received: from [192.168.0.18] (unknown [37.228.234.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by novek.ru (Postfix) with ESMTPSA id 0C40B500669; Thu, 13 Oct 2022 03:39:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 novek.ru 0C40B500669 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=novek.ru; s=mail; t=1665621591; bh=ixeQ2bDkrFAa8j/pTu1c+7sHh9CHcjnL5tH54cA/vxQ=; h=Date:Subject:To:References:From:In-Reply-To:From; b=nNqBOu7ZDGDxqH9tfsCbrwz7rXz1l7hHXzk36zIfKtpuY1gEBuBaOki31jYTQX615 Fg02vMEUXHeY+QFkoh/RniWBKNhxOhjbJHlOO8aOxQ/rVQxkgvfpTe9qxFg5E7kIl0 3W7MTxA0M6HonqILxQZHA5vPMQrfuMcUXShqmGY0= Message-ID: Date: Thu, 13 Oct 2022 01:43:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: bridge:fragmented packets dropped by bridge Content-Language: en-US To: Vyacheslav Salnikov , netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org References: From: Vadim Fedorenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07.10.2022 12:21, Vyacheslav Salnikov wrote: > Hi. > > I switched from kernel versions 4.9 to 5.15 and found that the MTU on > the interfaces in the bridge does not change. > For example: > I have the following bridge: > bridge interface > br0 sw1 > sw2 > sw3 > > And I change with ifconfig MTU. > I see that br0 sw1..sw3 has changed MTU from 1500 -> 1982. > > But if i send a ping through these interfaces, I get 1500(I added > prints for output) > I investigated the code and found the reason: > The following commit came in the new kernel: > https://github.com/torvalds/linux/commit/ac6627a28dbfb5d96736544a00c3938fa7ea6dfb > > And the behavior of the MTU setting has changed: >> >> Kernel 4.9: >> if (net->ipv4.sysctl_ip_fwd_use_pmtu || >> ip_mtu_locked(dst) || >> !forwarding) <--- True >> return dst_mtu(dst) <--- 1982 >> >> >> / 'forwarding = true' case should always honour route mtu / >> mtu = dst_metric_raw(dst, RTAX_MTU); >> if (mtu) >> return mtu; > > > > Kernel 5.15: >> >> if (READ_ONCE(net->ipv4.sysctl_ip_fwd_use_pmtu) || >> ip_mtu_locked(dst) || >> !forwarding) { <--- True >> mtu = rt->rt_pmtu; <--- 0 >> if (mtu && time_before(jiffies, rt->dst.expires)) <-- False >> goto out; >> } >> >> / 'forwarding = true' case should always honour route mtu / >> mtu = dst_metric_raw(dst, RTAX_MTU); <---- 1500 >> if (mtu) <--- True >> goto out; > > As I see from the code in the end takes mtu from br_dst_default_metrics >> static const u32 br_dst_default_metrics[RTAX_MAX] = { >> [RTAX_MTU - 1] = 1500, >> }; > > Why is rt_pmtu now used instead of dst_mtu? > Why is forwarding = False called with dst_metric_raw? > Maybe we should add processing when mtu = rt->rt_pmtu == 0? > Could this be an error? > If you compare ipv4_mtu code from 4.9 you will see that the very first mtu value is filled by rt->rt_pmtu value. I believe there were changes to the bridge code where rt_pmtu value got empty or cleared. I'm still looking for the root cause of the problem, will update you once I find it. > > I found a thread discussing a similar problem. It suggested porting > the next patch: > Signed-off-by: Rundong Ge > --- > include/net/ip.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/net/ip.h b/include/net/ip.h > index 29d89de..0512de3 100644 > --- a/include/net/ip.h > +++ b/include/net/ip.h > @@ -450,6 +450,8 @@ static inline unsigned int > ip_dst_mtu_maybe_forward(const struct dst_entry *dst, > static inline unsigned int ip_skb_dst_mtu(struct sock *sk, > const struct sk_buff *skb) > { > + if ((skb_dst(skb)->flags & DST_FAKE_RTABLE) && skb->dev) > + return min(skb->dev->mtu, IP_MAX_MTU); > if (!sk || !sk_fullsock(sk) || ip_sk_use_pmtu(sk)) { > bool forwarding = IPCB(skb)->flags & IPSKB_FORWARDED; > > > Why was this patch not accepted in the end?