Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1522916

Re: [PATCH] icmp: Restore resistence to abnormal messages

From David Miller <davem@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH] icmp: Restore resistence to abnormal messages
Date 2016-11-15 18:00 +0100
Message-ID <sDPfr-7tr-15@gated-at.bofh.it> (permalink)
References <sCqCu-I7-7@gated-at.bofh.it> <sDukF-2cH-3@gated-at.bofh.it> <sDPfr-7tr-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] icmp: Restore resistence to abnormal messages Vicente Jimenez Aguilar <googuy@gmail.com> - 2016-11-11 21:30 +0100
  Re: [PATCH] icmp: Restore resistence to abnormal messages David Miller <davem@davemloft.net> - 2016-11-14 19:40 +0100
    Re: [PATCH] icmp: Restore resistence to abnormal messages David Miller <davem@redhat.com> - 2016-11-15 18:00 +0100
      Re: [PATCH] icmp: Restore resistence to abnormal messages Florian Westphal <fw@strlen.de> - 2016-11-15 18:40 +0100
        Re: [PATCH] icmp: Restore resistence to abnormal messages Vicente Jiménez <googuy@gmail.com> - 2016-11-15 20:40 +0100
          Re: [PATCH] icmp: Restore resistence to abnormal messages Florian Westphal <fw@strlen.de> - 2016-11-16 02:20 +0100
            Re: [PATCH] icmp: Restore resistence to abnormal messages Vicente Jiménez <googuy@gmail.com> - 2016-11-17 02:20 +0100

csiph-web