From: David Miller <davem@redhat.com>
To: googuy@gmail.com
Cc: kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
kaber@trash.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] icmp: Restore resistence to abnormal messages
Date: Tue, 15 Nov 2016 11:56:57 -0500 (EST) [thread overview]
Message-ID: <20161115.115657.798577230951109692.davem@redhat.com> (raw)
In-Reply-To: <CAO1wt+b4OkJ4DmJ7_hUj_oKj4p_rRMuKUVpiBY7MSFMa=0WKQg@mail.gmail.com>
From: Vicente Jiménez <googuy@gmail.com>
Date: Tue, 15 Nov 2016 17:49:43 +0100
> On Mon, Nov 14, 2016 at 7:36 PM, David Miller <davem@davemloft.net> wrote:
>> From: Vicente Jimenez Aguilar <googuy@gmail.com>
>> Date: Fri, 11 Nov 2016 21:20:18 +0100
>>
>>> @@ -819,6 +820,12 @@ static bool icmp_unreach(struct sk_buff *skb)
>>> /* fall through */
>>> case 0:
>>> info = ntohs(icmph->un.frag.mtu);
>>> + /* Handle weird case where next hop MTU is
>>> + * equal to or exceeding dropped packet size
>>> + */
>>> + old_mtu = ntohs(iph->tot_len);
>>> + if (info >= old_mtu)
>>> + info = old_mtu - 2;
>>
>> This isn't something the old code did.
>>
>> The old code behaved much differently.
>>
> I don't wanted to restore old behavior just fix a strange case that
> was handle by this code where the next hop MTU reported by the router
> is equal or greater than the actual path MTU. Because router
> information is wrong, we need a way to guess a good packet size
> ignoring router data. The simplest strategy that avoid odd numbers is
> reducing dropped packet size by 2.
This whole approach seems arbitrary.
You haven't discussed in any way, what causes this in the first place.
And what about that cause makes simply subtracting by 2 work well or
not.
You have a very locallized, specific, situation on your end you want
to fix. But we must accept changes that handle things generically and
in a way that would help more than just your specific case.
next prev parent reply other threads:[~2016-11-15 16:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 20:20 [PATCH] icmp: Restore resistence to abnormal messages Vicente Jimenez Aguilar
2016-11-14 18:36 ` David Miller
2016-11-15 16:49 ` Vicente Jiménez
2016-11-15 16:56 ` David Miller [this message]
2016-11-15 17:30 ` Florian Westphal
2016-11-15 19:32 ` Vicente Jiménez
2016-11-16 1:14 ` Florian Westphal
2016-11-17 1:17 ` Vicente Jiménez
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=20161115.115657.798577230951109692.davem@redhat.com \
--to=davem@redhat.com \
--cc=googuy@gmail.com \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.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;
as well as URLs for NNTP newsgroup(s).