From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward106j.mail.yandex.net ([5.45.198.249]:50649 "EHLO forward106j.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbeCNI74 (ORCPT ); Wed, 14 Mar 2018 04:59:56 -0400 From: Alexander Zubkov To: Serhey Popovych , Luca Boccassi , Stephen Hemminger Cc: "netdev@vger.kernel.org" In-Reply-To: <3ebb9805-fb69-c67d-6222-c6d1d344f4ec@msu.ru> References: <20180312210301.12757-1-stephen@networkplumber.org> <1520890670.31389.1.camel@debian.org> <3677951520930804@web6j.yandex.ru> <1084221520939138@web32g.yandex.ru> <1520942521.12414.1.camel@debian.org> <3ebb9805-fb69-c67d-6222-c6d1d344f4ec@msu.ru> Subject: Re: [PATCH iproute2] Revert "iproute: "list/flush/save default" selected all of the routes" MIME-Version: 1.0 Message-Id: <135881521017992@web3o.yandex.ru> Date: Wed, 14 Mar 2018 09:59:52 +0100 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Sender: netdev-owner@vger.kernel.org List-ID: Hello, There was a series of patches by Serhey and specifically this one: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=93fa12418dc6f5943692250244be303bb162175b It drops handling of special prefix names in get_prefix_1(), and in get_addr_1() they always receive family and bytelen. But as I unerstand for any case it was important to keep it with unspecified family for further filtering. As I do not know what is the global idea, I want to discuss it. Because there are options depending on how and where we want to handle those special names. Like keep unspecified family or change filtering logic. I have added Serhey Popovych in the recepients, so he can give some ideas on what his aim is and help choose better solution. 13.03.2018, 21:12, "Alexander Zubkov" : > Hi, > > I just realized that you need patch for v4.15.0, which is easier to do. > I'll send it as separate message now. I will make patch for the master > branch, but later. > > On 13.03.2018 13:02, Luca Boccassi wrote: >>  On Tue, 2018-03-13 at 12:05 +0100, Alexander Zubkov wrote: >>>  Hello again, >>> >>>  The fun thing is that before the commit "ip route ls all" showed all >>>  routes, but "ip -[4|6] route ls all" showed only default. So it was >>>  broken too, but in other way. >>>  I see parsing of prefix was changed since my patch. So I need several >>>  days to propose fix. I think if "ip route ls [all|any]" shows all >>>  routes and "ip route ls default" shows only default, everybody will >>>  be happy with that? >> >>  Hi, >> >>  My only concern is that behaviour of existing commands that have been >>  in releases is not changed, otherwise I get bugs raised :-) >> >>  Thank you for your work! >> >>>  13.03.2018, 09:46, "Alexander Zubkov" : >>>>  Hello. >>>> >>>>  May be the better way would be to change how "all"/"any" argument >>>>  behaves? My original concern was about "default" only. I agree too, >>>>  that "all" or "any" should work for all routes. But not for the >>>>  default. >>>> >>>>  12.03.2018, 22:37, "Luca Boccassi" : >>>>>    On Mon, 2018-03-12 at 14:03 -0700, Stephen Hemminger wrote: >>>>>>     This reverts commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2. >>>>>> >>>>>>     Debian maintainer found that basic command: >>>>>>             # ip route flush all >>>>>>     No longer worked as expected which breaks user scripts and >>>>>>     expectations. It no longer flushed all IPv4 routes. >>>>>> >>>>>>     Reported-by: Luca Boccassi >>>>>>     Signed-off-by: Stephen Hemminger >>>>>>     --- >>>>>>      ip/iproute.c | 65 ++++++++++++++++++---------------------- >>>>>>  -------- >>>>>>     ------------ >>>>>>      lib/utils.c  | 13 ++++++++++++ >>>>>>      2 files changed, 32 insertions(+), 46 deletions(-) >>>>> >>>>>    Tested-by: Luca Boccassi >>>>> >>>>>    Thanks, solves the problem. I'll backport it to Debian. >>>>> >>>>>    Alexander, reproducing the issue is quite simple - before that >>>>>  commit, >>>>>    ip route ls all showed all routes, but with the change it >>>>>  started >>>>>    showing only the default table. Same for ip route flush. >>>>> >>>>>    -- >>>>>    Kind regards, >>>>>    Luca Boccassi