David Miller <da...@redhat.com> wrote: > From: Vicente Jiménez <goo...@gmail.com> > Date: Tue, 15 Nov 2016 17:49:43 +0100 > > > On Mon, Nov 14, 2016 at 7:36 PM, David Miller <da...@davemloft.net> wrote: > >> From: Vicente Jimenez Aguilar <goo...@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.
FWIW this is similar to the patch I sent a while ago: https://patchwork.ozlabs.org/patch/493997/ I think in interest of robustness principle ("eat shit and don't die") one of these changes should go in :-|