Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754167AbcKQBRt (ORCPT ); Wed, 16 Nov 2016 20:17:49 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36121 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752409AbcKQBRq (ORCPT ); Wed, 16 Nov 2016 20:17:46 -0500 MIME-Version: 1.0 In-Reply-To: <20161116011404.GF30581@breakpoint.cc> References: <20161111202018.13795-1-googuy@gmail.com> <20161114.133646.1687576478968660327.davem@davemloft.net> <20161115.115657.798577230951109692.davem@redhat.com> <20161115173024.GD30581@breakpoint.cc> <20161116011404.GF30581@breakpoint.cc> From: =?UTF-8?Q?Vicente_Jim=C3=A9nez?= Date: Thu, 17 Nov 2016 02:17:44 +0100 Message-ID: Subject: Re: [PATCH] icmp: Restore resistence to abnormal messages To: Florian Westphal Cc: David Miller , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uAH1Ht7i006823 Content-Length: 1508 Lines: 36 On Wed, Nov 16, 2016 at 2:14 AM, Florian Westphal wrote: > Vicente Jiménez wrote: >> 1- add warning with pr_warn_ratelimited. I like this idea. I also >> though about adding some message but I have no kernel experience and I >> preferred to have just a working solution. > > I added this only to show whats happening. > > I don't like such printks because end users can't do anything about it. > What about using net_dbg_ratelimited macro? it only adds messages if debug is enabled. > >> Finally, both patches decrement current packet by a value: Mine by 2 >> and Florian's by 8 bytes. Both arbitrary values. Personally I prefer >> to go by small steps. If the small step fails, it just iterate again >> and with 4 iterations, my patch also decrement the original value by 8 >> bytes (4x2). >> Basically they are the same but my patch take smaller steps and miss >> the warning message. > > IIRC I chose 8 because connection recovered faster in my case. > > I have not experienced this issue again (I dropped the patch from > my kernel at some point and the connection stalls did not reappear so > this got fixed elsewhere). My issue is permanent for now in various locations. We have to decrease MTU manually on all devices with newer kernels. We don't have direct access to those abnormal routers because they are managed by a communication provider that think the network had no problem because all their Windows machines apparently work perfectly. -- cheers vicente